What Is Card on File? How Stored-Credential Transactions Work — and How to Keep Them From Failing

Card on file (CoF) is a permission-based arrangement that allows a merchant to securely store a customer’s payment credentials and use them for future charges. The credential is normally tokenized and held in a PCI DSS–compliant vault, rather than stored as a raw card number in the merchant’s application.

Most subsequent stored-credential charges are processed as merchant-initiated transactions (MITs). The initial authorization establishes the customer’s consent, while later transactions must carry the correct stored-credential indicators so the issuer can understand why the card is being charged.

Card on file is one part of the broader recurring payment processing lifecycle. This article focuses on the stored-credential mechanics, including MIT vs CIT, tokenization, SCA, retries, and cross-border authorization.

What is card on file?

A card-on-file payment occurs when a merchant charges a payment credential that the customer previously authorized the merchant to retain.

Under the EMVCo Stored Credential Framework, card-on-file transactions are classified according to how and why the stored credential is used. These classifications are reflected in the authorization message sent to the issuer.

Common categories include:

• Recurring: fixed or predictable payments collected on an agreed schedule, such as SaaS subscriptions or memberships.
• Installment: a fixed total divided into an agreed number of scheduled payments.
• Unscheduled credential on file (UCOF): payments where the amount or timing varies, such as ride-hailing charges or account top-ups.
• No-show: a charge applied when a customer does not attend a reserved service.
• Delayed charge: a charge submitted after the original service or transaction.
• Resubmission: a previously declined transaction submitted again under permitted conditions.
• Reauthorization: a new authorization associated with an existing stored-credential relationship.

Card on file is an authorization relationship, not a type of token. Treating every stored payment as the same transaction type can lead to incorrect indicators, unnecessary declines, and weaker dispute positioning.

How card-on-file payments work

A properly implemented card-on-file flow generally follows five steps.

1. Collect the credential with clear consent

The customer enters a card during checkout, account creation, or subscription sign-up and agrees that the merchant may use it again.

The consent terms should clearly explain:

• What the customer is paying for
• The amount or method used to calculate it
• The charging frequency
• How the customer can cancel
• How refunds and disputes are handled

Future charges should be linked to a clear and recorded customer authorization.

2. Tokenize and store the credential securely

In a well-designed integration, the merchant does not retain the raw primary account number directly.

A payment provider or PCI-compliant vault replaces the card number with a non-sensitive token. The application uses that token when it needs to initiate a future payment.

Tokenization helps reduce exposure to card data and can reduce the merchant’s PCI DSS scope, depending on the integration model.

3. Flag the initial transaction

The first transaction is normally a cardholder-initiated transaction (CIT) because the customer is actively present and choosing to save or use the card.

The authorization message should indicate that:

• The customer is initiating the transaction
• The credential will be retained
• Future merchant-initiated charges may follow

If the initial transaction is not correctly identified, later MITs may appear unrelated to any customer consent known to the issuer.

4. Submit later charges as MITs

Subsequent charges are submitted as merchant-initiated transactions when the merchant triggers the payment without the customer actively participating at that moment.

Each transaction should use the appropriate category, such as recurring, installment, or unscheduled credential on file.

The correct indicator helps the issuer assess the payment in context and can affect authorization, authentication treatment, and dispute handling.

5. Confirm, retry, and refresh

After each charge, the merchant should:

• Send a receipt or payment confirmation
• Record the transaction result
• Interpret the issuer response
• Retry recoverable failures at an appropriate time
• Refresh outdated card credentials where possible

Account-updater services such as Visa Account Updater and Mastercard Automated Billing Updater can help replace outdated credentials when a card expires or is reissued.

MIT vs CIT: why the distinction matters

Every card-on-file transaction should be identified as either a cardholder-initiated transaction or a merchant-initiated transaction.

Cardholder-Initiated Transaction

A CIT occurs when the customer is actively involved in the payment.

Examples include:

• Saving a card for the first time
• Completing an online checkout
• Confirming a purchase inside an application
• Updating a stored payment method

In markets subject to Strong Customer Authentication requirements, the initial CIT may need to be authenticated using 3D Secure 2.

Merchant-Initiated Transaction

An MIT occurs when the merchant charges a previously stored credential without the customer actively initiating the transaction at that moment.

Examples include:

• Monthly subscription renewals
• Usage-based billing
• Scheduled installment payments
• No-show fees
• Delayed charges
• Approved resubmissions

Properly linked MITs may qualify for an SCA exemption in relevant markets, provided that the initial CIT was correctly authenticated and the appropriate indicators are included.

Incorrect MIT or CIT classification can contribute to more declines, downgraded processing, and weaker dispute rights.

Card on file vs network tokens vs PAN tokenization

Card on file, network tokenization, and PAN tokenization describe different parts of the payment setup. They can be used together, but they should not be treated as interchangeable terms.

Card on file

Card on file is the commercial and authorization arrangement between the merchant and the customer.

It includes:

• Customer consent
• Stored-credential indicators
• MIT and CIT classification
• Rules governing future charges

Card on file is not itself a token.

Network tokenization

A network token is issued and managed by a card network, such as:

• Visa Token Service
• Mastercard Digital Enablement Service
• American Express Token Service

The network token replaces the underlying card number during payment processing.

Because the token is linked to the card network, it may continue working when the underlying card is replaced or reissued. Checkout.com has referenced an American Express figure indicating an approximately 2.75% authorization uplift for tokenized card-on-file transactions. This should be treated as a directional industry figure rather than a universal result.

PAN tokenization

A PAN token is typically issued by a gateway, vault, processor, or orchestration provider.

It replaces the card number inside the merchant’s payment environment and supports security and PCI DSS scope reduction. However, a standard vault token does not automatically provide the same network-level lifecycle management as a network token.

Comparison table

The strongest setup may combine all three: a card-on-file agreement, a network token used as the payment credential, and a PCI-compliant vault supporting secure storage and retrieval.

Where businesses use card on file

Card-on-file payments support business models where asking customers to re-enter payment details for every purchase would add unnecessary friction.

Common use cases include:

• Subscriptions and memberships: SaaS, streaming, gyms, and learning platforms
• Usage-based billing: AI services, API platforms, and cloud software
• Marketplaces and on-demand services: transportation, delivery, and service platforms
• Travel and hospitality: bookings, incidental charges, delayed charges, and no-show fees
• Installment plans: an agreed total divided across multiple billing cycles
• In-app purchases: one-click purchases using a previously saved credential
• B2B repeat billing: agencies, professional services, and recurring invoices

From the customer’s perspective, the experience may look like simply “saving a card.” At the payment-network level, it creates a stored-credential relationship with consent, classification, and authorization requirements.

Why card-on-file charges fail

Card-on-file payments can fail even when the initial transaction was successful.

TrueLayer, citing Recurly, has noted that card payment failure rates can reach up to 14% in some circumstances. For subscription businesses, these failed payments can create involuntary churn when a customer intends to continue but the renewal does not clear.

Common causes include:

Expired or replaced cards

The underlying card may expire, be replaced after fraud, or receive a new account number.

A vault token that still points to outdated credentials may stop working unless the payment provider supports an account updater or network-token lifecycle management.

Incorrect stored-credential indicators

An issuer may decline a subsequent charge when it cannot connect the transaction to the original customer authorization.

This can happen when:

• The initial CIT was not correctly flagged
• The later payment uses the wrong MIT category
• Required reference information is missing
• The stored-credential chain is broken

Missing authentication on the initial CIT

In the EU and UK, the initial customer-initiated payment may require SCA.

If the initial transaction is not properly authenticated, subsequent MITs may not qualify for the expected exemption and can face additional declines.

Cross-border issuer risk controls

The customer’s issuing bank may see a foreign merchant, unfamiliar acquirer, or unusual transaction pattern.

Even valid recurring transactions can be declined when the issuer cannot confidently recognize the merchant or transaction context.

Unclear billing descriptors

A customer may dispute a valid recurring payment when the descriptor on the card statement does not match the brand they recognize.

A clear billing descriptor can reduce confusion, customer support requests, and avoidable disputes.

How to recover failed card-on-file payments

A recovery strategy should respond to the reason for the failure rather than repeatedly submitting the same payment.

Use network tokens where available

Network tokens can support credential lifecycle management and may continue working when the underlying card changes.

They can also provide the issuer with additional transaction context compared with an outdated raw PAN.

Use account-updater services

Services such as Visa Account Updater and Mastercard Automated Billing Updater can refresh changed card details before the next billing attempt.

This helps prevent an expired or replaced card from turning into an unnecessary cancellation.

Send the correct indicators

The merchant and payment provider should verify that:

• The first transaction is identified as the initial CIT
• The credential-storage relationship is established
• Each later MIT uses the correct category
• Required references connect the MIT to the original authorization

Apply intelligent retry logic

