What is a Card-on-File Transaction and what is it used for?

In this guide, we’ll review how card-on-file transactions work, examples of where they can be used, and benefits and drawbacks.

What are card-on-file transactions?

Card-on-file (COF) transactions refer to the process of storing cardholder information securely so that it can be used for future transactions without the cardholder having to physically present their card or enter card details again. Therefore, the cardholder authorizes the merchant to store their card information “on file” to initiate payments or refunds.

This can be convenient for both the cardholder and the merchant, as it opens the door for faster checkouts and reduces friction in the payment process. Card-on-file transactions are typically used in e-commerce settings where the cardholder's information is stored with a merchant's payment service provider rather than with the merchant. 

To ensure security, the stored card information must be encrypted. In situations where a merchant is using a payment service provider, a token—rather than the cardholder data—may be provided and stored on the merchant’s backend. By replacing cardholder data with tokens, organizations can reduce their PCI DSS compliance scope considerably. We’ll go more in-depth on tokens in a bit.

How do card-on-file transactions work?

There are two types of card-on-file transactions: 

1. Consumer-Initiated Transactions (CIT) occur when the consumer is present and provides their payment details to the merchant, such as at a POS terminal in-store or on an online checkout page. CITs offer proof that the legitimate cardholder was involved in and authorized the transaction (e.g., presentation of chip data with cryptograms in-store or card verification values like CVV, CVC, or CVV2 for online purchases).

2. Merchant-Initiated Transactions (MIT) require a previous consumer-initiated transaction to take place, which authorizes a merchant to initiate a transaction without the cardholder or additional card validation. This transaction relies on a prior agreement between the customer and merchant that the stored payment information will be used for recurring subscriptions, automated billing, or unscheduled transactions.

Businesses frequently receive customers’ consent to the card-on-file terms by having the customer:

• Fill out an payment form
• Provide their card details over the phone, or
• Enter their card at a POS terminal and sign a receipt

How are card-on-file transactions captured and initiated?

There are several ways to initiate COF transactions as a merchant. The methods, however, will depend on whether the business operates online, in-store, or as a subscription service.

With an in-store or online merchant, customers’ card details may be authorized and stored by:

• Swiping the card for card-present transactions.
• Filling in customer card information for card-not-present transactions.

Merchants store the payment details, or a token, and associate them with a customer profile after making a transaction. Thus, giving permission for their information to be kept on file.

In the case of subscription service businesses, card-on-file payments can be initiated by asking customers to authorize recurring payments.

The main types of COF transactions

• Incremental. This occurs when additional services or products are added during a contract period, such as adding a new line to an existing phone plan.

• Installments. This transaction involves a deferred payment for an individual purchase in which several fixed transactions are scheduled over a specific time period. A common example of this is monthly car payments of $350 for 36 months to pay off a vehicle.

• Delayed. A transaction that occurs after an initial transaction has been processed for products or services, such as fines, service upgrades, or vehicle damages.

• No-show. This transaction occurs when a customer is a no-show for scheduled services at a business and then is charged a no-show fee. For example, if a patient fails to give at least 24 hours notice of canceling or rescheduling their dental appointment, the dentist can charge for services per their agreed terms with the patient.

• Reauthorization. This typically takes place before a partial order is shipped to a customer or a customer extends a service (like a hotel stay).

• Recurring. A recurring payment can be fixed or flexible and has a specific time interval: every 2 weeks, month, quarter, 6 months, or year. A common example is gym memberships.

• Retry. When the first payment attempt is denied due to a low balance, a resubmission can be done to complete a purchase. Each card brand has specific rules regarding how this works and how many days from the original transaction attempt this can be done.

Examples of card-on-file in everyday businesses

There are several uses for card-on-file transactions, which can generally be broken down into recurring and one-off transactions.

Recurring payments

If a business needs to collect payments on a repeat basis, storing card details on file can make the process much easier. Examples of recurring payments include:

• Subscriptions: subscription services like Netflix and Spotify store details for card-on-file transactions to collect regular payments from customers.

• Memberships: a gym, for example, may use card-on-file to collect monthly membership dues.

• Installments: if paying for something in installments, the business collecting the payments could use card-on-file transactions until the balance is paid off.

• Repeat purchase: card details stored on apps like Lyft and DoorDash allow customers to use that service without giving their details every time they make an order.

