Last updated 01/25/2023
2 Min Read Time

Card saved for recurring, automatic payments

During first payment, the customer saves their card to set up automatic, recurring payments. Recurring payments are payments for different billing plans for product or content subscriptions, SaaS products, various memberships, subscription boxes, magazines, and donations. For example:

 

Utility Bill Payment
Tuition Payments
Insurance Payments

 

What is Best Practice for SCA for me?

Merchant Initiated Transactions are out of scope for SCA, provided they are preceded by a transaction that is fully authenticated with SCA through 3DS2, a fully SCA compliant authentication tool. This allows the Issuer to verify that the cardholder really is the person initiating the first and a series of future payments.

In order to give the Issuer as much insight into the circumstances of the payments as possible, when processing a payment on a stored card it should be flagged as “Credential on File” to indicate to the Issuer that the card has been stored.

For the Initial payment, our recommendation for the flow of the payment is

  1. Authenticate the cardholder using 3DS2 without the use of exemptions. This will give the Issuer enough information to verify that the cardholder really is the person initiating the payment.
  2. Authorise the card. This transaction should be processed with the appropriate “Credential on File” flags. This transaction could be for a zero value amount if this is supported by your acquirer.
  3. Store the Scheme Reference Data (SRD) of the authorisation response. This is a unique field supplied by Visa or Mastercard and should be part of the messaging in any future payments.
  4. Store the card. When the card has been successfully authorised the card should be stored.

For any Future, Merchant Initiated payments on the stored card, it is our advice the flow is to:

  1. Have appropriate “Credential on File” flagging. This indicates to the Issuer that this transaction is MIT and qualifies as out of scope from SCA.
  2. Include the SRD of the initial authorisation. This links future payments to the original authentication, which furnishes the Issuers with more information, improving the likelihood of successful processing.

Can I use Exemptions, to avoid challenging my customer?

Merchant initiated transactions are out of scope. This means payments can process without a need to verify the cardholder with SCA.

The Initial transaction must be authenticated with a challenge in order for the following Merchant initiated transactions to be processed successfully. Therefore, it is not an option to use an exemption from SCA for the initial transaction.

Which solution do you use?

If you need help identifying your integration type please contact us.

HPP

I store cards with GP ecom and initiate payments through my own / third party system. We are integrated to GP ecom via HPP for Initial Payments and Card Storage. Future Payments are initiated via the API. What do I need to do?

 

  1. Review the payment flow.
    You may need to alter the flow that the customer goes through when they first store their credentials, i.e. authenticate, authorise, store card.
  2. Make a change to your HPP integration to ensure all of your transactions are processed with SCA. The purpose of these changes is to supply the Issuer with all the information they may need in order to verify the cardholder. HPP will automatically facilitate a challenge to the cardholder if required. HPP 3DS2 documentation is available here: 3D Secure - Version 2 (SCA) HPP can support both 3DS2 and 3DS1 simultaneously and should 3DS2 be unavailable, HPP will dynamically route transactions through 3DS1, meaning you don’t need to implement any logic around this.
  3. Ensure the Credential on File flagging notifies the Issuer that the authorisations are on a stored card. For the Initial Authorisation, HPP will appropriately flag this on your behalf. For Future Authorisations through the API, you should include “Credential on File” flags as the card details are stored. As the transaction is initiated by the merchant, it should also be flagged as "Merchant Initiated" and indeed as "Subsequent" (not the first) transaction. Credential on File documentation is available here. COMING SOON
  4. Record the SRD of the initial authorisation, and supply it for all future transactions. This links all of the future transactions to the original authentication. This allows issuers to understand that this series of transactions was agreed to by the cardholder, and is useful in resolving disputes. More information on handling, storing and supplying the SRD is here. COMING SOON

API

I store cards with GP ecom and initiate payments through my own / third party system. We are integrated to GP ecom via API, what do I need to do?

  1. Review the payment flow. You may need to alter the flow that the customer goes through when they first store their credentials, i.e. authenticate, authorise, store card.
  2. Integrate into our new 3DS2 service to ensure your initial transactions are processed with SCA. The purpose of 3DS2 is to supply the Issuer with all the information they may need in order to verify the cardholder, and facilitate a challenge to the cardholder if required. API 3DS2 documentation is available here. Where 3DS2 is unavailable 3DS1 should be used. The API 3DS1 documentation is available here.
  3. Ensure the Credential on File flagging notifies the Issuer that the authorisations are on a stored card. For the Initial Authorisation, it should include "Credential on File" flags meaning the card will be stored. As the cardholder is present at the time of authorisation it should also be flagged as "Customer Initiated" and as “First” as it is the first authorisation on this card. For Future Authorisations, it should similarly include “Credential on File” flags as the card details are stored. As the transaction is initiated by the merchant, it should also be flagged as "Merchant Initiated" and indeed as "Subsequent" (not the first) transaction. Credential on File documentation is available here. COMING SOON
  4. Record the SRD of the initial authorisation, and supply it for all future transactions. This links all of the future transactions to the original authentication. This allows issuers to understand that this series of transactions was agreed to by the cardholder, and is useful in resolving disputes. More information on handling, storing and supplying the SRD is here. COMING SOON

What should I expect from 14 March 2022?

Merchant initiated transactions are out of scope of SCA.

We do not expect any impact to the authorisation rates of correctly flagged merchant initiated transactions. Similarly, a series of merchant initiated payments which began prior to 14 March 2022 are expected to process successfully even where not linked to an initial authentication.

Transactions not properly flagged as Merchant Initiated are likely to be treated as Customer Initiated by default and so are at risk of being declined if they lack SCA. If this occurs you may need to reauthenticate the cardholder.

Who is Liable in the event of a dispute?

Liability for fraud related chargebacks, passes to the card Issuer when an SCA challenge occurs.

Where the Issuer decides to approve the transaction following a challenge, the Issuer is accepting liability. This will be the case for the initial transaction in the series. This means any fraud related chargebacks here should not be billed to you.

The future transactions in the series are not processed via SCA and so liability rests with the Acquirer/Merchant and so it is likely that any fraud related chargebacks will be billed to you.

However by including the SRD of the first authenticated transaction in the future merchant initiated payments, linking a full authentication by the cardholder to future payments, it is easier to contest fraud related disputes should they arise.