Posted on September 13, 2019

As of Saturday 14th September 2019, EU legislation requiring Secure Customer Authentication (SCA) for client-initiated credit card purchases will come into effect. While there is a phase-in period for banks to raise their standards to new requirements, it is expected that the larger banks will begin requiring additional authentication steps from the 14th.

This extra authentication will only be required for purchases made via credit card (Stripe), as Direct Debits (GoCardless) payments are considered merchant-initiated transactions and do not fall under the scope of the new legislation. For Stripe, this means using 3D Secure 2.0. Stripe’s summary of 3D Secure 2.0 is as follows:

The 3D Secure standard—often known by its branded names like Visa Secure, Mastercard Identity Check, or American Express SafeKey—aims to reduce fraud and provide added security to online payments. Beginning in late 2019, banks are expected to gradually start supporting a new version of 3D Secure.

3D Secure 2 (3DS2) introduces “frictionless authentication” and improves the purchase experience compared to 3D Secure 1. It’s expected to be the main card authentication method used to meet the Strong Customer Authentication (SCA) requirements in Europe and a key mechanism for businesses to request exemptions to SCA.

3D Secure 2 allows businesses and their payment provider to send more data elements on each transaction to the cardholder’s bank. This includes payment-specific data like the shipping address, as well as contextual data, such as the customer’s device ID or previous transaction history. The cardholder’s bank can use this information to assess the risk level of the transaction and select an appropriate response.

If the data is enough for the bank to trust that the real cardholder is making the purchase, the transaction goes through the “frictionless” flow and the authentication is completed without any additional input from the cardholder.

If the bank decides it needs further proof, the transaction is sent through the “challenge” flow and the customer is asked to provide additional input to authenticate the payment.

AUTHENTICATION STEP

In short, when clients attempt to make a credit card payment the client’s bank will determine whether to request additional authentication before allowing the payment to be made.

If verification is needed, the client will see an authentication window where they are prompted to enter either:

  • A code that has just been texted to their registered mobile number
  • A password they have previously set up for authentication

The appearance of this window will vary based on the customer’s bank, but it should appear similar to the below:

Once they have authenticated the payment, it will continue as normal. Failed or cancelled authentication will give an error and cancel the payment step.

AUTHENTICATION EXEMPTIONS

Where possible, Stripe will request an exemption from 3D Secure authentication. The relevant exemptions are as follows:

  1. LOW RISK TRANSACTIONS

Stripe will conduct real-time risk analysis to determine whether or not to apply SCA to a transaction. It will use information such as transaction history and device ID, as well as fraud rate for the payment provider (below 0.13% for <100 EUR). Note that if even where the payment provider’s fraud rates are below the threshold, if the cardholder’s bank is above it we expect the bank to decline the exemption.

  1. FIXED-AMOUNT SUBSCRIPTIONS

For fixed-amount subscriptions, the first payment in a series will need to be authenticated but subsequent charges should be exempt from SCA.

  1. VARIABLE SUBSCRIPTIONS

In the occasional case of a change of payment amount for subscriptions, Stripe can request an exemption, however it will be up to the cardholder’s bank to decide whether or not to approve it.

  1. TRUSTED BENEFICIARIES

When completing authentication for a payment, some banks may allow a customer to whitelist a business they trust in order to avoid having to authenticate future purchases. This has the potential to make subscriptions more convenient, however adoption of this exemption in banks has been slow and it is not likely to be broadly implemented for the foreseeable future.

  1. PHONE SALES/CORPORATE PAYMENTS

Card details collected over the phone may fall outside the scope of SCA. In the case of corporate payments that are entered directly into the Stripe dashboard, these will be flagged as such and Stripe will request exemption from authentication, however as per all other cases, the cardholder’s bank has the final say.

Stripe will automatically request exemption for payments by users with an existing subscription by using their transaction history, but all new subscriptions (and single-pack payments) will be in the scope of the authentication requirements.

PROCESS CHANGES

In order to comply with SCA legislation and ensure that there are no issues taking payments, the following processes should be observed:

  1. Clients should be present for purchases made using their credit card (with the exception of recurring payments which automatically renew each month). They must be on hand in order to provide necessary authentication for payments and should have their mobile phone with them as this is the most common authentication method with 3D Secure 2.0.
  2. Under no circumstances should card details be recorded by staff for future input into the system. Clients receiving an unexpected verification message to their mobile device would be extremely problematic.
  3. The membership team can continue to take sign members up over the phone provided that the sign up takes place during the call and not after. In the case of corporate payments that are entered directly in the Stripe dashboard, these may not require a client present at the time of purchase if SCA exemption is given, however final say on this is at the discretion of the banks.
  4. To maximise the chance for SCA exemption, clients should sign up on their own devices and not through the instructor’s app. If they do not have their mobile device present, then authentication is unlikely to be possible.