3-D Secure, tokenisation and mobile-wallet provisioning

3-D Secure, tokenisation and mobile-wallet provisioning are three different mechanisms that people often blur together. 3-D Secure authenticates the cardholder. Tokenisation protects the card credential by replacing the real number with a stand-in. Wallet provisioning loads a token into a device wallet and depends on the issuer, processor and network all participating. None of this happens automatically, and each choice has fraud and customer-experience consequences. This guide explains how the pieces fit and what to design deliberately.

Card-on-file tokenisation

Card-on-file tokenisation replaces a stored card number with a token so that merchants, gateways and platforms can keep a credential on file without holding the raw PAN. Different token vaults produce different tokens, and a merchant token is generally scoped to that merchant. This reduces the blast radius if a store of credentials is compromised, but it is not a substitute for the network-level tokens described next.

Network tokenisation

Network tokens are issued by the card networks and can be used across the ecosystem rather than being tied to a single merchant. Because a network token maps to the underlying card without exposing it, it can improve resilience when the underlying card is reissued and can affect authorisation outcomes. Network tokenisation requires participation from the issuer and processor; it is not something a merchant simply switches on alone.

Device tokens

A device token is a token bound to a specific device — for example, a card provisioned into a phone’s wallet. The device token is distinct from the underlying card and from a merchant card-on-file token. Because it is device-bound, its risk profile differs, and lifecycle events (a lost device, a re-provisioned wallet) must be handled specifically.

Token vaults

A token vault is the system that stores the mapping between tokens and the real card credential and enforces who may detokenise. Vaults may be operated by the network, the processor or a dedicated token service provider. Understand who operates each vault your programme relies on, how access is controlled, and how tokens are scoped, because that determines both security posture and operational dependencies.

Lifecycle updates

Cards get reissued, expire, are blocked or replaced. Token lifecycle management propagates these changes to the relevant tokens so that a valid card-on-file or wallet token keeps working after a reissue, and a cancelled card’s tokens stop working. Without lifecycle updates, tokens drift out of sync with the underlying card, causing avoidable declines. Confirm how your processor and network handle lifecycle events.

3-D Secure

3-D Secure is a messaging protocol that lets the issuer authenticate the cardholder during a transaction, most commonly for online (card-not-present) payments. It involves the merchant/acquirer side, a directory operated by the network, and an access control server on the issuing side. 3-D Secure is one common way to meet strong customer authentication requirements set out in EU delegated legislation 1.

Authentication versus authorisation

Authentication and authorisation are separate steps. Authentication answers “is this the legitimate cardholder?” (often via 3-D Secure). Authorisation answers “should this specific transaction be approved?” (checked by the issuer/processor against balance, controls and fraud rules). A transaction can be authenticated and still be declined at authorisation, or vice versa. Designing the two independently avoids confusing customers and misreading decline reasons.

Exemptions

The EU strong-customer-authentication framework contemplates certain exemptions from applying authentication to every transaction, applied on a risk and category basis 1. Conceptually, exemptions let lower-risk transactions proceed with less friction, but whether and how an exemption applies is a rules-driven decision made by the parties in the flow. Treat exemptions as a configuration and governance topic, not a way to switch authentication off, and confirm how your issuer/processor supports them. The underlying payment-services framework sits behind these obligations 2.

Frictionless and challenge flows

3-D Secure supports a frictionless flow, where the issuer authenticates based on data without prompting the cardholder, and a challenge flow, where the cardholder must complete a step (such as approving in their banking app). More challenges can reduce fraud but add friction and abandonment. Tuning the balance is an ongoing exercise, not a one-time setting.

Wallet provisioning

Loading a card into a mobile wallet (device provisioning) requires the issuer, processor and network to support the wallet, and it is subject to the wallet operator’s own requirements and approval. Provisioning typically involves verifying the card and the cardholder before the device token is issued. It is not automatic, and support for one wallet does not imply support for another.

In-app provisioning

Some programmes offer push provisioning — a button in your own app that adds the card to the device wallet without the user re-keying details. This improves the customer experience but requires specific processor and network capabilities and integration work. Confirm availability rather than assuming it comes for free with issuing.

Token requestors

A token requestor is an entity authorised to request tokens for a defined use (a wallet operator, a merchant, a platform). Each token requestor is registered and identified, which lets the network and issuer apply rules per requestor. Knowing which token requestors are involved helps you reason about scope, risk and where a given token can be used.

