What can we help you with?



05/04/2022 19:45 PM






Authorize.Net is currently in the process of implementing support for the Visa, MasterCard, and Discover Card on File (COF) for Customer Initiated Transaction (CIT) and Merchant Initiated Transaction (MIT) as well as the separate Purchase Returns Authorization (PRA) Mandates. This article will provide you with the latest, up-to-date information available as well as links to available resources for more information. It is worth noting that:


  • Each processor connection is being updated independently, as each connection is unique and requires care in ensuring that the required fields are supplied according to your processor's specifications.
  • This article will update you with information on whether your processor connection has been updated for compliance of these mandates.

*If you are unsure which processor you are using, please contact your Merchant Service Provider to inquire

Mandate Who does it apply to? Applicable Card Types Estimated Date of Support Notes
Card on File (COF)
  • Customer Initiated Transaction (CIT)
  • Merchant Initiated Transaction (MIT)
Merchants who use:  
  • Visa
  • MasterCard
  • Discover     

First Data Nashville: 9/4/2020

NAB EPX: 1/24/2022




All Other Processor Connections: 
Contact Support

ARB & CIM Support

First Data Nashville: Completed 3/29/2022

NAB EPX: Completed 1/22/2022

For more information, please see our API Reference & Developer Guides

Purchase Returns Authorization (PRA)
aka Online Refunds
Merchants who
  • process refunds through their Authorize.Net account via API or the Merchant Interface
  • MasterCard
  • Visa
  • Discover

First Data Nashville: 2/17/2022

All Processor Connections: 
Contact Support

First Data Nashville was updated for only Visa and Discover.

MasterCard DSRP Token Cryptogram
Merchants who
  • process Apple Pay, Google Pay and/or full PAN tokenized transactions with a CreateTransactionRequest
  • MasterCard
All Processor Connections: 
Contact Support


Card on File (COF) Overview

Visa, Mastercard and Discover have released a set of mandated requirements for merchants who store customer payment credentials for possible future use. There are two "types" of transactions that are processed using stored credentials:

Cardholder Initiated Transactions Using Card on File
A Cardholder Initiated Transaction (CIT) is any transaction where the cardholder actively initiates a transaction. This can be paying online, in a store, over the phone or through a pay link/QR code, etc. In a Card on File transaction, the cardholder initiates a transaction, opting to pay using card information previously used and stored on file with the merchant. 

Merchant Initiated Transactions Using Card on File
A Merchant Initiated Transaction (MIT) is a payment initiated by a merchant without the cardholder. To do this, the cardholder must have previously given the merchant permission to store their card details for use in certain types of future payments. This means that an MIT can only happen after a cardholder has previously completed a CIT with the merchant. MITs can be split into two kinds of transactions: 

  • Standing Instructions
  • Industry Practices

Standing Instructions
These are transactions that reuse the cardholder's credentials on a regular basis or after a certain event occurs. Examples of Standing Instructions are:

  • Recurring Payments - transactions processed according to a fixed interval and fixed amount agreed upon by the cardholder and merchant. Recurring Transactions don't have a specified duration and can continue to be processed until the cardholder cancels the agreement
  • Unscheduled Card on File Transactions - transactions processed for a fixed or variable amount that are not tied to a schedule or recurring transaction date, but to a pre-defined event. For example, when your coffee rewards account falls below a certain minimum and your card automatically gets charged to reload the account balance 

Industry Practice Transactions  
These are transactions that reuse the cardholder's credentials on an ad hoc or one-off basis, with previous consent from the cardholder. Examples of Industry Practice Transactions are:

  • Resubmissions - used when the original authorization is not successfully funded to the merchant but goods or services were provided
  • Reauthorizations - used to obtain a new authorization after the previous authorization has expired
  • Delayed Charges - processes an additional charge after the original transaction has been completed
  • No Show - used to collect penalty fees for not showing up for a reservation or cancellation in accordance with the merchant's cancellation policy

Benefits of COF Mandate Compliance

  • Recognizing stored card, or credential, transactions helps merchants understand the transaction risk and enables robust processing, which result in differential treatment from your acquirer
  • Helps issuers better understand transaction risk levels
  • Higher authorization approval rates and more completed sales 
  • Fewer customer complaints related to false-positive declines

What do I need to do to be compliant? 
For those merchants who are storing their customer payment data outside of their Authorize.Net account, please see our API Reference and Developer Guides for more information on how you can update your integration for COF mandate compliance. Please work with your 3rd party service provider and/or developer to direct them to this documentation as needed. 

For merchants who use the Authorize.Net Customer Information Manager (CIM) and Automated Recurring Billing (ARB) services:

  • Work is still ongoing for the final compliance requirements phases, update will be made to this article once these have completed and are available to you
  • CIM will automatically populate the originalNetworkTransId and originalAuthAmount if the transaction request includes the required COF fields needed to identify the transaction as a COF transaction
  • ARB will automatically identify transactions processed within a subscription as a recurring payment  

The Visa, MasterCard and Discover card brands are now requiring that refunds made to customers be authorized in real-time, to validate the payment data in real-time and provide a real-time response of the success or failure of the refund attempt. 

Benefits of the Purchase Returns Authorization Mandate

The customer payment data will be validated in real-time, similarly to that of the original charge transaction request to debit funds from your customer's account. 

This means that refund transactions may now be returned as declines. This can happen if the card holder account is no longer active/valid or possibly for an unknown number of reasons which the cardholder will need to contact their issuer to identify and/or resolve. You may need to identify other means of refunding your customer if their issuer will not authorize the refund.

 What do I need to do to be compliant?

There is nothing you will need to do to become compliant. Authorize.Net is automatically performing the refund authorization at the time of submission. 

It is important to note that the Purchase Authorization Mandate, also called the Credit Authorization Mandate, is being implemented across various entities involved in the credit card authorization process, such as: 

  • Processors (the processor your acquirer uses)
  • Issuers (your bank)
  • Card Networks (Visa, MasterCard, American Express & Discover)

Since the card networks design the mandates, and then provide the requirement specifications to meet compliance to the issuers and processors so they can implement the changes in their systems, some processors and issuers are ready while others are not. This has caused some issuers to decline refunds. Some issuers, like FDCO Host Capture which always has performed real-time credit authorization, may see refunds decline in real-time. All other processors may see refund transactions receive a Settlement Error with their daily batch. 

If you receive a Settlement Error for a refund transaction, please contact your Merchant Service Provider to find out what options you have available to you to refund your customer. 

MasterCard DSRP Token Cryptogram
This MasterCard specific "Digital Secure Remote Payment" (DSRP) mandate update the original MasterCard cryptogram, from UCOF (Unscheduled Card-on-File), to add a new field specifically for Tokens (i.e. Apple Pay, Google Pay, full PAN tokenized transactions processed via a CreateTransactionRequest). 

 What will I need to do to be compliant?
Authorize.Net is currently working on compliance to this mandate. There is nothing you need to do at this time. This may change depending on your processor and will be updated here once more information becomes available. 

Card on File User Guide.docx

Card on File Mandate FAQs.docx

Was this article helpful?

Template "EBC - Coveo_Article_Recommendations" not found.