Credential-on-File (COF)

What Is Credential-on-File?

Credential-on-file (COF) refers to the card network framework that governs how merchants store, flag, and reuse payment credentials for future transactions. While card on file describes the act of storing a customer's payment details, the credential-on-file framework is the set of rules that dictate how those stored credentials must be identified in authorization messages sent through the card network.

Visa introduced its Stored Credential Transaction Framework in 2017, requiring merchants to include specific data elements in every authorization that uses a previously stored card. Mastercard followed with a similar mandate. The goal is straightforward: give issuers better visibility into whether the cardholder is actively participating in the transaction, so they can apply appropriate fraud screening and make more accurate approval decisions.

Before these mandates, issuers often saw stored-credential transactions as opaque: a charge arrived with a card number but no context about whether the customer had just clicked "Buy Now" or whether a merchant was charging a subscription renewal while the cardholder was asleep. The COF framework closes that information gap.

How It Works

The credential-on-file framework operates through transaction indicators embedded in the ISO 8583 authorization message. Every transaction using a stored credential must include two key pieces of information: who initiated the transaction, and whether it is the first or a subsequent use of the credential.

CIT vs. MIT Classification

The most fundamental distinction in the COF framework is between cardholder-initiated transactions (CIT) and merchant-initiated transactions (MIT):

• Cardholder-Initiated Transaction (CIT): the cardholder is actively participating in the transaction at the time it occurs. Examples include clicking "Buy Now" with a saved card, adding items to a cart and checking out, or entering a saved card's CVV to confirm a purchase. The initial transaction that establishes a stored credential relationship is always a CIT
• Merchant-Initiated Transaction (MIT): the merchant submits the transaction without the cardholder being present at that moment. The cardholder previously consented to the arrangement, but is not actively triggering the charge. Subscription renewals, automatic top-ups, and delayed charges after service delivery are all MITs

This classification matters because issuers apply fundamentally different risk models to each type. A CIT can prompt real-time authentication such as 3D Secure, while a MIT bypasses cardholder authentication entirely and relies on the stored consent linkage as proof of legitimacy.

Network Reference IDs

Each card network uses a unique reference identifier to link subsequent MITs back to the original cardholder-consented transaction:

• Visa Network Transaction ID (NTI): a unique identifier returned in the authorization response of the initial CIT. Every subsequent MIT must include this NTI to prove it traces back to valid cardholder consent
• Mastercard Trace ID: a composite reference derived from the Financial Network Code, Banknet Reference Number, and Banknet Settlement Date of the original transaction. Mastercard also assigns a Transaction Link Identifier (TLID) to every authorization, which persists across related messages including captures, refunds, and chargebacks

Without these reference IDs, the issuer has no way to verify that a merchant-initiated charge was properly authorized by the cardholder. Transactions missing the reference ID face higher decline rates and may trigger network compliance monitoring. For a deeper look at how networks handle tokenized credentials, see the payment network tokenization comparison.

MIT Use Cases

Mastercard's framework defines eight standardized MIT use cases, and Visa has a similar taxonomy. The initial CIT must indicate which MIT type will follow:

Using the correct MIT category is critical for interchange qualification. Misclassifying a transaction type can cause a downgrade from the qualified rate to a higher-cost category.

Authorization Message Structure

A typical COF authorization request includes specific fields that distinguish it from a standard one-time payment:

// COF authorization fields in a subsequent MIT
{
  "stored_credential": {
    "usage": "subsequent",           // "first" on initial CIT, "subsequent" on follow-up
    "initiator": "merchant",         // "cardholder" for CIT, "merchant" for MIT
    "reason": "recurring",           // MIT use case category
    "network_transaction_id": "019283746556473829"  // from original CIT response
  },
  "pos_entry_mode": "credential_on_file",
  "pan_or_token": "4444333322221111"
}

// Initial CIT establishing consent
{
  "stored_credential": {
    "usage": "first",
    "initiator": "cardholder",
    "reason": "recurring",
    "network_transaction_id": null   // assigned by network in response
  }
}

Consent Requirements

The COF framework imposes strict consent requirements that govern the entire lifecycle of a stored credential relationship:

1. The initial credential storage must occur during a cardholder-initiated transaction where the customer actively participates and explicitly agrees to have their card stored
2. The merchant must clearly disclose the terms of future charges: frequency, amount (or range), and the type of transactions that will occur
3. The cardholder must be able to revoke consent and have their stored credential deleted at any time
4. Every subsequent MIT must be traceable to the original consent through the network reference ID chain

