Table of Contents
- Introduction and Background
- Why is SCA Needed?
- Where SCA Applies
- What Does SCA Mean for Card-present?
- What Does SCA Mean for eCommerce?
- Exemptions
- What Do I Need To Do To Be Ready for SCA?
- 3DS1 Sunset
Introduction and Background
The EU Payments Services Directive (PSD2) brought in new laws in January 2018 to improve consumer rights and reduce many kinds of payment fraud. An important element of PSD2 is the introduction of additional authentication of transactions, known as Strong Customer Authentication (SCA), also commonly known as 2-factor authentication.
It applies to all types of electronic payment transactions, although we’re mainly concerned with cards. For certain transactions using a card or smartphone, the cardholder will need to provide additional identification. This could be, but not limited to, a PIN, an answer to a personal question, a one-time passcode sent to a device such as a mobile (which proves possession of that trusted device), or a biometric such as face recognition or fingerprint.
For online (eCommerce) card transactions, the means of achieving SCA will generally be through the use of EMV® 3-D Secure Version 2 (3DS2) or other methods that provide a second version of authentication, such as Google Pay or Apple Pay. This supersedes 3-D Secure Version 1 (3DS1) which was introduced in 2001. Although 3DS2 is the preferred method for 3-D Secure in eCommerce, PSD2 does not mandate how SCA is performed, and since 3DS1 provides a second factor of authentication it is also compliant with PSD2 guidelines.
Why is SCA Needed?
Payment fraud losses overall have continued to rise over the past decade after the drop brought about by Chip and PIN in the early 2000s. This increase has mainly been in the area of eCommerce and card-not-present (CNP), although the convenience of EMV contactless transactions has also been seized upon by criminals as a fraud vector. The European Banking Authority intervened by placing SCA requirements on participants to reduce fraud, as one of the core components of PSD2.
SCA will be fully required by issuers by 14th March 2022. Merchants not following the required SCA/PSD2 behavior documented below may see an increased number of soft declines. These soft declines are preventable so long as the merchant adheres to this article.
Common acquirer response codes for SCA-related soft declines are often either 65 or 1A.
Where SCA Applies
Merchants in the UK and Europe
SCA applies to transactions in the EEA and the UK only, where both payer and payee are in the region. When either the acquirer or issuer are based outside the EEA, this is referred to as a ‘One-Leg Out’ (OLO) transaction and this is out of the scope of SCA.
Merchants in the US or Elsewhere Outside the UK and Europe
Where a US merchant uses a UK or EEA acquirer for a particular reason, SCA will be applied to transactions made by cardholders using UK or EEA issued cards and the merchant will need to support 3DS or a similar alternative solution. SCA will not apply to transactions made by cardholders with US-issued cards in this circumstance though, as that would be classed as ‘One-Leg Out’ (OLO) so out of scope of SCA.
What Does SCA Mean for Card-present?
For card present, SCA is going to bring in soft declines where the issuer of the cardholder’s card sends back the instruction to prompt for PIN entry in the authorization result. So you could tap your card, see it go online, and then have the device ask you to insert your card and enter your PIN.
Due to SCA rules, there will also be fewer instances where devices without PIN pads are allowed to be deployed. Only unattended terminals for passenger transport fares, road tolls, and parking fees will remain exempt, and additionally for the UK, contactless charitable donations. Devices without PIN pads that are already deployed in non-exempt usage will start to see higher levels of declines because they aren’t able to handle the request to prompt for strong cardholder authentication. From a cardholder’s perspective, the only option in this situation is to try another card.
What Does SCA Mean for eCommerce?
Online shoppers will see more challenges for authentication to prove they are the card owner. With 3DS1, issuers typically require a password to be entered to verify the transaction.
3DS2 is far more sophisticated and improves the checkout experience compared to 3DS1, using over 100 data elements (such as the customer’s shipping address, device fingerprint, and payment history) sent to the issuer to better assess its risk level. This all takes place behind the scenes within the checkout process, meaning a smoother, more secure payment flow. Based on this data, the issuer will either authorize the payment without challenging the cardholder (frictionless-flow) or challenge the cardholder (step-up) to provide additional information to authenticate the transaction by, for example, entering a one-time passcode sent to their mobile device.
Exemptions
Not all transactions will require additional authentication. PSD2 provides several exemptions to SCA, to minimize friction in customer payment journeys. Those relevant to NMI customers are:
- Low-value
- MCC-specific
- Recurring payment
- Allow listing (or trusted beneficiary)
- Mail order / Telephone order (MOTO)
Low-value Exemption
Card transactions below €50 are considered low value and are generally exempt from SCA. However, if the customer initiates more than five consecutive low-value payments or if the value of the total payments exceeds €100, SCA will be required.
Specific Merchant Category Code (MCC) Exemption
Unattended transactions from MCCs 7523 (Parking), 4784 (Road and Bridge Tolls), and 4111 (Passenger Transportation Ticketing) are exempt from SCA. In the UK, Contactless charity donations from 8398 (Charities) are also exempt from SCA.
Recurring Payment Exemption
Series of payments of the same value to the same merchant (such as subscriptions and membership fees) are exempt after the initial setup using the Credential on File transaction flow. The initial setup of the recurring payment will still require authentication (and the transaction is flagged to the issuer as a Customer-Initiated-Transaction Credential on File authorization), but all subsequent Merchant-Initiated-Transaction Credential on File transactions will be exempt.
Payments that are made periodically to the same payee, but where the value changes each time (e.g. a utility bill), will not benefit from the exemption.
Trusted Beneficiary
Cardholders will have the option to allowlist a merchant they trust. They can request to have the trusted merchant be added to their record with the issuers after the first authentication is completed. Subsequent transactions with the allowed merchants are likely to be exempt from future authentication, however, issuers can still reject this request if the cardholder is thought to be a high fraud risk.
In a card-present scenario, the convenience of contactless at point-of-sale would remain for low-value transactions (less than €50). Chip and PIN is still common practice in the EEA for values above €50.
Mail Order / Telephone Order (MOTO) Transactions
These are outside the scope of SCA.
What Do I Need To Do To Be Ready for SCA?
From the announcement of PSD2 SCA in 2017, NMI has been actively involved with industry discussions and has been updating our systems and the Software Development Kits (SDKs) that we make available to merchants and distributors as the program has advanced.
Card-present Solutions
If your equipment uses payment devices that do not have a PIN pad to allow SCA, and you start to see increased numbers of soft declines there are several options available:
- Provide signage or instructions to cardholders to try another card if their first is declined
- Encourage the use of Apple Pay and Google Pay since these payment methods do authenticate the payer through a secondary, usually biometric, means
- If your equipment is on an exempt MCC, such as parking or tolls, contact your acquirer and raise a support case, as transactions should be getting flagged to issuers as SCA exempt
- Speak with your terminal provider or NMI account manager to discuss payment devices supporting PIN
Payment SDK
Version 2.20 or above needs to be installed (version 3.01 if terminals need to support Online PIN in certain EU countries) to handle SCA responses with supported devices. Ingenico RAM devices must be running RAM 2129 at a minimum.
Card-Present Cloud
No changes are required, the solution will update the devices as necessary and handle SCA challenges.
Direct Connect (Formerly ChipDNA Direct)
We recommend using the latest versions for up-to-date SCA handling. For further information, see EMV Card Present - Soft Decline SCA Flow
eCommerce
As part of 3DS2, the first and last name of the cardholder is now required in order to successfully complete a transaction with 3DS2. Please ensure your integrations prompt for this information.
Hosted Payment Page (formerly eKashu)
NMI’s Hosted Payment Solution has been updated to support 3DS2 version 2.1.0. Your merchant account must have an MCC and be enabled for 3DS.
Direct Connect (Formerly ChipDNA Direct)
An updated 3DS2 plugin (NMI 3-D Secure Server (3DS2)) is available for integrators with support for version 2.1.0. Please note the existing 3DS1 Merchant Plugin does not support 3DS2.
Payment API (Formerly Direct Post)
Additional implementation of NMI's Gateway.js is available for integrators to use with the Payment API solution and supports 3DS2 versions 2.1.0 & 2.2.0. When requesting enablement of the Payer Authentication Service, you must provide the following additional information:
- Requestor Category Code/Merchant Category Code
- Requestor Name/Merchant Business Name
- Requestor ID/Merchant ID
CNP Payments
CNP transactions cannot have 3DS as the cardholder isn't present to validate the 3DS challenges. Therefore, 3DS is only available for eCommerce transactions.
Hosted Payment Page (Formerly eKashu)
The transactions should be flagged as CNP/MOTO to ensure the card issuer doesn't reject transactions due to a lack of 3DS/cardholder validation. This is done by providing the following field within your Hosted Payment Page post data: ekashu_3d_secure_bypass = true
Recurring & Tokenized Payments
There has been a shift for recurring payments (known as tokenized payments) to include Credential on File indicators. These additional fields provide the issuing bank with further information on the authorization request. If you are performing tokenized payments, they should be flagged as CoF transactions accordingly so long as the acquirer certification permits it.
3DS1 Sunset
Visa, Mastercard, and American Express intend to end support for 3DS1 in October 2022. As a result, we have provided a list of key dates below:
- 16th March 2022
- The Payer Authentication service for NMI’s Payment API will no longer allow 3DS1 registrations, only version 3DS2 will be selectable via the UI.
- 31st March 2022
- Visa, Mastercard, and American Express will no longer allow 3DS1 enrolments. All newly enrolled merchants should be using 3DS2 from this date.
- 14th October 2022
- Visa, Mastercard, and American Express will no longer permit 3DS1 to be used for cardholder authentication. All merchants must be processing 3DS2 *.