Tokenization solved an important security and regulatory problem in digital payments: merchants no longer need to retain the underlying Primary Account Number (PAN) to support card-on-file (COF) transactions.
But it created another problem – routing control.
A merchant may have a debit card that can legitimately route over multiple enabled debit networks. Yet when the merchant stores a network token issued by a front-of-card network, that token may carry network or processing restrictions. The merchant therefore loses the ability to choose an alternate debit network for a subsequent digital tokenized transaction.
“The merchant has more security, but potentially less routing choice.” – Debashis Bhattacharyya
A side-by-side token architecture addresses that problem by allowing multiple network-specific tokens representing the same underlying payment account to coexist. It gives the merchant the ability to select the appropriate token and therefore the network route dynamically during transaction processing.
This concept is based on an important design principle that maintains three relationships –
PULSE’s Side-by-Side (SXS) Token Service is a real-world example of this model. PULSE describes SXS as enabling tokenized card-on-file debit transactions to be routed over PULSE or another participating unaffiliated debit network, with cryptogram validation and no change to the cardholder experience.
The objective of this article is not to reproduce PULSE’s implementation. Instead, it uses the publicly available patent disclosures as a reference architecture for how a new debit network could build its own side-by-side token capability.
Consider a consumer who has a debit card issued by Bank A.
That card supports:
A merchant stores the customer’s card for future purchases. Traditionally, the merchant token comes from the network.
Customer PAN -> Front of Card Token Service -> Merchant Token -> Merchant Card on File
For security reasons, that token may be restricted to transactions routed through the network that issued it. Hence, the transactions are always routed through Network A.
The core idea of this solution is simple. Let us use the same scenario here as well. In this case, two tokens are generated and stored at the merchant. One for the front of card – A, and an additional for the Debit Network – Back of card – B.
Please note – they are co-existent but not interchangeable. They have their own Token PAN, token type, network association, lifecycle status, routing eligibility, relationship with the PAN and are independent of each other.
The merchant’s payment platform can then select the appropriate token according to its routing strategy as depicted in this diagram.
{
“token”: “NDN_TOKEN_123456789”,
“token_type”: “SECONDARY”,
“network”: “NDN”,
“status”: “ACTIVE”,
“cryptogram_required”: true
}
The merchant saves this information in the database along with the primary token procured before from the Primary network.
The merchant now has multiple payment credentials associated with the same customer payment account.
The customer is invisible to this information, as they see the last 4 digits in the token on screen at the merchant’s e-commerce portal.
The merchant needs to build a routing engine based on the rules and network preference that can take advantage of this capability. The idea is for the merchant to be able to choose between the two tokens to maximize profits and minimize costs both for themselves and the customer without degrading the customer experience. The routing engine can route based on many factors –
A simple NDN based transaction will look like this
The presence of a secondary token should not be the reason for routing through NDN. It should be based on rules owned and managed by the merchant.
The debit network needs to carefully design a monetization policy that incentivizes merchants for routing through them. This can be made lucrative through lower cost, flexibility, safety and performance.
The table below lists the capabilities required by the network for enablement. These can be prioritized by applying the MoSCoW principle.
| Capability | Purpose |
|---|---|
| Token Service | Generate/manage secondary tokens |
| Eligibility Directory | Determine which cards/accounts support NDN |
| Token Vault | Secure PAN-to-token mapping |
| Cryptogram Service | Generate/validate transaction cryptography |
| Token Requestor Management | Control who can provision tokens |
| Lifecycle Management | Suspend, resume, replace and expire tokens |
| Account Updater | Propagate account changes |
| Merchant APIs | Provisioning and lifecycle integration |
| BIN/Account Range APIs | Eligibility |
| Routing Integration | Enable merchant network selection |
| Authorization Gateway | Process NDN token transactions |
| Monitoring/Fraud | Detect token abuse |
| Dispute/Chargeback Mapping | Link token transactions to underlying account |
| Reporting | Token/network/merchant analytics |
| Monetization | Fees for provisioning, lifecycle management, transactions, VAU and VAS |
The Side-by-Side token is a choice, and flexibility a merchant demands in today’s world. It empowers the merchant. It allows them to own and manage their routing mechanism and provide better services to their customers through low-cost routing options. The value is “One payment account can have multiple secure, lifecycle-managed network credentials, while the merchant retains the ability to choose the network route.”