What is a Stored Credential On File (COF)?

COF - Credentials On File API - Peach Payments 

The link below is a breakdown of how the payment request should look with the new parameter

Developer Documentation for more details 


Visa and MasterCard have defined mandatory rules and processing specifications for transactions performed using stored card details. This is to increase transparency, consistency and approval rates for credential-on-file (COF) transactions. Visa and MasterCard have introduced new identifiers for these transactions.

With credential-on-file (COF) transactions, a Primary Account Number Network (for example, Visa, Mastercard) creates a token which is stored stored by a merchant, merchant’s agent, Payment Facilitator or Staged Digital Wallet Operator to process future transactions for the cardholder. Future COF transactions do not require the cardholder to present or enter their payment credential information when they are making a purchase.

With the introduction of the Stored Credential and Merchant-Initiated Transaction Framework, data is presented with authorizations and transactions to identify stored credentials and indicate cardholder consent was obtained. Within these frameworks, transactions are presented as either a Cardholder-Initiated Transaction (CIT) or a Merchant-Initiated Transaction (MIT).


A credential is not considered stored when the credential is used to complete a single transaction or purchase.

Example: Guest Checkout - Cardholder shops at an e-commerce retailer to purchase three items. One item is backordered. The merchant submits two transactions to fulfill the entire order. Cardholder visits the merchant’s website a week later to purchase something; the cardholder has to enter their payment credentials to place the order.


Cardholder-Initiated Transaction (CIT)

With a CIT, the consumer is present and provides their payment credentials for the transaction. A CIT can be submitted through a terminal in store or an online checkout. CITs include proof that the cardholder was involved in the transaction (cardholder validation performed - CVV2, chip data, and so on). A CIT can be performed with a PAN or payment token.

A CIT can be initiated to complete a purchase or create a stored credential. Transactions that fall within the CIT type are limited to normal Sale, Pre-authorization and Account verification.

  • If an amount is due at the time credentials are stored, the CIT is submitted as an authorization for a purchase transaction.
  • If no amount is due when the credentials are stored, the CIT is submitted as an Account Verification.

Merchant-Initiated Transaction (MIT)

A MIT is a transaction that relates to a previous CIT but is conducted without the consumer present and without cardholder validation performed. The MIT must refer to a consumer’s original interaction and include the information from a prior CIT. Through an MIT, a merchant can initiate a transaction without the cardholder’s participation.

Categories for MITs include:

  • Standing-Instruction MITs support pre-agreed cardholder instructions for ongoing purchases of goods or services. Standing Instruction MITs are a follow-up to a CIT; for example, an Unscheduled Credential-on-File (COF) Transaction such as adding funds to a wallet account.
  • Industry-Specific Business Practice MITs support transaction types that are a follow-up to an original cardholder-merchant interaction that was not completed with one single transaction; for example, a Reauthorization (Split Shipment) Transaction.

Transaction Type Examples

  • Apple Pay Samsung Pay, Android Pay Contactless: not considered COF
  • Apple Pay Samsung Pay, Android Pay In-app or e-commerce website: not considered COF
    • Pass-through wallets such as Apple Pay, Samsung Pay, and Android Pay are not considered credential on file whether accepted as contactless or through a merchant website or merchant app.
    • If the cardholder instructs the merchant to store their payment credential during an in-app or e-commerce transaction using the payment credential from their Apple Pay or Android Pay, this would be considered initial storage of a payment credential (token).
  • Visa Checkout transactions: not considered COF
  • Guest Checkout: not considered COF
  • Simplified customer checkout (for example, online retailer stores the cardholder info): Cardholder-Initiated COF
  • Staged Digital Wallet Operator specific to a merchant: COF - could be used for Unscheduled COF, Recurring, Installment, cardholder initiated, full or partial prepayment
  • Transit wallet when amount goes below agreed amount, merchant will replenish: Unscheduled COF
  • Hotel - cardholder has a membership profile with the hotel and provides their card number for future reservations: considered COF
  • Hotel - cardholder provides the payment credential to cover charges (for example, hotel stay, incidentals such as food) associated to that specific reservation only: not COF
  • Drug store in person sale, uses QR code to link consumer to their profile with the merchant: uses stored credential - cardholder initiated
  • AFD mobile in-app purchases: may be COF
  • Recurring, Installment, Unscheduled COF: always COF
  • When the Merchant or its agent uses a payment credential for a single transaction or a single purchase: NOT COF
    • A No-Show Transaction
    • Amended amount or a delayed charge
    • Incremental Authorization
    • Reauthorization Auth Type - Where the merchant (for example, e-commerce merchant split shipment) is allowed to submit a new Authorization Request for the same transaction
    • Resubmission Auth Type - Transaction that received a certain authorization decline response and is resubmitted for authorization, as permitted in the Visa rules