Network tokens vs PSP tokens: what changes for repeat payments

Repeat payments are where card acceptance should be easiest. The customer has paid before, the card has been approved before, and nobody needs to type anything. Yet saved cards fail for reasons that have nothing to do with the customer: the card was reissued, the expiry date changed, the issuer is wary of a stored card number, or the merchant moved to a new provider and the saved cards stayed behind.

Tokens are the answer to all of these, but two different kinds of token answer different parts of the problem. This article explains what PSP tokens and network tokens are, what each changes for approval rates and portability, and how to combine them when you work with more than one provider.

What is a PSP token?

A PSP token, sometimes called a vault token, is a reference that a payment provider gives you in place of the card number. The provider stores the real card data in its PCI DSS compliant vault; you store the token against the customer. On the next payment you send the token, the provider looks up the card and sends the card number to the scheme.

PSP tokens do two useful things. They keep card numbers out of your systems, which reduces your PCI DSS scope, and they let returning customers pay without typing their card again. What they do not do is travel. A PSP token means nothing to any other provider, and the issuer never sees it: from the issuer’s side, the payment carries the plain card number.

What is a network token?

A network token is a replacement card number issued by the card scheme’s token service, such as Visa Token Service or Mastercard’s equivalent, on behalf of the issuer. EMVCo, which maintains the industry framework, describes an EMV Payment Token as a unique alternative value to the card number that is constrained in how it can be used, for example to a specific merchant, device or payment scenario.

Three properties matter for repeat payments:

• It is bound to its requestor. Visa describes its tokens as working only with the specific merchant or device they are linked to, so a stolen token is of little use elsewhere.
• It carries a cryptogram. Adyen’s documentation says each network token payment is protected with a single-use cryptogram, which the issuer can validate.
• It survives card changes. Adyen’s documentation says that if the shopper receives a new card because the old one expired or was lost, the network token remains the same.

How do they compare?

	PSP token	Network token
Issued by	The payment provider	The card scheme’s token service
Seen by the issuer	No; the issuer sees the card number	Yes, with a cryptogram
Card reissued or expired	Fails unless an updater refreshes it	Keeps working; the scheme updates the link
Works with another provider	No	Depends on the requestor and the providers
Reduces your PCI DSS scope	Yes	Yes
Effect on approval rates	Indirect, through fewer typing errors	Direct, through fresher credentials and issuer trust

What do network tokens change for approval rates?

Two things.

Fewer declines from stale credentials. Stripe’s guide on authorization rates says network tokens help deliver higher authorization rates by ensuring the latest credential is used, and that card account updater services, which refresh expired or renewed card numbers, reduce declines. Without tokens, those payments return hard declines such as expired card (code 54) or invalid account, and the only fix is for the customer to come back and enter a new card. Many do not.

More issuer confidence. A tokenized payment with a valid cryptogram tells the issuer the credential is being used by the party it was issued to. Visa says its tokens deliver up to a 5% increase in authorization rates and up to a 50% reduction in fraud compared with card numbers, and that more than half of European payments are already tokenized. These are Visa’s own figures; your results depend on your issuers, markets and how much of your volume is repeat business.

Worked example: a year of reissued cards

Example figures, for illustration only.

A subscription merchant has 40,000 customers with saved cards who are billed at least once a month. Suppose 2% of those cards are reissued each month because they expire or are replaced.

	Card numbers only	Network tokens on 70% of cards
Cards reissued in a year	9,600	9,600
Of which kept working by tokens	0	6,720
Customers who hit a stale-card decline	9,600	2,880
Of which never return with a new card (assume 30%)	2,880	864

Under these assumptions, network tokens keep about 2,000 more paying customers a year, before any effect on first-attempt approval rates. The 70% coverage reflects that not every issuer, card and provider supports network tokens.

What changes when you have more than one PSP?

Portability becomes the main question.

PSP tokens lock saved cards to one provider. If the provider has an outage, declines a segment or ends the relationship, you cannot charge those customers through another provider without asking them for their card again. Moving the card data is possible but formal: Stripe’s documentation, for example, says it transfers card data only to another PCI DSS Level 1 compliant processor, which must provide its attestation of compliance or Visa registry listing and an encryption key, and that it does not export payment history or subscriptions.

Network tokens are portable only in some setups. They are bound to the token requestor. If your provider requested them, they may be usable only through that provider. Adyen’s documentation says merchants can forward network tokens to a PCI-compliant third party, such as another payment service provider, which shows it can be done, but each provider handles this differently.

A vault you control solves most of it. If card data sits in a PCI DSS compliant vault at the orchestration layer rather than at one provider, every eligible provider can process a returning customer’s payment. Network tokens then sit on top: used by whichever provider supports them, with the stored card as a fallback.

What else matters for saved cards?

• Consent and the first payment. Card-on-file payments start with a customer-initiated payment in which the customer agrees to store the card. Visa Acceptance Solutions’ guide says merchants must get the customer’s consent to store payment credentials, and that later merchant-initiated payments reference the original transaction. Our credential on file entry explains the terms.
• Authentication. Tokens do not replace 3-D Secure. An issuer can still challenge a payment with a saved card, especially after a long gap or for a larger amount.
• Retries. Retry rules apply per credential. PayPal’s summary of Visa’s excess retry fee notes that trying the card number after a token is declined is not charged as a retry, but the issuer’s view of the account does not change, so the same retry discipline applies. Our article on soft and hard declines covers which codes to retry.
• Deletion. Customers should be able to remove saved cards, and removing a card should remove or suspend its tokens.

Which should you use?

Both, for different jobs:

1. Store cards in a vault you control, at the orchestration layer, so saved cards are not tied to one provider.
2. Use network tokens wherever your processing providers support them, for fresher credentials and issuer trust.
3. Keep the card number as a fallback for providers, issuers or cards without network token support.
4. Measure repeat-payment approval separately from first payments, and track expired and invalid-card declines on saved cards. If they stay high, token coverage is lower than you think.

How does Omno handle saved cards?

Omno Save Card stores cards as tokens in Omno’s PCI DSS compliant environment, at the orchestration layer rather than in one provider’s vault, so a saved card can be routed and cascaded to any eligible provider like a newly entered card. Returning customers pay with a saved card in the hosted checkout, and the issuer can still ask for 3-D Secure in the same flow. Whether a network token is used in an authorization depends on the connected PSP or acquirer, so ask Omno which token types are available for your providers. The tokenization and saved cards page has the details.