Issuer, processor and network dependencies

Every capability here — network tokens, device tokens, 3-D Secure, wallet provisioning — depends on the issuer, processor and network all supporting it. A gap in any one blocks the feature. Before promising a capability to customers, verify support end to end across the chain, as described in card issuing explained.

Fraud and customer-experience trade-offs

Authentication and tokenisation choices trade fraud reduction against friction. Aggressive challenging lowers some fraud but raises abandonment and support load; permissive settings do the opposite. These decisions interact with your broader monitoring and controls — see KYC, KYB and transaction-monitoring architecture — and should be tuned with data, then reviewed regularly rather than set once. The commercial context for card programmes is covered in how to choose an EMI or BaaS provider.

• Card-on-file vs network vs device token roles documented for your flows
• Token vault operators and detokenisation access identified
• Token lifecycle updates confirmed across processor and network
• 3-D Secure ACS provision confirmed on the issuing side
• Authentication and authorisation treated as separate steps
• Exemption handling understood as configuration and governance
• Frictionless vs challenge tuning owned by a named team
• Wallet provisioning support verified per wallet, end to end
• Push (in-app) provisioning availability confirmed
• Fraud/experience trade-offs monitored with data over time

Responsibility matrix

Capability	Typical owner	What to confirm
Card-on-file tokens	Merchant / gateway vault	Token scope and vault operator
Network tokens	Network + issuer/processor	End-to-end support and lifecycle
Device tokens	Wallet + issuer/processor	Provisioning and device binding
Token vault	Network / processor / TSP	Access control and detokenisation
Lifecycle updates	Processor + network	Propagation on reissue/cancel
3-D Secure (ACS)	Issuer / processor	ACS provision and challenge design
Exemption handling	Issuer / processor	Rules-driven configuration
Wallet provisioning	Wallet operator + issuer	Approval and per-wallet support
Push provisioning	Processor / your app	Integration and availability
Fraud/experience tuning	Your team + provider	Data, thresholds, review cadence

Questions to ask providers

• Which token types do you support: card-on-file, network and device tokens?
• Who operates the token vault, and how is detokenisation access controlled?
• How are token lifecycle events (reissue, cancel, expiry) propagated?
• How is 3-D Secure provided, and can you support both frictionless and challenge flows?
• How do you support strong-customer-authentication exemptions as a configuration?
• Which mobile wallets do you support today, and what does provisioning require?
• Do you support push (in-app) provisioning from our own app?
• What data and controls are available to tune the fraud/experience balance?
• How do authentication outcomes and authorisation outcomes surface separately in reporting?

Common failure modes

• Treating 3-D Secure authentication and authorisation as the same step.
• Assuming Apple Pay or Google Pay provisioning is automatic or guaranteed.
• Ignoring token lifecycle updates, so reissued cards cause avoidable declines.
• Not knowing who operates the token vault or who can detokenise.
• Over-challenging every transaction and driving abandonment.
• Promising a wallet or token capability before verifying support across issuer, processor and network.

What this does not cover

This guide explains how these mechanisms work in general terms. It does not make a PCI compliance determination, does not certify any specific implementation, and does not confirm that a given wallet will approve your programme. It complements — but does not replace — scheme documentation and advice tailored to your programme.

FAQ

Is 3-D Secure the same as authorisation?

No. 3-D Secure authenticates the cardholder; authorisation decides whether a specific transaction is approved. A payment can pass one and fail the other, so they should be designed and monitored separately.

Will my cards work in Apple Pay or Google Pay automatically?

No. Wallet provisioning depends on the issuer, processor and network supporting the wallet and on the wallet operator’s own requirements and approval. Support for one wallet does not imply support for another.

What is the difference between a merchant token and a network token?

A merchant (card-on-file) token is generally scoped to one merchant’s vault. A network token is issued by the card network and can be used more broadly, with support from the issuer and processor. They serve different purposes.

Do exemptions mean I can skip authentication?

No. Exemptions are a rules-driven configuration that may reduce friction for lower-risk transactions within the strong-customer-authentication framework 1. They are governed decisions made by the parties in the flow, not a way to turn authentication off.

Why do reissued cards sometimes cause declines?

If token lifecycle updates are not propagated, tokens can drift out of sync with the underlying card after a reissue, causing declines. Confirm how your processor and network handle lifecycle events.