Overview

Card networks — including Visa, Mastercard, and Discover — require merchants that store customer payment credentials to identify how those stored credentials will be used at the time of authorization. This requirement is commonly referred to as the Card on File (COF) mandate.

A Card on File transaction occurs when a merchant stores a customer's card information and later charges that stored credential. Proper COF identification helps issuers and acquirers better assess transaction intent and risk, resulting in higher authorization approval rates, fewer false declines, and improved long-term processing performance.

This article explains what COF transactions are, how they are categorized, what fields are required, which processors support COF on Authorize.net, and how to troubleshoot common issues.

Applicability

This article applies to merchants and developers who:

• Store customer payment credentials and submit subsequent charges via Authorize.net
• Use the Authorize.net API, CIM, or ARB for Card on File or recurring billing workflows
• Process Card Not Present (CNP) transactions using stored credentials

This article does not apply to:

• Virtual Terminal transactions unless network-required COF fields are explicitly included
• Level 2 or Level 3 transaction qualification — COF fields do not affect L2/L3 qualification
• Processors not listed in the Processor Support table below — contact Authorize.net Support for guidance on unlisted processors

Card on File Transaction Types

COF transactions fall into two primary categories based on who initiates the payment.

Cardholder-Initiated Transactions (CIT)

A Cardholder-Initiated Transaction (CIT) is any transaction where the cardholder actively starts the payment and chooses to use a stored card. The initial CIT establishes the stored-credential relationship required for future Merchant-Initiated Transactions (MITs).

Examples of CITs:

• Checking out online using a saved card
• Paying an invoice, pay link, or QR code with stored payment details
• Authorizing a payment over the phone or in person where stored credentials are used

Merchant-Initiated Transactions (MIT)

A Merchant-Initiated Transaction (MIT) is a payment the merchant submits using stored credentials without the cardholder actively participating at the time of the charge. MITs are only permitted after a prior CIT has established customer consent.

MIT types include:

• Standing instructions: Subscriptions and scheduled billing
• Industry practices / ad hoc: Resubmissions, reauthorizations, delayed charges, and no-show fees

Benefits of COF Compliance

Correctly identifying and submitting COF transactions provides the following benefits:

• Helps issuers better understand transaction intent and risk
• Increases authorization approval rates and completed sales
• Reduces false declines and customer disputes
• Improves long-term processing performance for stored-credential transactions

What Merchants Should Do

1. Identify whether a transaction is a CIT or MIT when submitting an authorization or capture request.
2. Include the appropriate network fields that reference the original transaction that established the COF relationship, where required by the network.
3. Retain records of customer consent for MITs and make those records available to acquirers or issuers on request.
4. Work with your developer or payment provider to map stored-credential fields to the Authorize.net API payload as required.

Processor Support and Enablement

COF support on Authorize.net depends on processor implementation and Authorize.net enablement. Processor support may vary by card brand and transaction type.

If your processor is not listed above, contact Authorize.net Support for guidance.

Implementation Notes — Authorize.net Behavior

CIM and ARB Behavior

Customer Information Manager (CIM) and Automated Recurring Billing (ARB) handle many COF indicators automatically when requests include the necessary fields.

• CIM can auto-populate originalNetworkTransId and originalAuthAmount when a prior transaction reference is available.
• ARB identifies subscription transactions as recurring payments automatically.

COF Reference Rules

• The first successful CIT that establishes the stored credential is the reference for all future MITs.
• If the card is updated or replaced, the first successful transaction on the new card becomes the new COF reference.
• Ensure stored references are updated whenever a card is replaced or a token is refreshed.

Interface Notes

• Transactions created via the Merchant Interface Customer Profiles are typically treated as cardholder-initiated.
• Virtual Terminal transactions are not usually classified as COF — use profile-based transactions or ensure network-required fields are present to establish COF classification.

Operational Caveats

• Incorrect or missing COF indicators can cause interchange downgrades or higher decline rates.
• COF implementation is ongoing across processors and networks — verify behavior in your test environments and with your acquirer.

Required COF Fields

The following fields are required by card networks for COF compliance when storing cards or submitting subsequent authorizations. These fields do not affect Level 2 or Level 3 qualification.

COF Processing Flags

Submit processingOptions.isStoredCredentials along with one of the following:

• isFirstRecurringPayment
• isFirstSubsequentAuth
• isSubsequentAuth

Subsequent Authorization Block

Include the following when submitting a subsequent or merchant-initiated authorization:

• subsequentAuthInformation.originalNetworkTransId
• subsequentAuthInformation.reason
• subsequentAuthInformation.originalAuthAmount

Include these fields on the CIT that establishes the stored-credential relationship and on all subsequent or MIT submissions as appropriate. Confirm exact field names and placement for your integration — API payload, CIM, or processor connector — and test end-to-end in sandbox environments.

Best Practices

• Confirm whether your processor connection supports COF and which card brands are supported before relying on COF flows.
• Retain customer consent records for MITs and ensure your refund, cancellation, and disclosure flows meet network rules.
• If using third-party storage, ensure COF indicators and the original transaction reference are present and documented in all requests.
• Test COF flows end-to-end in sandbox or test environments and log originalNetworkTransId and related fields to aid troubleshooting.

