-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Retrying network token transactions with clear PAN
The benefits of Network Tokens are well appreciated and truly valuable to the payment ecosystem. Network Tokens replace sensitive card data with unique, one-time-use tokens, reduces the risk vector of data breaches and simplifies compliance with data protection regulations. Adopting network tokens can directly uplift your auth rates by 4.6%.
Beyond Network Tokenization, could there be scenarios for further window of opportunity to further optimize your auth rates with a Clear Primary Account Number (Clear PAN) strategy?
There are three possible dimensions which allows a window of opportunity for further auth rate optimization.
In a Tokenized transaction, the underlying card network actually detokenizes the network token, and sends the Clear PAN number along with more metadata (including fraud score) to the issuer for processing. Hence it is possible that some issuers become overly cautious, and start rejecting transaction with using the fraud scores to reject the transactions avoid the path of liability shift at any cost (in spite of card schemes clearly mentioning that the additional metadata does not signify authentication)
Additionally, some issuers might have limitations on accepting tokenized transactions for cross-border payments, leaving a window of opportunity for improving the auth rates.
Ecommerce fraud solutions or acquirer fraud solutions tend to be more effective with Clear PANs because they have more accurate data points to analyze and can utilize established fraud detection patterns which have been well-trained on Clear PANs. Around 4% payments could be lost due to false positives (genuine transactions incorrectly labelled as fraud) due to differential capabilities of Fraud detection systems used by the acquirer or merchant.
And Network tokens while improving security by replacing sensitive data, could lead to less effective fraud detection due to unfamiliarity and reduced data visibility for fraud detection systems.
PSP implementation of network tokenization can impact your auth rates due to three factors.
Poor quality integration: Might lead to tokens expiring prematurely or not being refreshed properly, resulting in transaction failures. Dependency on third party TR-TSP: Some PSPs may depend on third party TR-TSP (Token requestor - Token Service provider) systems for tokenization service. This may result in additional hops which can add up to latencies and negatively impact the potential auth rate uplifts. Lack of interoperability: Some PSPs might obfuscate the actual network tokens with alternative identifiers. This hampers the interoperability of such network tokens for your business. Such alternate identifiers will not be recognized by an alternate PSP, if you wish to retry the payment with alternate PSP to uplift the auth rates.
If the transaction request with the Network Token fails, be sure to implement a retry strategy with de-tokenization. Work with a PCI certified partner to securely detokenize the network token into clear PAN and retry the payment. This can salvage auth failures due to the network token failures.
Ensure that you roll out your network tokenization strategy at a BIN level and establish the auth rate uplift before you fully switch to a network token. Network tokenization is also going to have an additional cost to the payment processing costs, and hence it is better to ensure that the auth rate uplift is significant enough to justify the costs incurred.
Some card schemes provide ~10 bps cost savings on the interchange program fee for network token transactions. But it is important to ensure whether your business critical interchange programs and MCC codes actually qualify for the savings.
Moreover, the auth rate uplift of network tokenization may not be the same across all BINs and this strategy will be very helpful to monitor the issuer behavior patterns with Network Tokens versus Clear PAN. And accordingly adopt network tokens for the BINs with significant uplift.
Always work with Card Scheme certified TR-TSP (Token requestor - Token Service provider). And ensure that the TR-TSP is transparent and not obfuscating the raw network tokens with alternate identifiers. Refer to the Card Scheme partner directory before choosing your TR-TSP partner.
Also connecting directly to the card scheme through certified TR-TSP will eliminate additional hops and eliminate the possibility of poor quality integrations.
Hence to conclude, it is very critical to have a clear PAN strategy (in a PCI compliant manner) to complement the network tokenization strategy while targeting auth rate uplifts and fraud reduction.