One-off payments

Card-on-file isn’t just for recurring purchases. There are also times when it can be used for one-off transactions:

• Fines or fees: when booking a hotel or restaurant, you might have to pay a fine using card-on-file if you fail to show up for your reservation or cancel with too short of notice. 

• Upsells: a gym, for example, may use stored card details for purchasing add-ons like equipment.

The benefits of card-on-file payments

Aside from receiving consistent and timely payments from customers, there are other card-on-file benefits for businesses.

1. Improving customer experience and conversion

By offering customers the option to store their payment cards, they can quickly and easily complete future purchases with just a few clicks—no need to enter card numbers, expiration dates, CVV codes, or other sensitive information. This is a great way to boost sales and customer loyalty by providing a frictionless and convenient experience for shoppers.

2. Improving business efficiency and predictability

Card-on-file transactions make it easy for businesses to ask for customers’ payment information once, save it, and then use it to maintain a stream of revenue. Thus, this payment solution makes it easier to forecast total monthly revenue, and plan expenses accordingly. In turn, businesses can make more effective decisions regarding revenue outlooks, staff management,  and operational improvements.

3. Saving time

Managing payments is one of the many tasks required to run a successful business. If you offer a wide range of products or services, it can quickly become overwhelming to ask for customers’ credit or debit card information each time. To save time, offering card-on-file transactions prevents chasing down people to collect payments. With extra time saved, companies can focus their time and energy on their goals, such as gaining new customers, developing new products or services, and achieving sustainable growth.

Card-on-file disadvantages

Card-on-file payments do have some drawbacks.

1. PCI scope considerations

Accepting debit or credit cards will inherently bring your business into scope with the Payment Card Industry Data Security Standard. Fortunately, many payment service providers (PSP), like Stripe and Adyen, provide tools and services that significantly reduce the effort to be PCI DSS compliant by storing the original cardholder data in their compliant infrastructure and issuing back tokens for merchants to share. While their platforms work great for small-to-medium-sized e-commerce solutions, using cardholder data for other purposes, like sending payments to other PSPs or partners, is impossible without taking back on significant PCI scope. To have full control and future optionality in your payment stack, you’ll need to decouple cardholder data from your PSP provider, either by building and maintaining your own cardholder data environment or using a tokenization service provider (more on this in a bit).

2. Processing fees

Major card networks charge transaction processing fees, which would incur each time a card-on-file transaction processes. If a payment fails, the business is still on the hook for the processing fee of not only that failed payment, but all retries. Especially with lower-ticket items, this fee structure may not be sustainable for most organizations as the fees could outweigh the benefits. Businesses may find that direct debit is a cheaper solution for collecting recurring payments that are smaller.

3. Card processing failures

Card-on-file transactions could unexpectedly fail when the customer changes their card - either due to its expiration date coming around regularly, losing it, or in case of theft. Reminding consumers to update their cards prior to expiration could help alleviate this issue. Fortunately, companies like Knot API, can help. 

Card-on-file with tokenization service providers

In recent years, tokenization has become a popular mechanism for merchants and platforms to enjoy the flexibility of COF transactions without absorbing the PCI DSS costs, risks, and distractions required to store cardholder data. 

Traditionally, the process works by swapping a sensitive data value, like a Primary Account Number (PAN), with an irreversible token or string. The token can then be stored and exchanged with another service, like a PSP, with payment instructions to initiate a payment. This keeps your systems out of scope while allowing you to use the token with your PSP to initiate transactions. Unfortunately, PSP tokens are unique to the PSP that generated them, so a token generated by PSP A can’t be used with Partner B or PSP C.  

To optimize your payments stack, companies, like Melio and Maxio, are turning to tokenization service providers, like Basis Theory. These companies generate tokens and provide similar infrastructure, tools, and services as PSPs, but without handcuffing their tokens' utility to a single PSP. By providing customers with a secure and compliant cardholder data environment to store, process, and route payments, customers of these services get the same PCI scope as working with a PSP and control over their cards-on-file without the costs and distractions of building their own PCI-compliant environment.   

Interested in learning more? Check out our PCI Blueprint and see how you can stand up your own PCI-compliant cardholder data environment (CDE) and card capture forms in less time than your daily standup.