Take immediate action now

Strong Customer Authentication and the implications for your business

The second EU Payment Service Directive (PSD2) introduces new mandatory requirements for authenticating e-Commerce transactions; referred to as Strong Customer Authentication (SCA)

From 1 January 2021, SCA must be used for all e-Commerce transactions unless an exemption or exclusion (out of scope transaction) applies. Exemptions do not require SCA and enable a frictionless payment experience which can be used for low risk transactions. 

What is Strong Customer Authentication?

SCA is designed to reduce online fraud and make online payments more secure. SCA requires the payment industry to introduce additional security measures by building additional authentication into the e-Commerce check-out process. SCA will help ensure that card issuers only authorise transactions from genuine cardholders, by using data from at least 2 of the following 3 categories:

Knowledge

Something only the customer KNOWS e.g. a PIN, a password, a one-time passcode sent to the cardholder.

Possession

Something only the customer has e.g. a card/smartcard, a mobile phone/smartphone with a banking app.

Inherence

Something only the customer IS e.g. biometrics such as a fingerprint, iris scan, voice or facial recognition.

 

What specific changes / actions do I need to make (as a merchant)?

To make the required changes to your e-Commerce solution, please follow the guidance below:

If you use our gateway EVO E-PAY to submit card transactions

  • and currently don’t use 3-D Secure, please inform us by e-mail to support.emea@evopayments.com about the desired activation of 3DS 1.0 and indicate the EVO contractor ID of your agreement as well as the client number. The activation will then be performed at short notice and free of charge for you. All other conditions remain unchanged.
  • please contact your Implementation Manager to obtain the technical reference with details of the changes you are required to make to support 3DS2 and submit the additional data for an improved transaction risk analysis.

If you use a 3rd party gateway / payment service provider (PSP)

  • and currently don’t use 3-D Secure please first contact your payment service provider (PSP) with the request to activate 3DS 1.0. At the same time, we (EVO) must register you with the credit card organisations and activate you in our systems. Please inform us by e-mail to support.emea@evopayments.com about the desired activation of 3DS 1.0 and state the EVO contractor ID of your agreement as well as the client number. The activation will then be done at short notice and free of charge for you. All other conditions remain unchanged.
  • please contact your 3rd party gateway / payment service provider (PSP) to obtain details of the changes you are required to make to support 3DS2.

If you are in any doubt

What will happen if merchants do not make the changes to support SCA by 1 January 2021?

If you do not make the required changes to support SCA your e-Commerce transactions will be declined by issuers.

EMV® 3-D Secure security standard

EMV® 3-D Secure (also known as 3-D Secure 2.x or 3DS2) is the successor to 3-D Secure 1.0 (also known as 3DS1). Although 3DS1 is compliant with the PSD2 SCA requirement, 3DS2 was introduced to improve cardholder authentication and enhance security through the use of enhanced data, enable the use of exception handling and improve the customer experience, regardless of payment device type/payment channel:

3-D Secure 1.0 (Verified by Visa, Mastercard SecureCode) 3-D Secure 2.x (Visa Secure, Mastercard Identity Check)
PSD2 compliant
Seamless transition from shop to authentication Limited
Optimized authentication Limited One-time password, fingerprint or biometric data
Extended data Limited Ten times more than 3DS1
What impact does SCA have on liability for e-Commerce fraud-related disputes?

When SCA is applied to a transaction, merchants/acquirers avail of protection in the event that a fraud-related dispute occurs. When SCA is not applied and the transaction results in a fraud related dispute, the merchant/acquirer is liable for the fraudulent transaction. 

Please note: 3DS protects against fraud related disputes. It does not protect against all chargeback disputes i.e. non-fraud related disputes such as goods / service not being as described or non-delivery related disputes.

The following diagram shows the merchant and issuer options and merchant-issuer liability for each option:

