Stored Credential Transaction Framework
As part of the ‘stored credential transaction framework’, Visa has specified new requirements for merchants and payment service providers. The regulations affect all merchants which use stored Visa card details (known as ‘stored credentials’) to initiate transactions. Such transactions could be merchant-initiated ones as in the case of subscription or instalment payments. But there are also scenarios to store card details for future reference in transactions by the cardholder (one-click checkout).
In the future, merchants that allow cardholders to store their Visa card details for initial and subsequent use will need to:
- Obtain approval from the cardholder on initial storing of their information. (Business Requirements)
- Use relevant indicators to mark transactions for which stored payment information (tokens) is used. (Technical Requirements)
You will find detailed information about the modified requirements in accordance with the new Visa regulations in the following sections:
- What Is a Stored Credential?
- Scenarios of Stored Credential Transactions
- Business Requirements – Disclosure and Cardholder Consent
- Technical Requirements
- Frequently Asked Questions
As the payment system has evolved, instances in which a transaction is initiated with a stored credential based on a cardholder’s consent for future use have increased to significant levels. Growth in digital commerce, together with the emergence of new business models, has increased the number of transactions where a merchant or its service provider uses cardholders’ payment credentials (i.e., Visa card details) that they previously stored for future purchases.
Recognising stored credential transactions allows for greater visibility of the transaction risk, enabling robust processing and resulting in diﬀerential treatment.
Visa has defined authorisation data values to help identify initial storage and usage of stored payment credentials to enable diﬀerentiated processing.
Visa is enhancing its rules and processing specifications to address a comprehensive list of scenarios where payment credentials are stored with the merchant.
Benefits of Identifying Transactions as a Stored Credential: Specifically identifying stored credential transactions allows diﬀerentiated treatment through the authorisation approval process. The results are:
- Greater visibility of transaction risk levels for issuers
- Higher authorisation approval rates and completed sales
- Fewer customer complaints and improved cardholder experience
A stored credential is information (including, but not limited to, an account number or payment token) that is stored by a merchant or its service providers (including payment service provider or acquirer) to process future purchases for a cardholder.
Payment credentials received by merchants from third parties that are not stored by the merchant or its service providers are not considered stored credentials. For example, a payment credential received by a merchant on a purchase from Visa Checkout or MasterPass and not stored by that merchant is not considered a stored credential.
A credential is also not considered a stored credential when the merchant or its service provider stores the credential to complete a single transaction or a single purchase for a cardholder (including multiple authorisations related to that particular transaction).
For example, when a cardholder provides a payment credential to a hotel to cover future reservations and charges as part of the cardholder’s membership profile, it is considered a stored credential. However, when the cardholder provides the payment credential to a hotel to cover charges related to a specific reservation only, it is not.
Cardholder-initiated Transaction (CIT): A cardholder-initiated transaction is any transaction where the cardholder is actively participating in the transaction. This can be either at a terminal in-store or through a checkout experience online, or with a stored credential.
Credential on File CIT: A card-absent transaction initiated by the cardholder where the cardholder does not need to enter their card details as the merchant uses the payment credential previously stored by the cardholder to perform the transaction. Examples include a transaction using a customer’s merchant profile.
Merchant-initiated Transaction (MIT):
- Perform a transaction as a follow-up to a cardholder-initiated transaction (CIT)
- Perform a pre-agreed standing instruction from the cardholder for the provision of goods or services
Examples of MITs include:
- A hotel charge for minibar expenses tallied after the guest has checked out and closed the folio
- A subsequent recurring payment for a magazine subscription
Digital payments made via an app to purchase goods or order services at a customer’s request – such as ordering a ride or buying train tickets – are not MITs but are cardholder-initiated transactions as the cardholder actively participates in them.
Industry-specific Business Practice MITs: MITs defined under this category are performed to fulfil a business practice as a follow-up to an original cardholder–merchant interaction that could not be completed with one single transaction. Not every industry practice merchant-initiated transaction is performed with a stored credential. When the merchant or its service provider stores the credential for a single transaction or a single purchase, it is not considered as a stored credential transaction. The following transaction types are industry-specific transactions:
Incremental authorisations: Incremental authorisations can be used to increase the total amount authorised if the authorised amount is insufficient. An incremental authorisation request may also be based on a revised estimate of what the cardholder may spend. Incremental authorisations do not replace the original authorisation – they are additional to previously authorised amounts. The sum of all linked estimated and incremental authorisations represent the total amount authorised for a given transaction. An incremental authorisation must be preceded by an estimated/initial authorisation.
One or more incremental authorisations can be requested while the transaction has not yet been finalised (submitted for clearing). Incremental authorisations must not be used once the original transaction has been submitted for clearing. In such a scenario, a new authorisation must be requested, with the appropriate reason code (e.g., delayed charges, reauthorisation).
Resubmission: A merchant performs a resubmission in cases where it requested an authorisation, but received a decline due to insufficient funds; however, the goods or services were already delivered to the cardholder. Merchants in such scenarios can resubmit the request to recover outstanding debt from cardholders.
Reauthorisation: A merchant initiates a reauthorisation when the completion or fulfilment of the original order or service extends beyond the authorisation validity limit set by Visa. There are two common reauthorisation scenarios:
- Split or delayed shipments from e-commerce retailers. A split shipment occurs when not all the goods ordered are available for shipment at the time of purchase. If the fulfilment of the goods takes place after the authorisation validity limit set by Visa, e-commerce merchants perform a separate authorisation to ensure that consumer funds are available.
- Extended-stay hotels, car rentals and cruise lines. A reauthorisation is used for stays, voyages and/or rentals that extend beyond the authorisation validity period set by Visa.
Delayed Charges: Delayed charges are performed to process a supplemental account charge after original services have been rendered and respective payment has been processed.
No-Show: Cardholders can use their Visa cards to make a guaranteed reservation with certain merchant segments.
A guaranteed reservation ensures that the reservation will be honoured and allows a merchant to perform a no-show transaction to charge the cardholder a penalty according to the merchant’s cancellation policy.
Standing-Instruction MITs: MITs defined under this category are performed to address pre-agreed standing instructions from the cardholder for the provision of goods or services. The following transaction types are standing instruction transactions:
Instalment Payments: A transaction in a series of transactions that use a stored credential and that represent cardholder agreement for the merchant to initiate one or more future transactions over a period for a single purchase of goods or services.
Recurring Payments: A transaction in a series of transactions that use a stored credential and that are processed at fixed, regular intervals (not to exceed one year between transactions), representing cardholder agreement for the merchant to initiate future transactions for the purchase of goods or services provided at regular intervals.
Unscheduled Credential on File (UCOF): A transaction using a stored credential for a fixed or variable amount that does not occur on a scheduled or regularly occurring transaction date, where the cardholder has provided consent for the merchant to initiate one or more future transactions. An example of such a transaction is an account auto-top-up transaction.
Prior to storing credentials for future use, the merchant must establish an agreement with the cardholder containing the following aspects:
- A truncated version of the stored credential (e.g., last four digits of card number (PAN))
- How the cardholder will be notified of any changes to the consent agreement
- The expiration date of the consent agreement, if applicable
- How the stored credential will be used
- Cancellation and refund policies
- Location of merchant
- Transaction amount or how it will be calculated
- Convenience fee or surcharge (if permitted and applicable)
- The frequency (recurring) or event (unscheduled) that will prompt the transaction
- For instalment payments, the total purchase price and terms of future payments, including the dates, amounts and currency
Operation and storage:
- Notify the cardholder in the event of a change to the agreement
- Retain the agreement for the duration of the consent; provide it to the acquirer upon request
- Where required by applicable laws or regulations, provide to the cardholder a record of the consent
- Use an account verification transaction if an authorisation of payments is not applicable at the time of storing the credential on file
- If the initial authorisation request or account verification is not approved the credential must not be stored.
- Provide a simple cancellation procedure, and, if the cardholder’s order was initially accepted online, at least an online cancellation procedure
- In case of cancellation within the terms of cancellation procedure, confirm the cancellation or refund in writing and provide receipt in case of cancellation within three business days
- Do not complete a transaction
- Beyond the duration expressly agreed by the cardholder, or
- If the cardholder requests that the merchant changes the payment method, or
- If the cardholder cancels according to the agreed cancellation policy, or
- After receiving a decline response
Provide notification for recurring transactions (seven business days) and for unscheduled COF transactions (two business days) before any of the following:
- End of trial period
- More than six months have elapsed since the previous transaction in the series
- Any change to the agreement including date, amount or how it is calculated
Issuer Requirements: An issuer must not decline a transaction based solely on a missing CVV2, if the authorisation request is for the subsequent transaction after the credential is stored. This rule previously applied only to recurring transactions and is now applicable to:
- Recurring transactions
- Instalment transactions
- Unscheduled COF (UCOF) transactions
- Transactions initiated by the cardholder using a stored credential
Merchant Requirements: Wirecard APIs in the past provided explicit support for the recurring and instalment transaction scenarios and these have already been upgraded to make sure issuers are notified of the specific use of stored credentials. We envisage slight changes in the future which we will communicate to you in due course.
For the other transaction scenarios described above we are not currently aware which merchants are using them. We are currently preparing extensions of the APIs in order to provide explicit support while minimising the impacts on existing implementations. If you believe you are using any of the transaction scenarios described in the categories of stored credentials including industry practices, we ask you to register this with us so that we can update you as and when specific interface changes become available.
Please register for Wirecard API updates regarding transaction scenarios
Frequently Asked Questions
Once the merchant has followed all disclosure requirements and used the appropriate indicator in the authorisation message to:
- Indicate that the credential is being stored, and
- Request and receive approval on the authorisation for the initial transaction
A credential is not considered stored when the merchant or its service provider stores the credential to complete a single transaction or a single purchase (including multiple authorisations related to the particular transaction). For example, when a cardholder provides a payment credential to a hotel to cover future reservations and charges as part of the cardholder’s membership profile, it is considered a stored credential. However, when the cardholder provides the payment credential to a hotel to cover charges related to a specific reservation only, it is not.
Also, payment credentials received by merchants from third parties, including digital wallets that are not stored by the merchant or its service provider, are not considered stored credentials.
If the initial transaction (in which storage of credentials is communicated) is declined for any reason, the merchant should not consider the credential to be on file for the purpose of the Cardholder Consent Agreement and future transactions.
Cardholder Consent Agreements are not needed when credentials are stored for the completion of a single transaction. All cases categorised under industry practices (no-show, delayed charge, incremental authorisation, resubmission, reauthorisation) are exempt from the requirement.
The regulations about stored credentials affect the authorisation stage of transactions. Existing clearing and settlement processes and interchange qualification criteria are not affected.
Chargeback rules are not changed as a result of the stored credential rules.
Please contact us by telephone +49 (0) 30 3001 123456 or email email@example.com if you have additional questions.
The service team will be glad to help you Mondays to Fridays from 9 a.m. to 5 p.m.
You will find your merchant ID in the info email with the subject "New regulations for handling stored Visa card details", which you have received from us. Your merchant ID is placed below the sender.