Troubleshooting and Common Scenarios

Interchange Downgrades or Declines

Downgrades and declines are often caused by missing COF indicators or required original-transaction references. Verify that originalNetworkTransId and originalAuthAmount are present and that the first CIT exists in the transaction history.

Virtual Terminal Not Treated as COF

Virtual Terminal charges may not be classified as CIT. Use profile-based transactions or ensure network-required fields are present to establish COF classification.

Card Updates or Token Replacement

When a card is replaced or updated, the first completed transaction on the new card becomes the new COF reference. Ensure stored references are updated to reflect the new card.

Resubmissions and Reauthorizations

Mark resubmissions and reauthorizations correctly and include references to the original transaction when networks require it to avoid declines.

Frequently Asked Questions

• • What is a Card on File (COF) transaction?
  • A COF transaction occurs when a merchant stores a customer's card information and later charges that stored credential. COF transactions are categorized as either Cardholder-Initiated Transactions (CIT) or Merchant-Initiated Transactions (MIT), depending on who initiates the payment.
• • Why do I need to identify whether a transaction is a CIT or MIT?
  • Card networks require merchants to identify transaction intent when submitting stored-credential transactions. Correctly identifying CITs and MITs helps issuers assess risk, improves authorization approval rates, and reduces false declines and disputes.
• • Can I submit a Merchant-Initiated Transaction (MIT) without a prior Cardholder-Initiated Transaction (CIT)?
  • No. MITs are only permitted after a prior CIT has established the stored-credential relationship and customer consent. The first successful CIT serves as the reference for all future MITs.
• • Does my processor support COF transactions?
  • COF support depends on your processor and the card brands involved. First Data Nashville, TSYS, and NAB EPX currently support COF on Authorize.net. TSYS support is limited to Card Not Present (CNP) transactions. If your processor is not listed, contact Authorize.net Support for guidance.
• • What happens if I submit a COF transaction with missing or incorrect fields?
  • Missing or incorrect COF indicators can result in interchange downgrades or higher decline rates. Ensure that originalNetworkTransId, originalAuthAmount, and the appropriate processing flags are included in your authorization requests.
• • Are Virtual Terminal transactions treated as COF?
  • Virtual Terminal transactions are not automatically classified as COF. To establish COF classification, use profile-based transactions or ensure network-required fields are explicitly included in the request.
• • What should I do when a customer's card is replaced or updated?
  • When a card is replaced or updated, the first successful transaction on the new card becomes the new COF reference. Update your stored references to reflect the new card to ensure subsequent MITs are processed correctly.
• • Do COF fields affect Level 2 or Level 3 transaction qualification?
  • No. COF fields are related to network stored-credential compliance only and do not affect Level 2 (L2) or Level 3 (L3) qualification.
• • Does CIM or ARB automatically handle COF indicators?
  • Yes, in many cases. CIM can auto-populate originalNetworkTransId and originalAuthAmount when a prior transaction reference is available. ARB identifies subscription transactions as recurring payments automatically. However, you should confirm behavior in your test environment and with your acquirer.
• • Where can I find developer documentation for COF implementation?
  • Refer to the Card on File Transactions Developer Guide linked in the Additional Resources section below.

Additional Resources

• Card on File Transactions Developer Guide — Authorize.net

Appendix — Field Guidance and Definitions

The following fields are related to network stored-credential compliance. They do not impact L2/L3 qualification.

Recommended COF Processing Flags

Submit processingOptions.isStoredCredentials along with one of the following:

• isFirstRecurringPayment
• isFirstSubsequentAuth
• isSubsequentAuth

Subsequent Authorization Data

Include the following when submitting a subsequent or merchant-initiated authorization:

• subsequentAuthInformation.originalNetworkTransId
• subsequentAuthInformation.reason
• subsequentAuthInformation.originalAuthAmount

Include these fields on the CIT that establishes the stored-credential relationship and on all subsequent or MIT submissions as appropriate.

Glossary

• API (Application Programming Interface): A set of protocols and tools that allows software applications to communicate with each other. Used here to submit COF transaction data to Authorize.net.
• ARB (Automated Recurring Billing): An Authorize.net feature that automates the submission of recurring payment transactions on a defined schedule.
• CIM (Customer Information Manager): An Authorize.net feature that securely stores customer payment credentials and profile data for use in future transactions.
• CIT (Cardholder-Initiated Transaction): A transaction actively initiated by the cardholder using a stored card credential.
• CNP (Card Not Present): A transaction type where the physical card is not present at the point of sale, such as online or phone payments.
• COF (Card on File): A stored payment credential that a merchant retains with customer consent to charge at a future date.
• L2/L3 (Level 2 / Level 3): Enhanced data levels for commercial card transactions that may qualify for lower interchange rates. COF fields do not affect L2/L3 qualification.
• MIT (Merchant-Initiated Transaction): A transaction submitted by the merchant using stored credentials without the cardholder actively participating at the time of the charge.
• QR Code (Quick Response Code): A machine-readable optical label used to direct customers to a payment link or checkout page.
• STIP (Stand-In Processing): A process by which Visa's systems authorize transactions on behalf of an issuer when the issuer is unavailable.
• TSYS: A payment processing company that serves as one of the supported processor connections on Authorize.net.