Please note: 3DS only protects against chargebacks related to fraud. 3DS does not protect against chargebacks due to, for example, "Goods do not correspond to the description in the merchant's store or are defective" or "The cardholder did not receive the goods/services/credit note".

Schematic process of 3-D Secure 2.x
Overview of Exemptions

Description:
Remote transactions up to and including 30 EUR do not require SCA up to a maximum of 5 consecutive transactions or a cumulative limit of 100 EUR

What action is needed by merchant?
Merchants may need to make changes depending on e-Commerce product type and integration method (see your relevant implementation guide). 
Only the issuer can determine when the transaction counter or cumulative limit is reached and (if yes) will request authentication.

Description:
The TRA exemption allows for certain remote transactions to be exempted from SCA provided a robust real-time risk analysis is performed, and acquirers meet specific fraud thresholds. It is therefore also referred as the “low risk” exemption. TRA is key to delivering frictionless payment experiences for low-risk remote transactions. Issuers and Acquirers can both apply the TRA exemption so long as they meet certain requirements, including achieving fraud to sales rates within the specific fraud thresholds for card payments, set out in table below:

Transaktionswertband PSP-Betrugsrate
< €100 13 bps / 0,13 %
€100 - €250 6 bps / 0,06 %
€250 - €500 1 bps / 0,01 %

What action is needed by merchant?
This exemption relies heavily on the data provided for a transaction, so that the issuer / acquirer can assess the risk of a transaction properly. Therefore, it is highly suggested to provide all the information on a transaction as well as the cardholder. What information you as a merchant or your PSP has to provide depends on your integration method.This is explained in the relevant guide from EVO or your 3rd party gateway. For the acquirer’s side, EVO is planning to offer this exemption type in the near future.

Description:
Applicable when the customer makes a series of recurring payments for the same amount, to the same business. SCA is required for the customer’s first payment - subsequent charges however may be exempted from SCA.

Note: Visa does not consider recurring payments an exemption as they are part of their MIT network and thus in their opinion they are out of scope of SCA.

What action is needed by merchant?
The transactions must be flagged as a recurring transaction according to your PSP’s specifications in order to qualify for an exemption application. You also need to provide the trace ID of the first payment.

Description:
Cardholders may add a merchant to a list of whitelisted/trusted beneficiaries held by their Issuer. Subsequent payments to such merchants do not require SCA. 

What action is needed by merchant?
This is primarily an issuer exemption as the needed information is stored by the issuer.The flagging of the granted issuer exemption in the authorization is managed by your PSP – no action needed.

Description:
Payments made through dedicated corporate processes and protocols (e.g. lodge cards, central travel accounts and virtual cards) which are initiated by business entities, not available to consumers and which already offer high levels of protection from fraud may be exempted from SCA, subject to the view of the relevant competent authorities. 
Lodge Cards, Central Travel Accounts and Virtual Cards that are not associated with an individual cardholder and are used within a secure dedicated corporate payment process are examples that may fall into this category.

What action is needed by merchant?
This is primarily an issuer exemption as the needed information is stored by the issuer.The flagging of the granted issuer exemption in the authorization is managed by your PSP – no action needed.

For all exceptions, the issuer makes the final decision. If the acquirer/dealer requests an exception, the final decision is therefore made by the issuer.

Overview of Exclusions

Description:
Due to their very nature, payments made through the use of an anonymous payment instruments, such as anonymous prepaid (such as, gift) cards, are not subject to the obligation of strong customer authentication.
The Issuer is the only one able to identify this type of card. The Acquirer will not be able to identify from the primary account number that the product is an anonymous product.

What action is needed by merchant?
Managed by your PSP – no action needed.

Description:
Payments transacted by email or telephone are not considered to be electronic payments, and therefore, are deemed out of scope for SCA.

What action is needed by merchant?
Ensure your MOTO transactions are correctly coded for all cardholder purchase / payment scenarios.

