- Strong Customer Authentication
-
- SCA Guide One click Payments
Payment where card is saved for the future one-click payments
Customers are charged while they’re on-session, and card details are saved for future one-click payments.
Payment are made by the registered returning customers. After the first purchase, a customer can pay with a single click only. For example:
Deposit top up on gaming website.
Regular online grocery shopping.
-
What is Best Practice for SCA for me?
The purpose of SCA is to ensure that only the legitimate cardholder can make payments. The approach to achieving this follows two principals:
- Collecting good quality information to establish that the Cardholder is the person making the payment.
- Using Strong Authentication (e.g. 2 Factor Authentication) where necessary to verify the cardholder.
As such, best practice for you means using 3DS2 to give the Issuer of the card good quality information and facilitating the challenge for 2 factor authentication when requested.
In the case of ECOM payments, our advice is to use 3DS2, a fully SCA compliant authentication protocol, for every transaction. By doing so, you give the Issuer the maximum amount of information possible. The Issuer then can decide to approve the transaction (frictionless) or to challenge the cardholder with SCA, for example a One Time Password sent by SMS to their phone.
Where authentication via 3DS2 is not available, we recommend using 3DS1.
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:
- Authenticate the cardholder using 3DS2. This will give the Issuer enough information to verify that the cardholder really is the person initiating the payment.
- 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.
- Store the card. When the card has been successfully authorised the card should be stored.
For any Future payments on the stored card, our recommendation for the flow of the payment is:
- Authenticate with 3DS2
- Authorise with the appropriate “Credential on File” flags.
-
Can I use Exemptions, to avoid challenging my customer?
For a transaction meeting certain criteria, for example a low value transaction, there are two potential ways an exemption may be applied.
An Issuer, based on the good quality information you supply, and exemption criteria being met (in this example the low value), may apply an Issuer exemption and allow the transaction to flow through without a challenge (frictionless).
Your Acquirer, based on a request by you, may request an exemption (in this case the low value exemption) to bypass SCA. If the Issuer accepts the request for the Acquirer exemption, there will be no challenge to the cardholder (frictionless). If the Issuer declines, the transaction will have to be processed again using 3DS2.
-
Which solution do you use?
If you need help identifying your integration type please contact us.
I store cards with GP ecom and take payments online via our website / app, which is integrated to GP ecom via HPP, what do I need to do?
-
Review the payment flow.
You may need to alter the flow that customer goes through when they first store their credentials, i.e. authenticate, authorise, store card.
-
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.
-
HPP will automatically include the correct “Credential on File” flags on your behalf, meaning this will require no work by you.
I store cards with GP ecom and take payments online via our website / app, which is integrated to GP ecom via API, what do I need to do?
-
Review the payment flow.
You may need to alter the flow that customer goes through when they first store their credentials, i.e. authenticate, authorise, store card.
-
Integrate into our new 3DS2 service to ensure all of your 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. -
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 that is "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 cardholder is present at the time of authorisation it should also be flagged as “Customer Initiated" and indeed as "Subsequent” (not the first) transaction.
Credential on File documentation is available here. COMING SOON
-
-
What should I expect from September 2019?
Where ECOM transactions are processed without 3DS there is likely to be an increased decline rate.
We are advising our merchants using 3DS2 to expect an increase in challenges to their customers (when compared to 3DS1) for a time as the new services are rolled out. Over time, we believe that the Issuers should gradually reduce the number of challenges to customers, making the process more seamless. -
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 either frictionlessly with an Issuer exemption, or with a challenge, the Issuer is accepting liability. This means any fraud related chargebacks should not be billed to you. -
What if I requested an Exemption?
If a transaction is processed frictionlessly following a request by you for an Acquirer exemption to 3DS2, you should note that you are accepting liability for the transaction. This means any fraud related chargebacks which occur on exempt transactions will likely be billed to you.
