Overview
In October 2017, Visa and Mastercard issued new rules regarding the use of stored credentials. This mandate requires specific handling and transmission of stored credentials (in this case, tokens representing payment data). See the following documentation from Visa and Mastercard for detailed information:
- https://usa.visa.com/dam/VCOM/global/support-legal/documents/stored-credential-transaction-framework-vbs-10-may-17.pdf
- https://www.mastercard.us/content/dam/public/mastercardcom/na/global-site/documents/transaction-processing-rules.pdf (sections 5.3 and 5.4)
This document describes the CardPointe Gateway's compliance with this mandate and the changes that you may need to make to your integration to become compliant.
Support for stored credential (also known as card on file, or COF) transactions is enabled in production for the following processors:
- First Data North
- First Data Omaha
- First Data Rapid Connect
- Chase Paymentech Salem
- TSYS
Additionally, on 7/13/2024, an update to the CardPointe Gateway included a recertification of the First Data Rapid Connect specification to address Mastercard data integrity issues caused by an incorrect Mastercard Cardholder/Merchant Initiated Transaction Indicator.
Understanding Stored Credentials
A stored credential is information (including, but not limited to, an account number or payment token) that is stored by a merchant or its agent to process future transactions.
If your application stores cardholder data (for example, using the CardPointe Gateway profile service to manage cardholder profiles or storing tokens in your own database) for use in future one-time or recurring payments, you must do the following to become compliant with this mandate:
- Disclose to cardholders how those credentials will be used.
- Obtain cardholders’ consent to store the credentials.
- Notify cardholders when any changes are made to the terms of use.
- Inform the account issuer that payment credentials are now stored on file, either by processing an initial payment or a $0 account verification.
- Identify the initiator (cardholder or merchant) and frequency (one-time or scheduled) of transactions with appropriate indicators when using stored credentials.
- Provide proactive notification of future payment transactions and ability to cancel a subscription or recurring payment.
Additionally, merchants offering subscription services in Europe must send an electronic reminder notification (email or SMS/text message, if cardholder accepted future notification) and a link to online cancellation at least seven (7) days before initiating a recurring transaction if a trial period, introductory offer or promotional period has expired.
Identifying Cardholder and Merchant-Initiated Transactions
Payment applications must determine whether each applicable transaction is a Cardholder-Initiated Transaction (CIT), or a Merchant-Initiated Transaction (MIT).
A Cardholder-Initiated Transaction is any transaction in which the cardholder is actively participating in the transaction (by phone, online, or in-person) using stored credential and payment details, for example:
- A cardholder creating a standing order for a recurring, fixed-amount payment for goods or services (for example, a scheduled rent payment).
- A cardholder authorizing a payment on an account over the phone.
Cardholder-Initiated Transactions must be identified by including "cof":"c" in the authorization request to the CardPointe Gateway.
A Merchant-Initiated Transaction is any transaction in which the cardholder is not available to participate:
- A follow-up payment after an initial cardholder-initiated transaction.
- A direct deposit agreement for the payment of goods or services (for example, a recurring bill payment for a streaming service subscription).
Merchant-Initiated Transactions must be identified by including "cof":"m" in the authorization request to the CardPointe Gateway. Periodic recurring transactions must also include "cofscheduled":"y".
The following table describes some sample scenarios using stored credentials:
For Cardholder-Initiated Transactions, cofscheduled is optional. This value should be omitted or N if included.
| Scenario Name | Scenario Description | cof | cofscheduled |
|---|---|---|---|
| One-Time Online Purchase | A new customer makes a one-time purchase on your web store or app, and opts to create an account to store their billing and payment information. | C | N |
| One-Time Phone Purchase | A patient calls your office to make a one-time payment over the phone. The customer provides their billing information to an associate, who enters it into your application. When asked, the customer agrees to store their billing information for future payments. | C | N |
| One-Time Phone Purchase with Stored Profile | A patient calls your office to make a one-time payment over the phone, and their billing information is already stored for use in your application. | C | N |
| Online One-Time $0 Authorization (Account Verification) | A new customer creates an account on your website for the purpose of making one-time purchases. Your application processes the initial payment or a $0 authorization to verify the billing details. | C | N |
| Online Subscription $0 Authorization (Account Verification) | A new customer creates an account on your website and enrolls in a subscription service, which is billed monthly. Your application processes the initial payment or a $0 authorization to verify the billing details. | M |
|
| Online Subscription Returning Customer | A customer previously enrolled in your subscription service, and is automatically billed for the monthly amount using their saved billing details. | M | Y |
| Existing Customer Split Charges: | An existing customer purchased multiple items from your web store, and checked out with their stored profile; however, only some goods were in stock at the time of the order. The customer is charged twice for the split shipment, where: | ||
| Existing Customer Split Charges: In-Stock Charge |
| C | N |
| Existing Customer Split Charges: Remainder Charge |
| M | N |
Integrated Payment Application Changes
If you or your merchants use an application that integrates the CardPointe Gateway API to accept and manage transactions, you must update your application to become compliant with this mandate.
The changes required to comply with this mandate affect merchants who:
- Store and reuse payment tokens and customer information to process recurring payments through an E-commerce or ERP application.
- Use the CardPointe Gateway's profile service to create and store customer profiles and process card-not-present payments using the associated profileid and accountid.
If your payment workflows use either of these methods to store and reuse customer data, you will need to update your integration to identify the initial and subsequent payments.
New Authorization Request Parameters
To support the requirements to identify stored credential transactions, the CardPointe Gateway API includes the following new parameters, which must be included in the authorization request for all E-commerce, telephone, and recurring payments using stored customer payment information.
| Field | Max Length | Type | Description |
|---|---|---|---|
| cof | 1 | AN | The cof parameter specifies whether the transaction is initiated by the customer or merchant.
|
| cofscheduled | 1 | AN | The cofscheduled parameter specifies whether the transaction is a one-time payment or a scheduled recurring payment. Required for a Merchant-Initiated Transaction (MIT), and optional for a Customer-Initiated Transaction (CIT). Specify one of the following values:
|
| cofpermission | 1 | AN | For an authorization request with "profile":"y" to create a new profile, or for a profile create or update request, optionally include cofpermission to specify if the cardholder provided their permission to store and reuse their payment information. This field is optional, and is only used for reporting purposes, via the get profile response. Specify one of the following values:
Defaults to N if not provided. |
The following example illustrates the cof and cofscheduled fields used in an authorization request, where the merchant's billing system initiated a scheduled, automated payment:
Example Recurring Payment with COF Fields
{
"merchid":"177203351990",
"currency":"USD",
"expiry":"0420",
"orderid":"000246560010",
"accttype":"Visa",
"account":"4005562231212123",
"amount":"210.03",
"address":"1307 Broad Hollow Road",
"postal":"11747",
"capture":"Y",
"cof":"M",
"cofscheduled":"Y"
}
New Authorization Response Field
When a transaction is identified as a stored credential transaction, the CardPointe Gateway records the transaction as either an initial or subsequent transaction for card account and merchant ID.
The cof field has been added to the CardPointe Gateway's authorization response. When the cof field is present in the request, it will also be returned in the response to help you track your stored credential transactions.
CardPointe Payment Application Changes
If you or your merchants use the CardPointe Virtual Terminal or CardPointe Mobile app to accept and manage payments, you may need to become familiar with minor changes to these applications to become compliant with this mandate.
See Handling Stored Profiles for more information on these in-app changes.