1. Introduction
Network tokenization is a card tokenization solution offered by card networks like Visa, Mastercard, Discover or American Express that replaces primary account numbers (PANs) and other card details with a token issued by the card brand.
EMVCo defines a payment network token as “a surrogate value that replaces a primary account number (PAN) in the payment ecosystem.”
What are today's challenges?
Declines due to expired or not up-to-date accounts stay high and increase merchant maintenance to keep card-on-files account credentials up-to-date.
One single fraudulent transaction can entirely suspend a cardholder account.
Checkout experience and merchant subscriptions suffer when no real-time account updates are in place.
Why network tokenization?
Lost, stolen, expired cards, or other failures become irrelevant because the network token is proactively updated. Issuing banks are mandated by the card network to update the network tokens with any account updates.
As a result, customers experience fewer false declines due to out-of-date information and have a better user experience for their subsequent or recurring/instalment transactions.
Benefits of network tokenization adoption
Network tokens do not expire.
Issuers push changes to card networks to keep network tokens up-to-date.
Declines resulting from suspended accounts due to fraud are eliminated.
Declines resulting from expired, lost, or stolen accounts are eliminated.
Fraud screening shifts from the time of payment processing to the time of token provisioning.
Each network token is domain restricted to an individual merchant.
Issuers have greater confidence in network tokens leading to lower false decline authorization rates.
Benefits of network tokenization for consumers, merchants, and issuers
For consumers
Better payment experience
Eliminated frustration at the time of the transaction
Less declines experienced
Removed need to go through card-on-file updates on merchant's website upon card expiration or renewal
For merchants
Over 2% increase in authorization rates
No need to store sensitive account data, security liabilities are reduced
Reduced average fraud rates (according to Visa by 26%)
Reduced chargebacks as liability shifts to the issuer
Lower costs for lower interchange rates as card networks adopt a cost rate increase on qualifying transactions that are processed without the use of a network token (10 basis points increase by Visa)
Reduced in-house operational costs as the need to reach out to consumers having expired cards-on-file is eliminated - on average merchants try to contact consumers two to three times before cancelling services
For issuers
Fewer cards to replace as risk for fraud lowers and cardholders have less negative experiences
Greater visibility and control over credentials leading to higher confidence when approving transactions
2. The Tokenization vision
Consumer demand as well fraud increased significantly in the past few years and merchants are under intense pressure to deliver an effortless payment experience to their consumers that is highly secure. ACI Payment Orchestration Platform is helping merchants continue their tokenization and payments journey without friction. For this reason the vision is:
To offer a unified tokenization solution for better merchant integration and future card network evolution
To leverage one Token Vault across ecommerce (card-not present) and omnicommerce (card present and non card-not present)
To connect to the four major card networks (Visa, MasterCard, AMEX, Discover) via a scheme-preferred Token Service Provider
To keep up with the card network mandates and future evolution of network tokenization programs
To automate onboarding processes by card network and go live immediately
To be able to monitor acceptance rates
To transparently get billed and run your own analysis reports
Why a unified tokenization solution?
Today, existing non-PCI compliant merchants use merchant tokens to submit payments. The merchant tokens are ACI-generated tokens:
registration token in ecommerce - see Network Tokenization Integration Sheet - eCommerce
omniToken in omni (ecommerce and in-store) - see DRAFT Network Tokenization Integration Sheet - OMNI [eCommerce and in-store]
The product recommendation is for the merchants to continue using the merchant tokens. ACI does the rest and keeps complexity out of the merchants.
The merchants in this case should only onboard for network tokenization and continue the tokenization and payments journey without any integration change.
The unified tokenization solution automatically triggers network token provisioning or fetches network token authorization data to process the payments via acquirers
The acquirers would have to support and accept payments with network token authorization data
Why one token vault?
Today, there are ecommerce-only merchants and omni merchants that run their businesses both in-store and online (ecommerce).
For an omni merchant offering different payment channels to their consumers, one token vault is necessary to ensure a fluid and frictionless tokenization and payment flow.
The same card used in store or online with the same merchant would have the same network token regardless of the initiating source for tokenization (in-store terminal, or online merchant website)
An ecommerce-only merchant expanding business in-store or vice versa, would benefit from one token vault and leverage existing network tokens for authorising payments
What is stored in one token vault?
Only real card data and a reference to the network token are stored in the one token vault, nothing else.
The network token provisioning request to the card networks via TSP only triggers creation and approval of the network token and one token vault does not store it.
The network token transaction request to the card networks via TSP retrieves the network token authorization data (DPAN, expiry date, dynamic cryptogram) and one token vault does not store them.
Why connect to card networks through a TSP (Token Service Provider)?
It is better to have one integration with a provider preferred by the schemes.
The Network tokenization solution will evolve in future, and it is better to keep consistency from a merchant standpoint across all major card networks.
Automatic onboarding processes with card networks converge.
What if I have my own preferred TSP?
As a merchant, it is perfectly fine to work with your own preferred TSP (Token Service Provider).
In this case, the merchant controls the provisioning of the network tokens.
The merchant then uses the ACI Payment Orchestration Platform to authorise the payments using the network token authorization data elements as retrieved from the card networks via its TSP.
ACI Payment Orchestration Platform offers an extended OPP REST API to allow the merchant to pass all the network token authorization data
3. Dynamic cryptogram usage
Network token payments have increased security as they are merchant-specific and each transaction is protected with a one-time-use cryptogram that needs to be fetched from card networks.
CIT (Cardholder-Initiated Transactions) payments such as pre-authorizations or debits do require cryptograms as they are initiated by the shopper and represent authentication data that enhance issuer decisioning.
MIT (Merchant-Initiated Transaction) payments do not require a cryptogram as the shopper is no longer present.
Cryptogram usage rules are as follows:
All CIT-authorising transactions require dynamic cryptograms when authorising the payment with the Network Token Authorization Data
MIT-authorising transactions (recurring/instalments) do not require in general cryptograms, just network tokens. But please see below some of the card network rules where one MIT payment in the chain still requires a cryptogram.
MIT captures, reversals, or refunds do not require a cryptogram regardless of whether they are done offline or online, just network token.
In other words, a cryptogram is required for at least one payment in the chain for a card-on-file when authorization is performed with Network Token Authorization Data. To exemplify, there are two similar MIT situations that require cryptogram usage alongside a network token:
New MIT agreements between a merchant and shopper. In this case, the CIT payment is authorised with FPAN while the network token is asynchronously provisioned. Network token provisioning may take minutes.
First, the CIT payment is authorised with FPAN while the network token is being provisioned.
Second, the MIT payment is authorised with the network token and cryptogram.
Third, the MIT payment is authorised with the network token only (no cryptogram).
Fourth, the MIT payment is authorised with the network token only (no cryptogram).
And so on
Old MIT agreements (recurring or instalment payments established before the merchant opted for network tokenization). In this case, where merchants have old COFs in place, they just run recurring payments.
First, the CIT payment is authorised with FPAN (let’s say two years ago).
Second, the MIT payment is authorised with FPAN.
Third, the MIT payment is authorised with FPAN.
…
Now, the merchant decides to opt for network tokenization and does not want to have the cardholder present for a new MIT agreement.
Next, the MIT payment is authorised with FPAN while the network token is provisioned (asynchronous).
Next, the MIT payment is authorised with the network token and cryptogram.
Next, the MIT payment is authorised with the network token only (no cryptogram).
Next, the MIT payment is authorised with the network token only (no cryptogram).
The product recommendation for the merchant is to let ACI Payment Orchestration Platform provision and collect network tokens including dynamic cryptograms based on the network rules as explained above.
Otherwise, if the merchant wants to control the usage of network tokens with their own TSP (Token Service Provider), they will then have to control the dynamic cryptogram usage too.
FAQ
What is network token provisioning data vs network token authorization data?
When provisioning, all real card data elements are provided to the card network to initiate network token provisioning, from cardholder FPAN to expiry date and holder name, language, country and email.
The network token is then approved by the issuer once its own fraud screening is successful and then provisioned by the card network.
Finally, the network token becomes active for payment authorization.
With the network token provisioning request, there is no network token authorization data received to initiate or continue with a payment, just a reference to the network token.
To initiate or continue a payment, the network token authorization data is retrieved from the card network in a second request to the card network using the network token reference.
All these previously listed actions are transparent for the merchant, they are all handled by the ACI Payment Orchestration Platform.
Are cardholder language, country and email necessary for network token provisioning?
The customer’s language, country and email are all required parameters for network token provisioning as they are included in the fraud screening performed by the issuing bank.
If for some reason they are not available, the issuer may increase the fraud flag and mark the card as not being eligible to tokenization.
For new MIT agreements, the merchant has the ability to collect the following data:
cardholder language and country within locale OPP REST API parameter
cardholder email within the customer.email OPP REST API parameter
Question - If that happens, will the merchant have the possibility to start the process again ? If yes, any delay in doing so again ? If not, is there any workaround ?
For existing MIT agreements, when no cardholder language, country, or email parameters are available, the merchant language, country and email used during the onboarding process are considered as default parameters for token provisioning.
As a last resort, when no language, country, or email parameters are available, the merchant onboarding data is considered for token provisioning.
Why does payment continue with real card data when network token provisioning is initiated?
Due to high adoption from merchants for network tokenization, the card network simply has to deal with too many tokenization requests.
For this reason, the card network strategy is to provision the network token asynchronously and get approval from the issuing bank, thus closing the loop to make it active.
All these actions take between 2-4 seconds and in some exceptional instances up to 10 minutes, depending on the token request volume the card network receives.
The card network recommendation in this case, especially when the cardholder is present, is to continue the payment with real card data while network token provisioning is fully completed with all players.
With the next purchase, the network token will most probably be active, and network token authorization data can then be requested from the card network for payment processing.
As a merchant, do I need to store network token authorization data?
No. Network token authorization data is always retrieved from the card networks. The ACI Token Vault stores the token DPAN and DPAN expiry date as they do not change for the same MIT agreement. Cryptogram is not stored as it's dynamic and changes according to payment transaction and rules.
ACI Payment Orchestration Platform deals with the complexity to quickly and securely receive all network token authorization data when payment is initiated. The merchant just needs to onboard and enjoy the benefits.
If, as a merchant, I have my own TSP for network tokens, can I just authorize the payment?
Yes, if you have your own TSP (Token Service Provider), you control the way network tokens are provisioned by the card networks and approved by the issuers.
No onboarding is necessary with ACI Payment Orchestration Platform. You would have an OPP REST API extension to provide the network token authorization data in the payment request.
Dynamic cryptograms are not always required, so follow the guidance on Dynamic Cryptogram Usage.
What is the network token life cycle and should I care about it as a merchant?
Three network tokens statuses are handled by the issuers and card networks:
ACTIVE: Account and network token are in good standing. Merchants can process transactions according to COF agreement.
SUSPENDED: Temporary status for network tokens and can change to ACTIVE or DELETED. Merchants should not process transactions with suspended tokens. Tokens get suspended when an issuer is in the process of reissuing a new card due to an expiry, loss, theft, portfolio change, or fraud scenario.
DELETED: Final state for a network token usually when the account is closed. Merchant must request new credentials from the cardholder.
In case of a SUSPENDED or DELETED token status situation, the merchant receives a corresponding decline return code as provided by the acquirer from the issuer/card network.
What happens with the network tokens associated with a merchant token domain that is compromised?
Let's visualise the following fraud scenario where same cardholder has its card on file with two different merchants:
Merchant A and B have two different merchant token domains.
The same card being tokenized with both merchants leads to distinct network tokens provisioned for the same card as they pertain to different merchant token domains.
When merchant A is compromised due to suspected fraud, merchant B is not affected.
In this case, only end consumers doing business with that compromised merchant A would be affected. Issuers block the offending merchant by suspending the network tokens for that merchant domain rather than putting a hold on the entire card.
What is the merchant token domain if the PSP onboards on behalf of the smaller merchants?
The token domain would be that of the PSP domain.
It means that one network token is shared for the same card between merchants of the same PSP.
In case one merchant is compromised leading to the network tokens getting compromised, then this is potentially impactful for the other merchants.
The product recommendation for PSPs is to onboard large merchants individually so that they benefit from a token domain attributed only to them during the onboarding process.
It is possible for a PSP to both individually onboard large merchants as well to onboard the PSP on behalf of smaller merchants.
As a merchant, I use today Real-Time Account Updater. What if I switch to network tokenization?
Lost, Stolen, or Expired cards situations are completely removed if you go the network tokenization route.
A network token will always be linked by the network to the up-to-date card as received from the issuer.
If you do not need to have an improved checkout experience with up-to-date BIN and last 4 digits, then network tokenization gives you the highest acceptance rates levels with added security controls in place.
To be able to receive the updated bin, last 4 digits and expiry date and show them on subsequent checkouts then real-time account updater can continue to stay active to solve expired card situations.
For further details, see the Real-Time Account Updater and Network Tokenization advanced feature.
As a merchant, I use today multi-acquirer strategies. What if I switch to network tokenization?
Some acquirers may not be ready for network tokenization.
To avoid complexity on the merchant side, ACI Payment Orchestration Platform offers an automatic way of detecting which acquirers are ready for network tokenization.
If the acquirer to which the payment transaction is dispatched supports network tokenization, then payment is processed with Network Token Authorization Data
Otherwise, payment is processed with real card data.
For further details, see the Dispatching and Network Tokenization and Middleware Dispatching and Network Tokenization advanced features.