Evaluating network tokens: Webinar Q&A

Network tokenization promises better authorization rates, reduced fraud, and enhanced security, but implementing it comes with real questions.

During our recent webinar, "Evaluating Network Tokens: Are they worth it?", merchants asked the tough questions they're grappling with in their own organizations. Below, we've compiled the most insightful questions from the session along with detailed answers to help you make informed decisions about your network tokenization strategy.

We tried network tokens for a while, but didn’t see much uplift. Why do you think that this?

In most cases, a lack of observed uplift comes down to timing or data quality. Network token benefits often appear over a longer window, as they primarily reduce hard declines from expired or reissued cards. If the test period is too short, those cards haven't yet cycled, so the improvement isn't visible. It's also common for PSPs to perform network tokenization behind the scenes, which can distort comparisons. If your PSP was already routing tokenized traffic, your baseline authorization rate was already uplifted. Low uplift doesn't mean network tokens aren't effective; it usually means the sample period was too narrow or the data wasn't isolated from pre-existing tokenized transactions.

If we receive a cryptogram and the auth is then declined, is there any point in re-trying with a PAN?

It depends on the reason for the decline. For hard declines such as insufficient funds, retrying only adds cost without benefit. However, retrying with the PAN can be worthwhile for soft declines, like "do not honor, " as it provides stronger evidence of cardholder presence, particularly when a CVV is included. In recurring or card-on-file scenarios where CVVs are no longer stored, the value of retrying decreases. The best approach is to align your retry strategy with the decline code rather than retrying all declines indiscriminately.

We're a merchant with three PSPs and one standalone vault provider, and we're evaluating a standalone network tokenization solution. This requires coupling with their system in the payment flow, which may raise concerns about redundancy and incident handling. As a standalone provider, what's your view on this?

Resiliency should be a primary evaluation criterion when choosing a network token provider. Look for a platform built on active-active, multi-region infrastructure that can remain operational even during regional cloud incidents. Just as importantly, design your own system with failure in mind; the token service shouldn't be a single point of dependency for every transaction. The service only needs to be available when creating tokens from raw PANs. Once tokens are issued and stored, you can process merchant-initiated transactions (MITs) without requiring real-time cryptogram generation. Cryptograms are only essential for customer-initiated transactions, so your payment flow can remain resilient even if the token service is temporarily unavailable.

For a large merchant that generally has low card-on-file/repeat customers, do you have any estimate of the typical auth uplift?

Even merchants with limited repeat customers typically see a 30–50 basis-point uplift in authorization rates when using network tokens. Most of this improvement comes from reducing soft declines rather than simply addressing expired-card issues. For example, when a shopper's browser or wallet contains an outdated card, the network token often maps to the reissued credential, allowing the transaction to proceed successfully. In short, network tokens can deliver meaningful performance gains even in low card-on-file environments.

Merchant fraud teams primarily care about fraud chargeback rates due to Visa/Mastercard fraud programs and the overall cost of doing business. Does the fraud rate reduction promoted by network tokens address this issue? If not, is it even worth bringing up as a benefit?

Yes. When transactions are processed using network tokens along with a cryptogram, issuers often return an ECI value that triggers a liability shift, similar to what occurs with 3D Secure. This shift means that for certain types of fraud chargebacks, such as those monitored under Visa's VAMP or Mastercard's TC15/TC40 programs, liability transfers from the merchant to the issuer. The result is fewer fraud-initiated chargebacks and improved compliance ratios. In short, fraud reduction through network tokens isn't just a peripheral benefit; it directly impacts the metrics that fraud teams are measured against.

Could the Evervault SDK support domain-bound (device-specific) tokens?

When using the Network Tokens API, these tokens are domain-bound as they're tied to a specific merchant. Our Google Pay and Apple Pay SDKs will produce device-specific tokens when authenticating a transaction.

If Network Token creation and cryptogram generation are successful, can we assume the auth will be approved? If we have a failover to PAN (in case the NT creation fails or the cryptogram creation fails), is there also a need to retry with PAN if the final auth fails?

Successful network token and cryptogram generation would increase the likelihood that a transaction will be approved, but it doesn't guarantee it. The issuer may still decline based on their fraud risk engine. Retrying with a PAN depends on the reason the failure occurred.

Do network tokens still need to be encrypted via the Evervault SDK? What about the expiration date? Also, should the expiration date be encrypted for raw PAN with Stripe, and do these count as separate decrypts with the Evervault SDK?

Network tokens themselves don't fall under PCI DSS. Still, cryptograms must be treated as confidential authentication data and can only be stored for as long as required to process a transaction. Raw PAN expiries are considered cardholder data and are therefore in scope for PCI DSS so they should be encrypted.

Are network tokens supported within Visa's Compelling Evidence 3.0 for chargeback defense/presentation?

If a token is treated as the same credential (or same payment method) for that merchant, then yes, you could use a prior transaction that was tokenized (and undisputed) as part of the footprint. As a merchant, you would still need to capture the required matching data elements (device/IP, etc).

When using PSPs or standalone providers, what would be the PCI DSS requirements for a merchant? Can a merchant on the lowest PCI level store network tokens and payment cryptogram (at least for the time needed to process the payment)?

Cryptograms must be treated as confidential authentication data and should only be stored for as long as required to process a transaction.