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)
We are currently in the process of certifying the CardPointe Gateway for compliance with this mandate. This document describes the changes in development for the CardPointe Gateway API, and the changes that you can plan to make to your integration to become compliant.
The changes described in this document are currently in development. This document will be updated as development completes.
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
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:
| Scenario | cof | cofscheduled |
|---|---|---|
| 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 |
| 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 |
| 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 |
| 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 |
|
| 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. |
|
|
| A customer previously enrolled in your subscription service, and is automatically billed for the monthly amount using their saved billing details. | M | Y |
| 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: | ||
| C | N |
| 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
profileidandaccountid.
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 | For a merchant-initiated transaction (MIT), the cofscheduled parameter specifies whether the transaction is a one-time payment or a scheduled recurring payment.Specify one of the following values:
|
cofpermission | 1 | AN | For an authorization request with This field is optional, and is only used for reporting purposes, via the get profile response. Specify one of the following values:
Defaults to |
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:
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.
When Can I Update and Test my Integration?
You should plan to update and test your integration as soon as possible.
For First Data Rapid Connect, the UAT environment is configured to emulated the production environment and to echo the cof field and value from the request in the response.
For other First Data/Fiserv processors, the UAT environment is currently configured to ignore the cof and cofscheduled parameters, so your application can begin to send these values without encountering errors in testing.