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://www.mastercard.us/content/dam/mccom/global/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.
Initially, these updates will be available for integrators using the CardPointe Gateway API and Oracle EBS integration to accept card-not-present payments. You should plan to update and test your application as soon as possible.
Currently, the CardPointe Gateway UAT environment is configured to ignore these fields, so you can test your updated application without encountering errors in the test environment. See Integrated Payment Application Changes for more information.
These enhancements will be deployed to the CardPointe Virtual Terminal, Hosted Payment Page, and other payment products in future releases of these products. See CardPointe Payment Application Changes for more information.
Only merchants processing on First Data/Fiserv platforms (for example, First Data Rapid Connect) will be able to take advantage of this feature. For merchants on other platforms, transactions using stored credentials (for example, recurring payments) may be flagged for data integrity issues for non-compliance, and may incur fines.
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.
- Inform the account issuer that payment credentials are now stored on file, either by processing a payment or a $0 account verification.
- Identify the initiator (cardholder or merchant) and frequency (one-time or scheduled) of the transactions with appropriate indicators when using stored credentials.
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". Omitting the
cofscheduled parameter defaults this value to
n in the transaction record.
Expand the following topic for additional sample scenarios:
Sample Stored Credential Transaction Scenarios
|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.|
|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.|
|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.|
|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.|
|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:
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
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.
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.
|1||AN||For a merchant-initiated transaction (MIT), the |
Specify one of the following values:
The following example illustrates the
cofscheduled fields used in an authorization request, where the merchant's billing system initiated a scheduled, automated payment:
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.
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.
If you or your merchants use the CardPointe Virtual Terminal or CardPointe Hosted Payment Page to accept and manage payments, you may need to become familiar with minor changes to these applications to become compliant with this mandate.
The changes to these applications are currently in development, and are dependent on the changes to the CardPointe Gateway. Additional information will be available as development completes.
When Can I Update and Test my Integration?
You should plan to update and test your integration as soon as possible.
The CardPointe Gateway UAT environment is currently configured to ignore the
cofscheduled parameters, so your application can begin to send these values without encountering errors in testing.
Note that the
cof response field is not currently returned in the UAT environment; however this field will be present in production.
What Will Happen if I Do Not Update My Application?
Compliance with this mandate is required to continue processing recurring payments. Recurring transactions that do not include the required COF parameters may be flagged for a data-integrity issue and may incur fines.