• Developers
  • Reporting
  • Disputes
  • Contact us
  • Log in

Main Navigation

  • Account

      Account

        • Customer docs & pricing

          Find important documents such as our Terms of Service and Merchant Operating Instructions, as well as more information on things like Stored Credential Transactions and the Account Updater Service

        • Compliance & security

          For more information on Strong Customer Authentication, PCI Compliance, and fraud prevention best practices

        • Stationery ordering

          Order your tally rolls, card scheme logo stickers, and more

        • FAQs

          Our FAQs can help you with queries including pricing changes, cleaning and restarting your terminals, and Multi-Factor Authentication

  • Products

      Products

        • POS help
        • Ecommerce help
        • Bank Payment
  • Insights
  • Trending Articles
Sign up
Search

Main Navigation

  • Account
      Account

      Account

    • Customer docs & pricing
    • Compliance & security
    • Stationery ordering
    • FAQs
  • Products
      Products

      Products

    • POS help
    • Ecommerce help
    • Bank Payment
  • Insights
  • Trending Articles
    • Developers
    • Reporting
    • Disputes
    • Contact us
    • Log in
    Sign up /en-gb/sitecore/content/gpn/corporate/corporate/home/modals/signup-homepage

Sidebar Navigation

  • Account -
    • FAQs +
      • Pricing frequently asked questions +
      • PCI Frequently asked questions +
      • Best practice for cleaning your POS device(s) +
      • Terminal restart guide +
      • CNP FAQs - resubmitting declined transactions +
      • Multi-Factor Authentication for Global Payments Ecommerce Portal +
      • Ecommerce FAQs +
      • Bank Payment FAQs +
      • Your invoice explained +
      • How do I make a complaint +
    • Customer Docs & Pricing +
      • Terms of Service +
      • Merchant Operating Instructions +
      • Interchange fee update +
      • Recovered card form +
      • Mastercard and Visa Interchange rates +
      • Merchant Data Processing Notice +
      • Enhanced Authorisation Data Service merchant implementation guide +
      • Stored Credential Guide +
      • SCT Technical Implementation Guide +
      • SCT Decision Tree +
      • Account Updater Service +
      • Account Updater migration to UK Ensurebill +
    • Compliance & Security -
      • Ecommerce fraud management +
      • Know the risks +
      • Online Card Not Present Best Practices +
      • Fraud Hints and Tips Guide +
      • Reducing Risk of Fraud Guide +
      • Guide to Patching +
      • Know the risks +
      • What To Do If You're Compromised +
      • PCI Frequently asked questions +
      • SCA -
        • One-off payments without saving card details
        • One-click payments without saving card details
        • Card saved for recurring, automatic payments
        • Payment over the phone (MO/TO)
        • What Do I Need to Do to Be SCA Compliant?
        • PSD2 and SCA Technical Information Guide
        • Strong Customer Authentication Decision Tree
        • How to use the Strong Customer Authentication (SCA) Authentication Outage Indicator
    • Stationery ordering +
    • How do I understand my invoice? +
  • Products +
    • Point of Sale Help +
      • Quick Start Guide Miura M10 Device +
      • Quickstart Guide Miura M20 Device +
    • Ecommerce Help +
      • Transaction management +
      • Customer management +
      • Fraud Management +
      • Resetting your password +
      • Virtual Terminal +
      • Ecommerce portal navigation +
      • User Management +
      • Transaction reporting +
      • Ecommerce FAQs +
    • Bank Payment +
      • Bank Payment FAQs +
      • Bank Payment sales sheet +
  1. Home
  2. Account
  3. Compliance & Security
  4. SCA
  5. Card saved for recurring, automatic payments
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.


  • Account
  • Products
  • Customer Docs & Pricing
  • Compliance & Security
  • Industry news
  • Trending articles
  • Notices and Policies
  • Sitemap

Already a customer?

Log in

Connect

  • LinkedIn
  • Twitter
  • Facebook
  • YouTube
{D6036E8F-C9A1-420D-AEC3-5680EC9FBE35}
 

Global Payments is a trading name of GPUK LLP. GPUK LLP is authorised by the Financial Conduct Authority under the Payment Services Regulations 2017 (504290) for the provision of payment services and under the Consumer Credit Act (714439) for the undertaking of terminal rental agreements. GPUK LLP is a limited liability partnership registered in England with company number OC337146. Registered Office: Granite House, Granite Way, Syston, Leicester, LE7 1PL. The members are Global Payments U.K. Limited and Global Payments U.K. 2 Limited. Service of any documents relating to the business will be effective if served at the Registered Office.

Global Payments is also a trading name of Pay and Shop Limited. Pay and Shop Limited is a limited company registered in Ireland with company number 324929. Registered Office: The Observatory, 7-11 Sir John Rogerson's Quay, Dublin 2, Ireland. Service of any documents relating to the business will be effective if served at the Registered Office.

© 2023 GPUK LLP. All rights reserved. Privacy Statement | Terms of Use  | Ethics Reporting Hotline | Gender Pay Report  | Anti Slavery Statement