Description:
SCA regulations apply only to transactions made entirely within the EEA. If issuer or acquirer is domiciled outside the EEA (“One-leg out”), no SCA mandates apply. The nationality of the cardholder nor the merchant's business location are relevant for the assessment as to whether a transaction is out of scope due to the “one-leg” rule. EVO Risk policy and systems can influence if SCA should be applied in such instances.

What action is needed by merchant?
Managed by your PSP – no action needed. Issuers and acquirers may still require SCA to be applied to one-leg transactions. EVO’s current policy will require SCA for one-leg transactions.

Description:
SCA is required for the customer’s first payment where the cardholder agrees to the terms and conditions of later subsequent charges. These subsequent charges however are excluded from SCA, provided that the cardholder is not present in the check-out flow (sometimes referred to as off-session) at the time when the charge occurs. This category also includes subsequent recurring payments.

What action is needed by merchant?
The transactions must be flagged as a Recurring or MIT according to your PSPs specifications/ MIT framework in order to be approved by the Issuer’s as not requiring SCA. You also need to provide the ID of the first (Cardholder initiated & SCA authenticated) payment.

FAQ

An SCA exemption means that the acquirer / merchant requests an exemption (aiming to achieve a frictionless transaction without SCA) and the issuer then decides whether SCA is required. If yes, the issuer will trigger the authentication (challenge request) flow to authenticate the cardholder. An exclusion (“out of scope” transaction) does not require any authentication obligation and decision / flow, provided it is flagged correctly.

  • ‘One Leg out’ (OLO) transactions
    Transactions where the Payment Service Provider (PSP) of either the payer (i.e. the issuer) or of the payee (i.e. the acquirer) are located outside of the EEA. 
  • Mail Order/Telephone Order (MOTO) including Virtual Terminal (VT) 
    MOTO transactions are not considered to be electronic payments, and therefore are out of scope of the regulation. 
  • Merchant Initiated Transactions (MITs)
    A series of payments with a fixed or variable amounts that the merchants performs without direct involvement of the cardholder e.g. subscriptions. 
  • Anonymous Cards e.g. anonymous prepaid cards 

For all exclusions (out of scope transactions), acquirers and issuers may decide to apply SCA to the transaction, and the final decision is taken by the issuer.

The table above (Link) provide a summary and additional information.

No. Mail order and telephone order (MOTO) / Virtual Terminal (VT) transactions are out of scope for SCA, as they are not considered to be electronic payments. Merchants should continue to process these as they do today.

No, you must apply SCA for all e-Commerce transactions unless they are out of scope or an exemption is being requested. Even if a merchant flags a transaction as exempt, the issuer still has the final say and may require the transaction to be authenticated.

EVO will support all acquirer exemptions subject to relevant risk policies and assessments e.g. for the local market, specific business types, individual merchant risk as applicable. EVO will be implementing a TRA exemption in 2021 and will advise you when this becomes available.

No, it applies to the acquirer and issuer – depending on who wants to request the exemption.EVO is planning to use the TRA exemption and will confirm when this becomes available. 

All available data should be provided wherever possible to ensure an optimal cardholder and merchant experience and reduce transaction friction (challenge rate). The more information you include, the greater the chance that the issuer will not challenge the cardholder with SCA, as it leads to a more informed decision making process.

Whilst the benefit of SCA will be to reduce online card payment fraud levels, it is expected that the changes may also affect conversion rates of people using their card online. If you do not implement the changes needed to support 3DS2 you will see an increase in declined transactions.

As with any new technology it may take time for cardholders to become familiar with the process and SCA may lead to an increased number of abandoned transactions in the short term whilst the number of transactions requiring authentication is expected to decline.Over time 3DS2 is expected to increase consumer confidence in buying on-line reduce fraud and reduce abandonment rates due to enhanced data flows. 

If you are in any doubt, please contact support.emea@evopayments.com immediately. We also recommend that you read the latest Visa and Mastercard Merchant Best Practice Guides and PSD2 SCA information, which can be found here: