Authorize.net Mandate Compliance Overview
11/15/2023 00:19 AM
Authorize.net is in the process of implementing support for Visa, MasterCard, and Discover Card on File (COF) for Customer Initiated Transaction (CIT) and Merchant Initiated Transaction (MIT). Also, it is implementing the separate Purchase Returns Authorization (PRA) Mandates. This article provides the latest information and links to available resources. Note:
- Each processor connection is updated independently. Each connection is unique and requires careful attention to ensure that the required fields are supplied according to your processor's specifications.
- This article provides information on whether your processor connection has been updated for compliance with these mandates.
- If you are unsure which processor you are using, contact your Merchant Service Provider.
Here are the mandates, who they apply to, the applicable card types, the estimated date of support, and notes:
|Who does it apply to?
|Applicable Card Types
|Estimated/Completed Date of Support
|Card on File (COF) - Customer Initiated Transaction (CIT) and Merchant Initiated Transaction (MIT)
|Merchants who use Customer Information Manger (CIM), Automated Recurring Billing (ARB), or any 3rd party solution that stores customer payment card data for future charges.
First Data Nashville: Completed 3/29/2022
|Purchase Returns Authorization (PRA) aka Online Refunds
|Merchants who process refunds through their Authorize.Net account via API or the Merchant Interface
Amex (TSYS only)
First Data Nashville: 8/3/2022
|MasterCard DSRP Token Cryptogram
|Merchants who process Apple Pay, Google Pay and/or full PAN tokenized transactions with a CreateTransactionRequest
|TSYS: Completed 6/21/2023
All Other Processor Connections: Contact Support
|MasterCard EMV: AN 5499 - Revised Standards for Identifying MPOS Terminals in Transaction Messages
|Merchants who Process MC EMV transactions through our VPOS/MPOS
|At this point, we will not be providing any dates by which we will be supporting this mandate.
Card on File (COF) Overview
Visa, Mastercard, and Discover have set requirements for merchants storing customer payment credentials for potential future use. There are two types of transactions 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
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.
Purchase Returns Authorization (PRA) Overview
The Visa, MasterCard, and Discover card brands now require real-time authorization for customer refunds. This validates the payment data in real-time and provides immediate feedback on the success or failure of the refund attempt.
Benefits of the Purchase Returns Authorization Mandate
This mandate ensures customer payment data is validated in real-time, similar to the original charge transaction request. Consequently, refund transactions may now be returned as declines. This can occur if the cardholder account is no longer active or valid, or for various other reasons. Cardholders may need to contact their issuers to identify and resolve these issues. You may need to find alternative ways to refund your customer if their issuer will not authorize the refund.
What do I need to do to be compliant?
You don't need to do anything to comply. Authorize.net automatically performs the refund authorization at the time of submission. It's important to note that this mandate, also known as the Credit Authorization Mandate, is being implemented across various entities involved in the credit card authorization process. These include:
- Processors (the processor your acquirer uses)
- Issuers (your bank)
- Card Networks (Visa, MasterCard, American Express & Discover)
As card networks design the mandates and provide the compliance requirements to issuers and processors, readiness varies. This has led some issuers to decline refunds. Some issuers, like FDCO Host Capture, which has always performed real-time credit authorization, may see real-time refund declines. All other processors may encounter a Settlement Error with their daily batch. If you receive a Settlement Error for a refund transaction, please contact your Merchant Service Provider to explore your options for refunding your customer.
MasterCard DSRP Token Cryptogram Overview
This MasterCard-specific "Digital Secure Remote Payment" (DSRP) mandate updates 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 with this mandate. You don't need to do anything at this time. This may change depending on your processor and will be updated here once more information becomes available.
Was this article helpful?