Omnichannel Tokenization for Subscription Merchants
The most expensive moment for a merchant isn’t when a customer actively chooses to cancel, it’s when a recurring charge fails silently. A card expires, a processor declines a retry, or a soft decline is missed and never re-submitted.
Now, a customer who never intended to leave is gone.
Omnichannel tokenization steps in and breaks that cycle by storing payment credentials in a secure vault, routing each charge through whichever processor is best fit for approval, and helping merchants to avoid the silent attrition of failed subscription payments.
Describing Omnichannel Tokenization
The core concept of omnichannel tokenization is that the merchant uses a consistent approach to store tokens for any payment method, with the corresponding details stored in a programmable payments vault. The merchant then can concentrate development efforts on building a robust decisioning engine to route each transaction for the maximum likelihood of processing success at the lowest possible cost.
Omnichannel tokenization involves three elements:
- The consumer’s payment details are stored in a secure third-party vault.
- The merchant receives a token (a randomized string), which gives them access to send the payment details, without bringing them into the payment system (which would itself bring that system into PCI-DSS scope).
- The merchant uses the token to direct the third-party vault to route the payment details to their preferred payment processor.
The merchant, therefore, can accelerate the process of completing future payments by not requiring the customer to re-enter their details; and protect against the resource and investment drain of extensive PCI compliance by never storing those details in their own system. Indeed, the token that the merchant stores as a ‘key’ to accessing the customer’s details through the third-party vault can never be decrypted, nor can it be used to initiate payments by anyone other than the approved merchant.
In the payments world, there are several different tokenization options available, though most do not offer the flexibility of omnichannel tokenization. For example:
- PSP Tokenization: A specific payment service provider (PSP) may offer tokenization, which achieves many of the same benefits as omnichannel tokenization. However, PSP tokenization is limited to the associated PSP. In other words, the merchant must use the PSP token to transact via the issuing PSP, eliminating their flexibility to build a network of PSP partners to optimize processing fees and routing options.
- Card Network Tokenization: A deeper-in-the-system option, in which the merchant stores a token provided by the card network (e.g., Visa, Mastercard, etc.) that is specific to the merchant. While this protects the cardholder data, increases close rates, and can shift fraud responsibilities from the merchant to the card network, it is challenging to build and maintain, as each card network has its own set of requirements and standards to keep up with.
Why Subscription Merchants Depend on Card-on-File Flexibility
Subscription merchants rely on charging a stored card, often weeks or months after it was initially entered. This creates two challenges:
- Card details change, expire, or get reissued after fraud or when the customer simply loses their physical card. Every one of these events is a potential involuntary churn event if the merchant can’t update or retry with a fresh credential.
- Processor performance will vary. A processor that approves 94% of retries on a Tuesday might decline 20% on a Friday due to internal risk rules the merchant never sees and has no control over. Without the flexibility to retry through a different processor, a merchant loses revenue without being able to fight for it.
Omnichannel tokenization solves both problems, creating a rare win-win in the world of e-commerce. The card-on-file is stored in a processor-agnostic vault, keeping the token from being tied to any single PSP. Merchants then can retry a failed subscription with a backup processor without having to ask the customer to enter payment details again.
The merchant, with a token in place that is not associated with a particular PSP (payment service provider,) is free to add, replace, and remove payment partners over time, pursuing the optimal combination of transaction success and cost. In addition, by opting to store the clear-text cardholder data outside their system, they inoculate themselves from the resource drain of many complex PCI-DSS efforts and gain the confidence that they are not vulnerable to embarrassing and expensive data breaches.
Omnichannel Tokenization Eases PCI Concerns
An expensive element of maintaining a sophisticated payment system for most merchants is remaining in compliance with the stringent requirements of the PCI-DSS standard. Meeting PCI compliance means annually ensuring the safety and security of all customer personally identifiable information (PII). For merchants that intend to store any cardholder data within their database, this can mean significant costs, as well as the need to pay an external Quality Service Assessor (QSA) to validate their efforts on an annual basis.
Omnichannel tokenization eliminates a large chunk of the concern because the merchant simply avoids having the customer’s cardholder data stored in a format that could ever be used, or even reverse-engineered into its original form. Tokenization, by definition, replaces the usable data with a randomized string. This cannot be converted back into the underlying data (this is in contrast to encryption, where the data could be converted back to its original form by anyone who can access, or ‘crack,’ the decryption key).
Merchants using an omnichannel tokenization strategy not only reduce the cost and complexity of their PCI-compliance program, but operate with confidence that no breach could expose their customers' details.
QSA fees, annual audits, and engineering time spent on controls instead of growth; most of that goes away when you're not storing card data. Get started by outsourcing PCI compliance.