Retrying immediately and repeatedly can increase issuer declines and create unnecessary network pressure.

A better retry strategy considers:

• Issuer response codes
• Whether the decline is soft or hard
• Local time and billing date
• Card network rules
• Route or acquirer availability
• The time elapsed since the previous attempt

Keep the descriptor recognizable

The descriptor should match the brand or service name the customer expects to see.

For subscriptions, merchants should also send renewal notices and payment receipts so customers can easily connect the charge to the service.

Cross-border card on file

Card-on-file rules may appear similar across markets, but authorization performance can vary significantly when the issuer, merchant, and acquirer are in different countries.

Industry analysis cited by PaymentsJournal has placed cross-border card authorization at approximately 80–90%, compared with 95–99% for locally acquired payments. The actual result depends on the merchant category, issuer mix, market, fraud profile, and payment setup.

For subscription and repeat-payment businesses, the difference compounds across billing cycles.

Acquirer location matters

Processing a transaction through an acquirer that has local or regional issuer relationships may improve how the payment is recognized.

A single overseas acquiring route can underperform when a business expands into several markets.

The routing layer is explained in more detail in the HaiPay guide to payments orchestration.

Network tokens can improve credential continuity

Network tokens can remain connected to the underlying account when a physical card is reissued, where the relevant network and issuer support lifecycle updates.

This reduces the risk that an otherwise valid recurring relationship fails because the card number changed.

Local payment methods may be more suitable

International cards are not the default recurring-payment method in every market.

Depending on the country and business model, merchants may also need:

• Direct debit
• Account-to-account payments
• Pay-by-bank services
• Digital wallets
• Local recurring mandates

The HaiPay guide to alternative payment methods explains how these payment options differ across markets.

A card-on-file setup designed for one domestic market may require local acquiring, tokenization, and additional payment methods before it can perform consistently across borders.

Security and compliance requirements

Card-on-file payments involve several overlapping security and compliance requirements.

PCI DSS

Any organization that stores, processes, or transmits cardholder data must consider its obligations under PCI DSS.

Tokenization can reduce the amount of sensitive data handled directly by the merchant, but it does not automatically remove every PCI DSS responsibility.

The merchant should confirm the applicable scope with its payment provider and qualified compliance advisers.

SCA and 3D Secure 2

In markets governed by SCA requirements, the initial CIT will generally require authentication unless another exemption applies.

A properly established MIT may qualify for an exemption from additional customer authentication, but the transaction must still:

• Be connected to valid customer consent
• Use the correct MIT indicator
• Include the required transaction references
• Follow the applicable card-network rules

Card-network stored-credential rules

Visa, Mastercard, American Express, and other schemes publish their own stored-credential and MIT requirements.

These rules may address:

• Initial and subsequent transaction indicators
• Customer disclosures and consent
• Cancellation mechanisms
• Credential retention
• Resubmission conditions
• Dispute and liability treatment

A low-cost implementation that omits these requirements can create higher decline rates, compliance gaps, and weaker dispute outcomes later.

How HaiPay supports card-on-file payments

HaiPay provides subscription payment and acquiring capabilities that can support card-on-file use cases across multiple markets.

Available capabilities include:

• Failed-payment retry logic that can adjust timing and routing for recoverable transactions
• BIN detection and 3D Secure matching to support authentication decisions
• Authorization optimization using transaction, routing, and message-level factors
• Fixed-cycle, usage-based, and hybrid subscription billing
• Subscription lifecycle management, including trials, plan changes, cancellations, refunds, and payment recovery
• International card and local payment-method coverage
• Payment Links for remote and invoice-style payment collection
• API-based integration for subscription and recurring-payment workflows

HaiPay’s published subscription information includes support for Visa, Mastercard, American Express, JCB, and UnionPay, alongside local payment methods in multiple markets.

Published pricing and settlement terms may vary by market, merchant profile, and commercial agreement. Businesses should confirm the current terms during onboarding.

Book a demo to discuss card-on-file and subscription payment requirements for specific markets.

Developers can also review the HaiPay Subscription API documentation.

Related reading

• Recurring Payment Processing
• Alternative Payment Methods

Sources

• EMVCo specifications and resources
• PCI Security Standards Council
• Visa Account Updater overview
• Checkout.com: Card-on-file transactions explained
• TrueLayer: What are card-on-file transactions?
• Orchestra Solutions: Considerations for international payment processing
• HaiPay Subscription Payments
• HaiPay Subscription API