Card-on-file

Card-on-file (COF) is a payment arrangement where a merchant or service provider securely stores a customer’s card details (card number and expiry date, or a tokenised reference; the CVV is not stored) after the customer’s initial consent. These stored details are then used to process future payments without requiring the customer to re-enter their card information each time.

Card-on-file is widely used for recurring subscriptions, repeat purchases, and one-click checkout experiences in e-commerce, streaming, ride-hailing, food delivery, and some financial and crypto services that support card funding.

Why card-on-file is used

Card-on-file offers benefits for both customers and merchants.

For customers

• Convenience – no need to re-enter card details for every purchase or renewal.
• Faster checkout – one-click or automatic payments reduce friction at the point of sale.
• Continuity of service – recurring subscriptions (for example, streaming, software, gym memberships) can renew automatically without interruption.
• Predictable payments – scheduled or usage-based charges (for example, cloud services, utilities) can be debited automatically.

For merchants and service providers

• Higher conversion – simpler checkout flows lead to fewer abandoned carts.
• Reduced friction – customers are more likely to complete repeat purchases.
• Predictable revenue – recurring charges improve cash flow visibility for subscription businesses.
• Lower operational costs – fewer manual payment collection attempts and failed transactions.

For these reasons, card-on-file is a standard model in many digital and subscription-based businesses.

How card-on-file works

The card-on-file process typically follows these steps.

1. Initial consent and data capture

• The customer chooses to save their card for future use, often by checking a box such as “Save my card for faster checkout” or “Use this card for future payments”.
• The customer enters their card details (card number, expiry date, CVV) on a secure payment page.
• The merchant explains how the card will be used (for example, for recurring subscriptions, future purchases, or automatic top-ups) and obtains explicit consent.

2. Secure storage or tokenisation

• The merchant does not usually store raw card data on its own servers. Instead:
  • Card details are sent to a payment service provider or card network.
  • The provider returns a token or reference that represents the card.
  • The merchant stores this token, not the full card number.
• This reduces risk and helps the merchant comply with security standards such as PCI DSS.

3. Subsequent transactions

• For future payments, the merchant uses the stored token or reference to initiate a charge.
• Depending on the scheme rules and transaction type, the customer may or may not need to re-authenticate:
  • Recurring fixed-amount subscriptions often have lighter authentication after the first payment.
  • Variable-amount or unscheduled charges may require stronger customer authentication (for example, 3-D Secure) depending on jurisdiction and card scheme rules.
• The customer sees the charge on their statement, usually with the merchant’s name and sometimes a descriptor indicating it is a recurring or stored-card payment.

4. Ongoing management

• Customers can usually view, update, or remove their saved cards in their account settings.
• Merchants must honour requests to delete stored card details and stop future charges (subject to any contractual obligations for ongoing subscriptions).
• If a card expires or is replaced, the merchant or payment provider may offer card-updater services to automatically refresh the stored details, where permitted and with appropriate consent.

Common use cases for card-on-file

Card-on-file is used in many industries and scenarios.

Subscriptions and recurring billing

• Streaming services (video, music, news).
• Software-as-a-service (SaaS) and cloud platforms.
• Gym memberships and wellness services.
• Subscription boxes and regular deliveries.

Repeat purchases and one-click checkout

• E-commerce retailers that allow saved cards for faster future purchases.
• Food delivery and ride-hailing apps that charge per order using a stored card.
• In-app purchases and digital content stores.

Automatic top-ups and balance funding

• Some financial or crypto platforms allow users to save a card to automatically top up a wallet or account balance when it falls below a threshold.
• Prepaid or debit card programmes that auto-reload from a linked funding card.

Usage-based and variable charges

• Cloud computing and API services that bill based on usage.
• Utilities or telecoms that charge variable monthly amounts.
• Marketplaces that charge sellers or buyers on an ongoing basis.

Security and compliance requirements

Because card-on-file involves storing and reusing payment credentials, it is subject to strict security and regulatory requirements.

PCI DSS compliance

