Stored cards and tokens
Recurring subscriptions, one-click checkout, automated billings, and on-demand mobility applications rely on charging card credentials without requiring the consumer to manually re-enter their card number. Maintaining payment credentials on file requires specialized encryption architectures, strict compliance certifications, and distinct transaction classification flags.
Card security standards and the PAN
The 16-digit number embossed on physical and virtual payment cards is the primary account number (PAN). Because plain-text PANs represent prime targets for digital theft, handling unencrypted card numbers triggers comprehensive regulatory oversight under the Payment Card Industry Data Security Standard (PCI DSS).
PCI DSS defines stringent physical, operational, and network security requirements for any infrastructure that stores, processes, or transmits cardholder data. Storing raw PANs within internal application databases places systems in PCI DSS Scope Level 1 or 2, necessitating extensive annual on-site audits, continuous vulnerability assessments, and immense potential liability in the event of a security breach.
Consequently, best practice dictates that merchant application servers never touch, process, or store raw PANs. Checkout interfaces capture card data within secure iframes or hosted fields provided directly by the payment processor. The processor ingests the raw card data into its PCI-certified vault and returns an opaque reference string—a token—to the merchant's application.
Tokenization architectures: PSP tokens versus Network tokens
Modern commerce utilizes two distinct tokenization architectures:
- A PSP token (or gateway token) is generated proprietary to a specific payment processor. The merchant stores this token in its internal database and passes it during API calls. However, PSP tokens are functionally useless outside that specific processor's environment. Migrating stored card vaults between competing processors requires executing complex, time-consuming PCI-compliant vault-to-vault transfer protocols.
- A network token is issued directly by the underlying card schemes (Visa, Mastercard, American Express) in coordination with the issuing bank. Network tokens replace the original card PAN with a unique, domain-restricted surrogate number mapped specifically to a single merchant.
Network tokens deliver significant operational advantages over standard processor tokens:
- Dynamic cryptograms: Every transaction processed using a network token includes a single-use cryptographic cryptogram, providing security equivalent to an EMV chip transaction.
- Elevated authorization rates: Issuing banks recognize that network tokens are cryptographically secured and bound to a verified merchant domain, consistently yielding higher authorization approval rates (often 1–3% higher).
- Automated lifecycle management: When a cardholder's physical card is replaced due to expiration, loss, or bank re-issuance, the card network automatically updates the network token's underlying routing in real time. Transactions continue to process without service interruptions.
Digital wallet implementations (such as Apple Pay and Google Pay) utilize device-bound network tokens natively, as detailed in digital wallets.
Managing vault lifecycle: Account Updater services
When utilizing standard PSP tokens, payment vaults naturally degrade over time as credit cards reach expiration dates or are reissued following bank migrations. In subscription commerce, expired cards trigger involuntary churn and failed renewal cycles.
Card networks maintain automated account updater databases. Payment processors query these services prior to scheduled billing cycles to verify card status. If a card has been renewed or replaced, the service returns the updated card expiration date and PAN mapping, allowing subscription renewals to process seamlessly without requiring customer outreach.
Transaction categorization: CIT versus MIT
When initiating transactions against stored payment credentials, card scheme regulations require merchants to classify transactions into two distinct categories:
- A cardholder-initiated transaction (CIT) occurs when the consumer is actively present at the checkout interface and initiates the payment, even if they select a previously saved card token. One-click e-commerce checkouts are CIT transactions. CIT payments can undergo interactive 3-D Secure authentication and achieve liability shifts.
- A merchant-initiated transaction (MIT) occurs when the merchant charges a stored credential without the active participation of the cardholder, pursuant to an agreement established previously. Common MIT transactions include automated monthly subscription renewals, milestone billing, utility meter consumption, and delayed incidental charges.
Because the customer is not present during an MIT transaction, MITs cannot undergo interactive two-factor authentication, exempting them from Strong Customer Authentication (SCA) step-up challenges while conferring zero liability shift.
Secure valid cardholder consent during initial tokenization before executing merchant-initiated charges.
- Present explicit disclosures detailing the billing amount, frequency, and cancellation terms during checkout.
- Process the initial transaction as a cardholder-initiated transaction (CIT), executing 3-D Secure authentication.
- Record and store the transaction network reference identifier returned in the authorization response.
- Reference the stored network transaction identifier in all subsequent merchant-initiated transactions (MIT), flagging the specific MIT subcategory.
Enforcing single-charge execution with idempotency keys
Processing transactions automatically against stored credentials removes the consumer from the execution loop. If an automated background billing daemon experiences a network timeout while calling a payment gateway, the application cannot determine whether the authorization completed or failed. Re-submitting the request blindly risks charging the subscriber twice.
To prevent duplicate billing, payment APIs require an idempotency key—a unique string passed in request headers that uniquely identifies the specific business operation. If an application re-submits a payment request containing an identical idempotency key, the gateway bypasses the card network and returns the cached result of the original attempt rather than executing a duplicate charge.
Terms introduced
- Primary account number: the card number itself, which PCI DSS restricts you from storing. Often shortened to PAN.
- PCI DSS: the Payment Card Industry Data Security Standard, the rules for any system that handles card data.
- Token: a stand-in for a card number that is useless outside the system that issued it.
- Network token: a token issued by the card network for one merchant, domain-restricted, with a fresh cryptogram per use, and updated by the network when the card changes.
- Account updater: a network service that supplies replacement card details for cards a merchant holds on file.
- Cardholder-initiated transaction: a transaction where the customer is present and chooses to pay, including with a stored card.
- Idempotency key: a value attached to a request so a repeated request returns the original result instead of charging twice.
How providers do it
Every payment provider listed below maintains a secure cardholder data vault, allowing merchants to charge stored credentials for recurring subscriptions or one-click checkouts without handling raw Primary Account Numbers (PANs).
Because vault tokens are proprietary identifiers generated inside each provider's secure infrastructure, they cannot be transferred directly to another processor. When evaluating tokenization solutions, the key differentiators are whether the provider automatically requests scheme network tokens and whether it supports real-time card account updater services.
| Provider | Stored card identifier format | Network tokenization and account updater | Status |
|---|---|---|---|
| Stripe | PaymentMethod object (pm_...) attached to a Customer record | Automatically requests network tokens where eligible; includes card account updater | unconfirmed |
| Adyen | storedPaymentMethodId linked to a shopperReference | Built-in network tokenization and automated account updater enabled across global networks | confirmed |
| Braintree | Braintree Vault payment method token (supporting cards and PayPal billing agreements) | Account updater and network tokenization available subject to merchant setup | unconfirmed |
| Checkout.com | Payment Source identifier (src_...) | Automated card updater and network tokenization available via unified API | unconfirmed |
Migrating customer payment credentials between proprietary processor vaults is an intensive technical and compliance project rather than a simple database export. Because raw cardholder numbers can only move between certified PCI DSS Level 1 service providers over encrypted channels, a token migration typically takes several weeks to coordinate. Understanding the friction and provider cooperation policies around vault exports is a vital consideration before centralizing millions of recurring customer profiles within a single processor.
- Stripe
- Adyen
- Braintree
- Checkout.com
What they are: the vault. Card data goes to Stripe from the browser and the merchant holds Stripe's identifiers, which is what keeps PCI scope small.
| Standard term | Their term | Status |
|---|---|---|
| Customer | Customer, cus_… | confirmed |
| Stored card token | Payment method, pm_…, attached to a customer | confirmed |
| Cardholder-initiated | off_session: false, the default for a payment the customer is present for | unconfirmed |
| Merchant-initiated | off_session: true on the payment | confirmed |
| Idempotency key | Idempotency-Key request header | confirmed |
| Question | Answer | Status |
|---|---|---|
| Do they support network tokens? | Yes, transparently, where the network and issuer allow it | unconfirmed |
| Is account updater available, and is it priced? | unconfirmed | |
| Can the vault move to another provider? | Migration is possible through a PCI-compliant transfer, and takes weeks | unconfirmed |
Last verified: never.
What they are: the vault as well as the acquirer, so a stored card lives in Adyen's system and is addressed by Adyen's identifiers rather than the merchant's.
| Standard term | Their term | Status |
|---|---|---|
| Customer | Shopper, keyed by shopperReference | confirmed |
| Stored card token | storedPaymentMethodId, in the Adyen vault | confirmed |
| Cardholder-initiated or merchant-initiated | shopperInteraction | confirmed |
| Why a stored card is being charged | recurringProcessingModel | confirmed |
| Question | Answer | Status |
|---|---|---|
| Do they support network tokens? | Yes, and they request them automatically where they can | confirmed |
| Is account updater available? | Yes, for cards stored in the vault | confirmed |
| Are tokens portable on leaving? | unconfirmed; a storedPaymentMethodId means nothing outside Adyen, so this is a vault migration project | |
| Are tokens shared across merchant accounts? | Scoped per merchant account unless token groups are enabled | confirmed |
The last row catches people out on multi-entity estates. A shopper who saved a card on one merchant account does not have a saved card on another, so the same customer is asked for the card twice and one of those checkouts converts worse.
Last verified: 2026-09-09 against Adyen's public tokenization documentation.
What they are: the vault, and it stores more than cards. A PayPal or Venmo agreement sits in the same vault beside a card token, which is convenient and hides a difference.
| Standard term | Their term | Status |
|---|---|---|
| Stored card token | Payment method token, in the Vault | confirmed |
| Customer | Customer, holding several payment methods | confirmed |
| Default card | Default payment method on the customer | confirmed |
| Question | Answer | Status |
|---|---|---|
| Is a stored PayPal agreement the same kind of thing as a card token? | No. It is a billing agreement with its own consent and its own cancellation path | unconfirmed |
| Does account updater apply to vaulted cards? | unconfirmed | |
| Do network tokens flow through automatically? | unconfirmed | |
| Are tokens portable on leaving? | unconfirmed; a vault migration through PayPal is a project, not a request |
A customer who cancels a PayPal billing agreement from inside PayPal has stopped the renewal without touching anything on the merchant side. The merchant's records still show a stored payment method and a live subscription, so the failure shows up as a declined renewal weeks later.
Last verified: 2026-09-09 against Braintree's public developer documentation.
What they are: the vault as well as the acquirer.
| Standard term | Their term | Status |
|---|---|---|
| Single-use token from the browser | Token, tok_… | confirmed |
| Stored card token | Source, src_… | confirmed |
| Transaction | Payment, pay_… | confirmed |
| Question | Answer | Status |
|---|---|---|
| Do they support network tokens? | unconfirmed | |
| Is account updater available? | unconfirmed | |
| How is a merchant-initiated payment flagged? | unconfirmed; find the field before building renewals, because the flag decides the liability | |
| Are tokens scoped per processing channel? | unconfirmed |
The two prefixes are worth keeping straight in integration code. A tok_ is single-use and expires
in minutes. A src_ is the stored card. Naming both "token" in a database column is how a
renewal job ends up trying to charge something that stopped existing at checkout.
Last verified: 2026-09-09 against Checkout.com's public documentation.