The data security rules around payments can be puzzling to new and seasoned payments professionals...
Why Card Tokenization Failure Hurts Your Business
As e-commerce continues to expand, with revenues growing faster than their brick-and-mortar competitors, payment processing and security remain under the microscope. The proliferation of damaging data breaches and systems hacks, causing untold millions of costs and difficult-to-reverse damage to brands, means that no merchant can afford to leave their customers’ data exposed. For this reason, tokenization has become one of the most keenly-researched payment system additions of the day: whether at the card network, payment processor, or third-party provider level, successful tokenization schemes are driving lower risk and lower costs. But what happens when a carefully-created system fails?
How does card tokenization fail?
Card tokenization is the process of replacing sensitive data with a unique string that can be used to submit transactions but can never be converted back into its plain text form. Card tokenization failure occurs when the requesting merchant requests—but does not receive—a token representing the customer’s cardholder data.
Tokenization failure can happen at a number of points in the transaction process:
- The web form may be improperly formed, resulting in a token request that cannot be processed by the tokenization provider
- There may be connectivity issues between the consumer and the tokenization provider - anything from the user’s WiFi failing to the token vault’s content delivery network (CDN) suffering some kind of outage
- The customer may enter data that is not recognized by a card network, causing them to reject the transaction, and, therefore, not create a token
- Security protocols, which change fairly regularly, may block data from flowing in one direction or another
Regardless of the causes of the card tokenization failure, the impact of such an event can be significant because the ramifications affect not only the initial transaction, but also any future ones. After all, storing a card token isn’t really an action focused on closing one deal, rather it’s a strategic move that allows the merchant to process future payments more conveniently and quickly for the customer.
So a token provisioning going wrong can put a dent in a long tail of continued sales.
It also matters where the card tokenization failure occurs in the process. For instance, if the issue occurs at the card network because of mismatching details, there is still an opportunity to re-prompt the customer to check what they have entered and try again. By contrast, if the issue occurs at the full-service PSP level, there will likely be a range of esoteric processes to work through to try for another attempt—with the PSP’s own fraud management systems delivering some amount of friction.
Limiting Failure Risk
Making token provision as robust as possible requires forethought, planning, and a certain amount of expertise. It’s also critical to have fallback positions that fuel the maximum number of possible routes.
Some of the ways that payment systems are structured are more vulnerable to card tokenization failure than others. This risk is to a large degree determined by where in the process the merchant positions the tokenization provisioning step:
- PSP-level Tokenization: The risk is high, because the PSP is literally the single gateway to the payments ecosystem. If something goes wrong here, there are no alternative pathways to explore.
- Card Network Tokenization: The risk here is medium, because the failure codes returned by the card network, when properly communicated, can offer a strong indication of the root causes of the failure, and provide an opportunity for re-tries.
- Token Vault Tokenization: The risk here is low, because the token vault can be called upon to retry transactions based on card network codes, as well as across a functionally limitless number of payment providers.
It’s worth noting that merchants whose payment systems make use of programmable token vaults, like the one provided by Basis Theory, tend to be based on a principle of redundancy: there’s always, for instance, more than one PSP to send transactions to, so that if one is unavailable, another can be used. Simply as a design principle, this serves to increase the likelihood of a token being provisioned.
Planning Ahead
Optimization is the most popular word in payments, and that’s exactly what merchants should do with their transaction processes.
Merchants who are going to maximize their payment throughput plan ahead, understanding that, like other challenges, failed card tokenization is an inevitability. By using a group of trusted PSPs with different focuses and in different geographies, they not only reduce their risk of failed transactions, they also decrease the cost of processing.
Most opt to automate this payment approach by using a programmable payment vault, which handles the tokenization, and ensures smooth transmission of transactions—even if that transmission has to be repeated to offset downstream tokenization failures.