Stored credential transactions


Payment systems are evolving, and more cardholders are storing their card details with apps, third-parties and digital wallets.

To make sure merchants use their customers' details responsibly, Visa and Mastercard are introducing new definitions for these 'stored credentials', and new rules for stored credential and merchant initiated transactions.

If you process stored credential transactions, you will need to make changes to comply with these rules.

What is a stored credential?

The rules apply to transactions where you store a card number or token for future purchases, or where you use stored information for future purchases. These rules apply to:

  • Merchants or their agents
  • Payment Facilitators (PFs)
  • Staged/ Digital Wallet Operators (SDWO)

For simplicity, this site will refer to all of the above as 'you' - even when the entity making the transaction is a third party operating on your behalf.

There are two types of stored credential transactions:

Cardholder initiated

A Cardholder Initiated Transaction (CIT) is where the cardholder actively selects the card to use, and completes the transaction using previously stored details.

Cardholder Initiated Transactions are limited to sale, pre-authorisation, and account verifications.

Merchant initiated

A Merchant Initiated Transaction (MIT) is where is where you submit a transaction using previously stored detail without the cardholder's participation, such as a recurring payment.

Merchant Initiated Transactions are excempt from Strong Consumer Authentication (SCA). However please note that the first transaction must be strongly authenticated. Once the first transaction is strongly authenticated, and the transaction ID from the original authenticated transaction is included in the payment request, subsequent transactions are excluded.

There are a number of MIT types. See the Appendix for a list.

How this affects you

Whenever you process a stored credential transaction (either an MIT or CIT), you must follow Visa and Mastercard rules.

The consent agreement

If you allow cardholders the opportunity to store credentials, you must get their consent to do so.

This consent agreement must contain:

  • A truncated card number (i.e. the last four digits)
  • Details of how you will notify your cardholder of any changes to the consent agreement
  • The expiry date of the agreement
  • Details of how you will use the stored card details

If you are going to use the stored details to initiate transactions (MITs), you must also include:

  • Your cancellation and refund policy
  • Your full postal address, including country and telephone number
  • The amount, or details of how you will calculate this
  • Any permitted additional fees or surcharges
  • The transaction frequency (for recurring transactions)
  • The total purchase amount, and the terms of future payments (for instalment transactions)
  • For a non-scheduled MIT (i.e. not a recurring or instalment transaction), the event that will initiate the transaction

You must store the cardholder's consent in compliance with the Payment Card Industry Data Security Standard, and keep this consent for the duration of the agreement. You must provide a copy to the cardholder and, in the event of a dispute, provide a copy to the card issuer.

Amending or cancelling a consent agreement

If you want to change the agreement, you must notify the cardholder.

In particular, you must notify cardholders within seven working days (for recurring transactions), and within two working days (for unscheduled MITs) before any of the following events:

  • End of a trial period
  • More than six months elapsed since the last transaction
  • Any changes to the agreement

You must not continue submitting transactions beyond the duration of the cardholder's consent.

You must stop submitting transactions if the cardholder cancels in accordance with your policy, or if you receive a decline response.

For instalments, if the cardholder cancels in accordance with your policy, you must confirm this to the cardholder within three days, and provide a credit receipt for the amount specified in your policy, if relevant.

Submitting a stored credential transaction

When you submit a stored credential transaction, you must submit additional information to Worldpay.

The information will be different, depending on whether the transaction is:

  • An initial transaction where you store a card number or token for future purchases, or
  • A subsequent transaction using stored information for future purchases
  • If the cardholder initiates the transaction, you will need to submit a cardholder initiated indicator
  • If you are initiating the transaction (i.e. a merchant initiated transaction), you will need to submit a merchant initiated indicator and a specific transaction reason code - see the appendix for a list of reason codes

For technical guidance on how to submit stored credential transactions to our gateways, please see the following documentation:

Worldpay will publish technical guidance on how to submit stored credential transactions for our other services as soon as this is available.

Appendix

Stored credential flow



Merchant Initiated Transaction reason codes

Reason Description
REAUTH Reauthorisation - a purchase made after the original purchase. A common scenario is delayed/split shipments.
UNSCHEDULED A transaction using a stored credential for a fixed or variable amount that does not occur on a scheduled or regularly occurring transaction date. This includes account top-ups triggered by balance thresholds.
DELAYED A delayed charge is typically used in hotel, cruise lines and vehicle rental environments to perform a supplemental account charge after original services are rendered.
INSTALMENT A single purchase of goods or services billed to a cardholder in multiple transactions, over a period of time agreed by the cardholder and you.
INCREMENTAL An incremental authorisation is typically found in hotel and car rental environments, where the cardholder has agreed to pay for any service incurred during the duration of the contract. An incremental authorisation is where you need to seek authorisation of further funds in addition to what you have originally requested. A common scenario is additional services charged to the contract, such as extending a stay in a hotel.
RECURRING Transactions processed at fixed, regular intervals not to exceed one year between transactions, representing an agreement between a cardholder and you to purchase goods or services provided over a period of time.
RESUBMISSION When the original purchase occurred, but you were not able to get authorisation at the time the goods or services were provided. It should be only used where the goods or services have already been provided, but the post-event authorisation request is declined for insufficient funds.
NOSHOW A no-show is a transaction where you are enabled to charge for services which the cardholder entered into an agreement to purchase, but the cardholder did not meet the terms of the agreement.
N/A Only use if the other reasons are not applicable Implementation: Hide this row, and let you react to queries?

Legal

This document and its content are proprietary to Worldpay and may not be reproduced, published or resold. The information is provided on an "AS IS" basis for information purposes only and Worldpay makes no warranties of any kind including in relation to the content or suitability. Terms and Conditions apply to all our services.