Last updated October 1, 2019.
On September 14, 2019, Strong Customer Authentication (SCA) requirements went into effect in Europe. These new requirements are part of the revised Payment Services Directive (PSD2) regulations and mandate that additional authentication measures be performed on certain electronic transactions. For the latest information on the ever-evolving regulatory landscape, please refer to our SCA cheatsheet.
SCA has been the source of a lot of questions -- and a lot of uncertainty -- for merchants who do business in the affected countries. To help address those questions, we’ll look more closely at SCA, including details on what’s required, key dates, information on exemptions, and an introduction to the latest update of the 3D Secure protocol -- the solution that Braintree is recommending merchants adopt in order to be SCA-ready.
Under PSD2, merchants will be required to use SCA on applicable transactions when executing a payment. SCA mandates that two-factor authentication be performed on electronic payment transactions involving cards. That means that for a transaction to be approved, merchants must collect and provide the card issuers with two of the following independent authentication factors:
SCA will be required on card transactions in which both the merchant’s acquiring bank and the bank issuing the buyer’s debit or credit card are located within the European Economic Area (EEA). The affected countries/regions include: Austria, Belgium, Bulgaria, Croatia, Republic of Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, and the United Kingdom (including Guernsey, Jersey, and the Isle of Man).
Braintree merchants located in Switzerland, Andorra, Monaco, and San Marino will also need to meet SCA requirements because their acquirer is located in the EEA.
SCA requirements will not apply to transactions processed on non-EEA-issued cards. It will also not apply to merchants that contract with acquiring banks licensed outside the EEA, even if the card is issued in the EEA region.
Under the regulatory guidelines, exemptions to SCA requirements will be allowed for certain types of transactions. Obtaining an exemption essentially allows a transaction to take place without adhering to the SCA requirement of needing two factors of authentication. Braintree’s SCA-ready solution will have the capability to pass flags and indicators when exemptions are requested -- in other words, we will accommodate SCA exemptions if our merchants choose to use them.
Let’s look at the exemptions that apply to transaction types supported by Braintree:
Low-value transactions are considered those that total less than €30 each, but no more than five transactions on a payment instrument in a row can skip SCA based on this exemption, and SCA is required if the customer’s total payments exceed €100 since the last time SCA was applied. Since the information needed to validate these criteria is only available to the issuing bank, merchants will still need to confirm if SCA is required on all transactions that might fall into this exemption category and not any of the others described below.
This exemption will allow an acquirer to request approval from issuing banks to avoid SCA up to certain transaction-amount limits based on the acquirer’s overall fraud rate, calculated on a rolling quarterly basis (90 days). This applies to all transactions and all merchants if the transaction is deemed low-risk during the acquirer’s real-time risk assessment, but the final decision on whether the exemption can be claimed on the transaction rests with the issuer on a case-by-case basis as part of the issuing bank’s own risk analysis. The lower the acquirer’s overall fraud rate, the higher the limit of low-risk transactions that can be claimed as exempt, as shown here:
In some cases, corporate payments rely on other security methods that would then exempt the transactions from SCA. These include corporate card payments made through secure processes and protocols as well as lodged corporate cards, which are used for employee travel and managed directly by a travel agent. Corporate cards that are not processed using these additional security methods, such as traditional employee corporate purchase cards (P-cards), will still be subject to SCA.
Consumers can add businesses they trust to a list of trusted beneficiaries held by the issuing bank. SCA is required to add a merchant to a cardholder’s list, so that payments to the merchant will not require SCA until the cardholder removes that merchant from his or her trusted beneficiary list.
It is still unclear how banks will manage their cardholders' beneficiary lists or even how many banks will choose to offer this, particularly in the early months following the SCA enforcement deadline. Braintree will continue to stay close to developments related to this exemption to ensure that merchants and cardholders alike can take advantage of this exemption when technical solutions become available.
Exemptions have the potential to reduce checkout friction and customer drop-off by decreasing the number of times a customer needs to be authenticated. On the surface that may seem ideal, but the reality may not be so straightforward. Before seeking exemptions, we recommend merchants familiarize themselves with some of the nuances around this topic -- including how and when to seek them and the ways obtaining them could affect the ability to shift liability for fraud-related chargebacks and negatively impact the transaction lifecycle -- so they can build the right strategy for their business.
It’s also important to remember that the decision to accept the exemption will ultimately fall to the issuer. Each issuer will have different risk-analysis models that inform their decision, and some may not even have the infrastructure in place to support certain types of exemptions -- especially in the short-term. It’s also likely that some exemptions will be more widely accepted than others, and they could even vary from market to market depending on how issuers in different countries/regions decide to handle them.
Under the terms of PSD2, certain types of transactions will be considered out-of-scope and therefore will not require SCA.
Here are the transaction types supported by Braintree that will be considered out-of-scope:
For merchants that have particular types of interactions with their repeat customers, merchant-initiated transactions (MITs) can provide an opportunity to avoid multiple authentication requests in cases where the cardholder is not present. Merchants offering a recurring or metered billing model (e.g: a subscription service or utility bill) will only need to apply SCA to the first transaction (or verification while vaulting a card in the Braintree Vault). Subsequent transactions (when the customer is not in session) will then be considered merchant-initiated and out-of-scope for SCA.
Once strong authentication requirements are enforced, merchants who do not perform SCA on transactions that require it are likely to see an increase in declines. 3D Secure 2 (3DS2) is an industry-standard solution for SCA that can help merchants meet requirements and protect their revenue. This solution provides a simple way to authenticate transactions with a no- to low-friction checkout experience for cardholders, and allows merchants to shift liability to the issuers on authenticated transactions to help reduce costs associated with chargebacks categorized as fraud. Braintree’s 3DS2 solution also offers built-in support for both 3DS2 and 3DS1 protocols and can automatically divert your transactions, so you can be sure your business will be SCA-compliant regardless of issuer readiness.
Get details on the industry-standard solution for meeting PSD2’s Strong Customer Authentication (SCA) requirements.
Read more
Authentication will vary based on transaction types and business models. Here, we take a closer look at how SCA can be applied to some common payment scenarios and flows.
Read more
