Credential-on-File Payments: How Recurring and Stored-Card Transactions Work

Recurring payments and stored-card transactions are an important part of the payment infrastructure for many online businesses. Subscription services, marketplaces, travel companies, digital services and other merchants increasingly rely on customers being able to make payments without entering their card details every time.

But storing a customer’s card credentials is only part of the process. Subsequent transactions need to be identified and processed correctly so that the payment ecosystem — including the merchant, payment service provider, acquirer, card network and issuer — can distinguish them from a new customer-initiated purchase.

This is where Credential-on-File (COF) and Merchant-Initiated Transactions (MITs) become important.

What is a Credential-on-File transaction?

A Credential-on-File transaction occurs when a merchant stores a customer’s payment credentials, with the customer’s agreement, so they can be used for a future transaction.

Common examples include:

• Subscription payments

• Recurring memberships

• Installment payments

• Stored-card payments

• Account top-ups

• Certain subsequent payments where the customer is no longer actively participating in the transaction

The initial transaction is generally initiated by the customer. Subsequent transactions may then be initiated by the merchant under the agreement established with the customer.

Mastercard’s current transaction-processing rules classify recurring and installment payments as types of Merchant-Initiated Transactions based on a cardholder agreement. citeturn0search33

Cardholder-Initiated Transactions vs Merchant-Initiated Transactions

One of the most important distinctions in modern recurring payment processing is between a Cardholder-Initiated Transaction (CIT) and a Merchant-Initiated Transaction (MIT).

A CIT occurs when the customer is actively involved in initiating the payment — for example, when a customer purchases a product online using a card that has previously been stored by the merchant.

An MIT occurs when the merchant initiates a subsequent transaction based on an agreement that was previously established with the customer.

A typical subscription might therefore look like this:

1. Customer signs up
The customer enters their card details and agrees to the subscription.

2. Initial payment
The customer initiates the first transaction and, where applicable, completes the required authentication.

3. Payment credentials are stored
The merchant retains the payment credential in accordance with the applicable rules and customer agreement.

4. Subsequent subscription payments
The merchant initiates future payments according to the subscription agreement.

This distinction is important because the subsequent transaction is not simply another standard e-commerce card payment. The payment needs to carry the appropriate information identifying its relationship to the original transaction.

Mastercard’s rules require subsequent merchant-initiated transactions to reflect the relevant recurring-payment and/or credential-on-file processing information. citeturn0search35

Why does this matter for online merchants?

A stored-card transaction is different from a customer entering their card details for the first time.

The issuer needs sufficient information to understand the nature of the transaction and, where applicable, its relationship to the original customer-initiated payment.

For merchants operating subscription or other recurring models, correct transaction classification therefore becomes an important part of payment optimisation.

Incorrectly identifying a subsequent transaction can create unnecessary friction in the payment flow and can contribute to avoidable payment failures.

This is particularly important for businesses where the customer’s lifetime value depends on successfully collecting multiple future payments rather than simply completing the initial purchase.

Recurring payments are not all the same

Recurring transactions can involve either fixed or variable amounts.

For example:

• A €20 monthly subscription is a fixed recurring payment.

• A utility subscription where the amount changes each month is a variable recurring payment.

• A software subscription with additional usage charges may involve a combination of recurring and other merchant-initiated transactions.

The way these transactions are classified and submitted therefore needs to reflect the actual commercial agreement and payment flow.

Current Mastercard documentation distinguishes recurring payments, installment payments and other merchant-initiated transaction types. citeturn0search33

The role of the payment service provider

For merchants, correctly implementing credential-on-file payments is not simply a matter of storing a customer’s card.

The payment integration needs to support the relevant transaction types and provide the appropriate information to the payment service provider and acquiring infrastructure.

Depending on the merchant’s business model, this can involve:

• Identifying the initial customer-initiated transaction

• Correctly identifying subsequent merchant-initiated transactions

• Maintaining references to the original transaction

• Identifying recurring or installment payment arrangements

• Handling fixed and variable recurring amounts

• Supporting the relevant authentication requirements

• Correctly transmitting stored-credential information

Mastercard’s current rules, for example, require information linking an MIT to the initial authorisation to be carried through subsequent related authorisations in applicable cases.

Strong Customer Authentication and recurring payments

For European merchants, recurring payments also need to be considered alongside Strong Customer Authentication (SCA).

The initial transaction that establishes a recurring payment agreement may require customer authentication. Subsequent merchant-initiated transactions can then be processed differently because the customer is not actively participating in each individual payment.

The exact treatment depends on the transaction type and applicable rules, so merchants should ensure that their payment provider supports the relevant SCA and MIT flows rather than treating every recurring transaction as an ordinary card payment.

Mastercard’s payment documentation identifies Merchant-Initiated Transactions as subsequent transactions based on an agreement established with the payer, with the payer authenticated during the transaction that established the agreement where applicable. citeturn0search6turn0search14

What should merchants check?

If your business uses subscriptions, stored cards or other recurring payment models, it is worth reviewing how your current payment setup handles credential-on-file transactions.

Questions to ask your payment provider include:

• Are our recurring payments correctly identified as merchant-initiated transactions?

• Are our stored-card transactions correctly classified?

• How is the original customer-initiated transaction referenced?

• Are fixed and variable recurring payments handled correctly?

• How are SCA requirements handled for the initial and subsequent transactions?

• Are we using the appropriate payment data and transaction indicators?

• What happens when a customer’s card expires or is replaced?

• How are failed recurring payments retried?

• Can we monitor authorization and decline rates specifically for recurring and stored-card transactions?

These questions become particularly important as the proportion of revenue generated from existing customers increases.

Optimising recurring payment performance

For a subscription or recurring-revenue business, the first payment is only the beginning of the customer relationship.

A merchant may acquire a customer successfully but still lose revenue later if subsequent payments fail unnecessarily.

Payment optimisation should therefore look beyond the initial conversion and consider the entire payment lifecycle:

Customer acquisition → Initial payment → Credential storage → Subsequent payments → Renewal → Recovery of failed payments

This is where payment infrastructure, transaction classification, issuer behaviour, authentication, card lifecycle management and retry strategies can all have an impact.

For merchants processing significant recurring or stored-card volumes, analysing authorization rates and decline reasons by transaction type can reveal opportunities that are not visible when all card payments are viewed as a single category.

How Gropay can help

Gropay helps merchants and payment businesses evaluate and optimise their payment infrastructure across markets, payment providers and transaction types.

For merchants operating subscription, recurring or stored-card models, this can include reviewing the payment flow, provider capabilities, transaction setup and performance data to identify potential sources of unnecessary payment friction.

If recurring payments represent a significant proportion of your revenue, understanding how those transactions are being processed can be just as important as optimising the initial checkout.

Talk to Gropay about optimising your payment setup and international payment performance.