In the European Union, PSD2's Strong Customer Authentication (SCA) adds another layer: the initial CIT that establishes the stored credential typically requires SCA, while properly flagged subsequent MITs are exempt. The Mastercard Trace ID was required for all subsequent transactions in the EU even before the broader global framework change, specifically to evidence that a customer-authenticated setup occurred.

Impact on Authorization Rates

Proper COF flagging directly affects authorization rates. Issuers use the COF indicators to make more informed approval decisions:

• Transactions with valid network reference IDs linking back to an authenticated initial CIT receive preferential treatment from issuer fraud models
• Recurring MITs with consistent amounts and intervals see higher approval rates than unscheduled MITs with variable amounts, which trigger more scrutiny
• Missing COF indicators force the issuer to treat the transaction as higher risk, often resulting in soft declines that require cardholder re-authentication
• Compliance with the stored credential framework is also required for merchants to benefit from Visa's Real Time Account Updater, which automatically refreshes expired or reissued card details

For subscription businesses, the difference between correct and incorrect COF flagging can translate to several percentage points of recurring billing recovery, directly affecting revenue and involuntary churn.

Use Cases

Subscription Commerce

SaaS platforms, streaming services, and membership businesses depend on COF compliance for every renewal cycle. The initial signup is a CIT flagged as "first" with a recurring MIT type. Every subsequent monthly charge is a MIT referencing the original transaction ID. Getting this chain right is essential for maintaining high approval rates across millions of renewal attempts.

Marketplace and Platform Payments

Platforms like ride-hailing and food delivery apps store credentials during onboarding and charge variable amounts after each service. These are unscheduled credential-on-file MITs, which require the original consent reference but allow flexible timing and amounts. The payment facilitator managing the platform must ensure correct COF indicators flow through to the acquirer.

Hospitality and Travel

Hotels and rental car companies frequently use delayed charge and incremental authorization MIT types. A guest provides their card at check-in (CIT), and the hotel may later charge for minibar usage (delayed charge) or extend the pre-authorization for an extra night (incremental). Each charge type carries its own MIT indicator.

Retry and Recovery

When a recurring charge declines, merchants use the resubmission MIT type to retry. Card networks impose specific rules on resubmission timing and frequency: Visa limits retries to 15 attempts within 30 days for recurring transactions, and Mastercard has similar constraints. Correct resubmission flagging through the COF framework distinguishes legitimate recovery attempts from potential card testing.

Risks and Considerations

Compliance Complexity

Each card network maintains its own COF rules, field names, and enforcement timelines. Visa, Mastercard, and Discover each have slightly different taxonomies and reference ID formats. Merchants operating across multiple networks must implement network-specific logic or rely on their payment processor to abstract these differences. Processors that fail to pass COF indicators correctly can cause merchant-wide downgrade issues.

Interchange Downgrades

Transactions missing required COF indicators may fail to qualify for the best interchange rate category. Instead of receiving the qualified recurring or electronic commerce rate, the transaction falls to a standard or non-qualified tier with higher fees. For high-volume merchants, even small per-transaction downgrades compound into significant cost increases over millions of transactions.

Network Monitoring Programs

Card networks actively monitor compliance at the processor and merchant level. Visa and Mastercard can place non-compliant merchants into monitoring programs that impose additional reporting requirements and potential fines. Persistent non-compliance with COF indicator mandates may trigger escalation within the card scheme mandate enforcement process.

Chain-of-Consent Breaks

If a merchant migrates payment processors, the network reference IDs from the original CIT may not transfer cleanly. This breaks the chain of consent linking subsequent MITs to the original cardholder authorization. Merchants must work with both old and new processors to migrate stored credential references, or re-establish consent with a new CIT, which risks customer friction and increased churn.

Credential-on-File and Stablecoin Payments

The credential-on-file framework exists because card payments require intermediaries to store and manage sensitive credentials on behalf of customers. This creates an inherent tension: merchants need stored credentials for convenience, but storing them introduces compliance burden, breach risk, and network dependency.

Stablecoin and crypto payment architectures sidestep this entirely. In a self-custodial wallet model, the customer authorizes each payment directly from their own wallet without the merchant ever touching or storing a credential. There is no COF framework needed because there is no credential to store: the customer pushes funds rather than authorizing a merchant to pull them. For merchants exploring alternatives to stored credential management, the stablecoin fraud advantage analysis examines how push-payment models eliminate entire categories of card-based fraud risk.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.