• Merchants and service providers that handle card data must comply with the Payment Card Industry Data Security Standard (PCI DSS).
• This includes requirements for:
  • Secure transmission and storage of card data.
  • Access controls and encryption.
  • Regular security testing and monitoring.
• Most merchants use tokenisation and third-party payment providers to reduce their PCI scope.

Customer consent and transparency

• Card networks and regulators require clear disclosure and explicit consent before storing card details.
• Customers must be informed about:
  • What the card will be used for (recurring, future purchases, top-ups).
  • How and when charges will be applied.
  • How to manage or cancel stored-card arrangements.
• Pre-ticked boxes or implicit consent are generally not acceptable for card-on-file setup.

Strong Customer Authentication (SCA) and 3-D Secure

• In jurisdictions such as the European Economic Area, Strong Customer Authentication rules apply to many card payments.
• For card-on-file:
  • The initial transaction that sets up the stored card typically requires SCA (for example, 3-D Secure).
  • Subsequent recurring transactions may be exempt from SCA under certain conditions (for example, fixed-amount recurring subscriptions with the same merchant).
  • Variable or unscheduled charges may require SCA depending on scheme rules and local regulation.
• Merchants must implement flows that comply with these rules while preserving a good user experience.

Dispute and chargeback handling

• Card-on-file transactions can still be disputed by customers (for example, if they do not recognise a charge or believe it was unauthorised).
• Merchants must maintain evidence of:
  • Customer consent to save the card.
  • Clear terms around recurring or future charges.
  • Transaction history and communication with the customer.
• Good record-keeping helps defend against unjustified chargebacks and resolve genuine disputes fairly.

Card-on-file vs guest checkout

Card-on-file differs from guest or one-time checkout.

Guest checkout

• Card details are used for a single transaction only.
• The merchant does not store the card for future use.
• The customer must re-enter card details for each new purchase.
• Lower ongoing risk for the customer, but more friction for repeat purchases.

Card-on-file

• Card details (or a token) are stored for future transactions.
• Enables recurring and one-click payments.
• Requires explicit consent and stronger security and compliance controls.
• More convenient for repeat customers, but requires robust security and clear management options.

Many merchants offer both options, allowing customers to choose whether to save their card.

How card-on-file affects users

From a customer’s perspective, card-on-file shows up in several ways.

During checkout

• An option to “Save this card for future purchases” or “Use this card for recurring payments”.
• Clear information about how the card will be used and how to manage it.
• Initial authentication (for example, 3-D Secure) when the card is first saved.

In account settings

• A “Payment methods” or “Saved cards” section where users can:
  • View saved cards (often with only the last four digits visible).
  • Add new cards.
  • Remove or delete saved cards.
  • Set a default card for future purchases.

On statements and notifications

• Recurring or stored-card charges appear on the card statement with the merchant’s name and descriptor.
• Some merchants send email or in-app notifications before or after charging a stored card, especially for variable amounts or top-ups.

When disputing charges

• If a customer does not recognise a charge, they can contact the merchant or their card issuer.
• The merchant should be able to provide details of the original consent and transaction history.
• Customers can request their card to be removed from file and future charges stopped, subject to any existing contractual obligations.

Good practices for users

To use card-on-file safely and effectively:

• Only save your card with merchants you trust and use regularly.
• Read the terms around recurring or future charges before agreeing.
• Periodically review your saved cards in account settings and remove those you no longer use.
• Monitor your card statements and app notifications for unexpected charges.
• If you cancel a subscription, confirm that future charges will stop and consider removing the saved card.
• Report unrecognised or suspicious charges to the merchant and your card issuer promptly.

Good practices for merchants

For platforms implementing card-on-file:

• Obtain clear, explicit consent before storing card details.
• Use tokenisation and reputable payment providers to minimise security risk.
• Comply with PCI DSS and card scheme rules on stored credentials.
• Implement appropriate authentication flows (for example, 3-D Secure) in line with SCA and local regulations.
• Provide easy-to-use tools for customers to view, update, and delete saved cards.
• Send clear notifications and receipts for recurring and stored-card charges.