As you may be aware, Strong Customer Authentication (SCA) will be in effect as 14th September 2019, across the European Economic Area (EEA). Below you will find many of the frequently asked questions regarding: Strong Customer Authentication, PSD2 and 3D Secure V2, to help you through the transition and enable you to better understand what it means.



WHAT IS PSD2?


The second European Payment Services Directive (PSD2) is a European directive which came into force across the European Economic Area (EEA) on January 13, 2018. PSD2 was established to established to drive payments innovation and data security by reducing competitive barriers, mandating new security processes and encouraging standardized technology to protect the confidentiality and integrity of payment service users’ personalized security credentials.

PSD2 requires banks to support Open APIs to enable consumers to make payments directly from their bank accounts via newly-regulated third-party payment service providers.

 

WHAT IS STRONG CUSTOMER AUTHENTICATION (SCA)?


The security measures defined around SCA introduce requirements that issuers and acquirers must observe when they process payments or provide payment-related services.

In general terms, card issuers will be obliged to perform an SCA check for every electronic payments transaction above €30 that does not meet specified exemption criteria. The SCA check requires authentication using two of the following three factors:

  • Something the cardholder knows E.g., a password or PIN

  • Something the cardholder has E.g., a token, a mobile phone

  • Something the cardholder is E.g., a fingerprint or voice match


 

IS THERE ANY FLEXIBILITY ON THE SEPTEMBER 14, 2019 DEADLINE?


In response to uncertainty and unreadiness of merchants to meet the September 14, 2019 secure customer authentication (SCA) deadline, the European Banking Authority (EBA) have issued this opinion paper.

The EBA concludes that The National Competent Authority (NCA) of each European country may "provide limited additional time" for issuers, acquirers and merchants to migrate to SCA-compliant solutions. Key markets including France and Italy have already implemented a grace period, with other key markets likely to follow.

However, the EBA opinion does not specify what form this migration plan should take. Furthermore, the delegation of this responsibility to each region’s NCA is likely to result in a 4 divergent European regulatory environment that poses challenges to organizations operating internationally.

In light of this, Quaife supports the recommendation of The European Association of Payment Service Providers for Merchants (EPSM). The EPSM have proposed that extended timeframes should be harmonised across all regions affected by this regulation. Mastercard have similarly called on NCAs to agree on ‘collective migration plans [based on] a harmonized European roadmap.’

Until confirmation has been received, on the process merchants should follow to request an extension, customers are still recommended to work towards meeting SCA requirements in advance of September 14, 2019.

 

WHEN IS SCA CHECK REQUIRED AND WHAT ARE THE EXEMPTIONS?


SCA checks are mandated for every electronic payment over €30 – and for those under €30 where either there have been five previous transactions on the same card without SCA being applied or the card has accumulated transactions totaling more than €100 without an SCA check being applied.

Transactions out of scope for SCA include:

  • Recurring transactions (after the first transaction has been authenticated)

  • MOTO transactions (Mail/Telephone order)

  • One-leg-out transactions (where the card is issued or the merchant is based outside the EEA)

  • Direct debits


While card issuers can try to reduce the number of cases in which SCA is required, there is no way to prevent it fully. In cases where SCA is required but does not take place, the issuer has to soft decline the authorization request.

Transactions that are in scope may be rendered exempt from SCA if the cardholder has applied to have the merchant with which they are transacting whitelisted with their bank (card issuer), and the bank has agreed. Under PSD2, individual cardholders may ask their issuers to “whitelist” merchants they use regularly — but the decision will ultimately be at the bank’s discretion — and will depend on the level of fraud exposure the bank has experienced with the chosen merchant.

Issuers and acquirers may also render a transaction that is under €500 exempt if they have demonstrably low levels of fraud. This requires that transaction risk analysis (TRA) is in place and fraud is kept below set exemption threshold values (ETV).

These values are:

  • 0.13% for transactions up to €100

  • 0.06% for transactions up to €250

  • 0.01% for transactions up to €500


It is expected that issuers will apply the TRA exemption as much as possible to reduce the friction and frequency of SCA that their cardholders will encounter during remote purchases. In some cases, issuers may request SCA even if the acquirer has implemented an exemption — if they are suspicious about the transaction.

Only issuers and acquirers can exempt a transaction from SCA. There are exemption flags in 3DS for a merchant to request an exemption.

 

IS FRAUD SCREENING STILL REQUIRED?


Merchants are encouraged to continue screening their transactions in order to keep their fraud rate low. This means that the acquirer, who is responsible for fraud scoring across the breadth of their merchant base, can grant TRA exemptions to merchants who are effectively managing their fraud levels.

 

WHAT HAPPENS WITH FRAUD LIABILITY IN THE CASE OF EXEMPTIONS?


The liability for transactions will sit with the issuer when a transaction has been authenticated using SCA. The liability remains with the issuer if the issuer applies a TRA exemption to SCA. When an exemption to SCA is applied by the acquirer using a TRA exemption, the liability will be transferred to the acquirer, unless the issuer challenges the transaction.

 

SHOULD SCA BE APPLIED FOR ONE-LEG OUT OR RECURRING TRANSACTIONS?


One-leg-out transactions are those where either the issuer or the acquirer are located outside the European Economic Area (EEA). While these transactions are out of scope for SCA, it is expected that SCA should be applied on a ‘best effort’ basis.

As for recurring transactions, any transactions/installments after the initial authorization are flagged as merchant-initated transactions (MIT). MIT is out of scope for SCA, and as such it does not need to be applied. This applies even if the initial authorization did not go through SCA.

 

IS THERE ANY EFFECT TO CARD-PRESENT (CP) TRANSACTIONS?


While the majority of requirements around SCA relate to card-not-present (CNP) transactions, SCA will also be required for some card-present (CP) contactless payments based on value and velocity. Contactless transactions are exempt from SCA if they meet the following conditions:

  • Payments over €50 in Europe, or £50 in the United Kingdom; and

  • Five consecutive payments without consumer authentication; or

  • Cumulative payments to the value of €150 without consumer authentication


A majority of cards currently in circulation were not implemented with these velocity limits, which is expected to be rectified in the device implementation.

 

WHAT IS 3D SECURE?


3D Secure is a customer authentication protocol introduced by EMVCo and leading card schemes, designed to reduce fraud rates and provide security to merchants and shoppers for card-not-present transactions. 3D Secure V1 is already widely in use today, but does not enforce modern secure authentication methods and frequently relies on archaic authentication methods such as static passwords.

 

WHAT IS 3D SECURE V2?


3D Secure V2 is the latest version of the 3D Secure protocol. 3D Secure V2 includes several key changes to the handling of card-not-present payments. Critically, these changes ensure the protocol is fully in line with the PSD2 regulatory technical standards around SCA, which come into 6 effect on September 14, 2019. Furthermore, the updated protocol is designed to help streamline the customer journey by reducing or removing points of friction, ultimately improving checkout conversion rates as well as reducing fraud.

 

WHAT ARE THE BENEFITS OF 3D SECURE V2 COMPARED TO PREVIOUS VERSIONS?


There are several benefits to merchants, issuers and shoppers as a result of 3D Secure V2. Broadly, the changes ensure a streamlined customer journey with fewer friction points to reduce the high rate of shopping cart abandonment from 3D Secure V2. These enhancements include:

  • Risk-based authentication. 3D Secure V2 will support the transmission of additional rich data during transactions, making authentication assessments and decisions more accurate. The issuer will be able to evaluate the fraud risk and bypass full authentication if the risk is low enough, resulting in a smoother customer journey for low-risk shoppers. This risk-based approach to authentication is entirely aligned with PSD2 guidance on SCA.

  • Biometric or two-factor authentication. If the issuer (after performing an initial assessment) determines that authentication is required, either biometric or two-factor authentication will be performed to validate the shopper. The biometric authentication methods available will depend on what is supported.

  • Eliminates initial enrollment. The removal of this one-time step in the 3D Secure flow eliminates a major point of friction in the customer journey upon first-time use.

  • Support for in-app purchases. Unlike 3DS V1, which required a browser call-out to complete authentication, 3DS V2 can handle in-app purchases natively. This avoids compatibility issues experienced within some apps for browser authentication callouts.

  • Allows for bespoke checkout integration. Should they wish, merchants can now integrate the 3-D Secure authentication process into their own checkout process, resulting in a much smoother experience for shoppers.

  • Support for non-payment authentications. The latest 3D Secure version offers support for no-value authorizations, such as tokens for card-on file. Note that it is mandatory to perform an SCA check such as 3D Secure to add a new card as a card on-file. Subsequent transactions do not have to go through 3D Secure, but need to reference the original transaction and the amount cannot differ by more than 15%.


 

WHAT ARE "FRICTIONLESS FLOW" and "CHALLENGE FLOW"?


As mentioned previously, risk-based authentication based on rich data is a key feature of 3-D Secure V2. If the issuer determines the transaction is low-risk, they can bypass full authentication altogether – this is referred to as “frictionless flow”. If the issuer decides to go ahead with full authentication, this triggers what is known as the “challenge flow”, which more closely mirrors the 3-D Secure V1 workflow.

In the authentication phase, the 3DS server sends information about the cardholder to the directory server. It is then forwarded on to the correct access control server, which performs a risk check to determine next steps.

If risk is determined to be low, the payment continues with no further interaction between the issuer and cardholder. This is frictionless flow.

If the issuer decides the shopper needs additional authentication, the cardholder interacts with the issuer to authenticate themselves biometrically or using two-factor authentication. This is the challenge flow.

 

WILL 3D SECURE V1 REMAIN AVAILIBLE?


Quaife.net will continue to support 3-D Secure V1 alongside V2, until further notice from card schemes on timings for deprecation of the older version.

 

WHAT ARE THE DIFFERENCES BETWEEN 3D SECURE 2.0, 2.1 AND 2.2?


The specs for EMV 3D Secure 2.0 were first published by EMVCo in 2016, with subsequent versions adding additional functionality. Version 2.1 introduced frictionless authentication, shorter transaction times, and uses 10 times more data than version 1.0.

The payments ecosystem is currently adapting to the latest version (2.2), which includes support for exemptions for additional types of frictionless authentication. This includes acquirer-side transactional risk assessment, low-value transactions and whitelisting of merchants. Current plans for future versions include further enhancements to transaction risk assessment and support for devices other than web browsers and mobile devices.

 

WILL MERCHANTS REQUIRE NEW MERCHANT IDs (MIDS)?


It is important to differentiate between two types of merchant IDs:

  • The first type of merchant ID is assigned by the acquirer, and will not change as a result of implementing 3D Secure V2.

  • The second type of merchant ID is assigned by the schemes, and is also frequently referred to as a ‘Requestor ID’. If the merchant is already enrolled for 3-D Secure V1, the same merchant ID can be retained for 3D Secure V2. However, the Requestor ID will not be automatically enrolled for 3-D Secure V2. As such, the merchant or Quaife.net will need to ensure that their Requestor ID is enrolled with the scheme, or a new merchant ID will need to be requested.


 

IS AN UPGRADE TO 3D SECURE V2 REQUIRED, AND IF SO, WHEN BY?


Europe:

Customers in Europe are strongly recommended to migrate to 3-D Secure V2 by September 14, 2019, when the PSD2 regulatory technical standards on SCA are scheduled to come into effect. Note that Mastercard have indicated that payments processed by 3-D Secure V1 remain compliant with the "letter of the law" of SCA. However, 3-D Secure V2 is recommended to ensure full "operational readiness" by "[unlocking] full use of exemptions".

Transactions in the EEA that do not meet SCA requirements (those that do not pass through 3-D Secure or equivalent authentication) are liable to be declined by the issuer after this date.

Rest of the World

Mastercard and Visa have mandated issuers to adopt 3-D Secure V2. Mastercard imposed a mandate deadline of April 1, 2019 for issuers globally to adapt to the new protocol. Visa have provided the following mandate schedule:

  • Europe: April 12, 2019

  • North America and Latin America: August 15, 2019

  • Rest of World: April 18, 2020


 

HOW WILL QUAIFE.NET SUPPORT 3D SECURE V2?


Quaife.net are currently working to ensure readiness for 3-D Secure V2 across our affected card-not-present solutions.

 

3D SECURE V2 READINESS

Quaife.net already supports 3-D Secure V2 in the customer testing environment. Production availability is expected from mid-August for Visa, Mastercard and American Express.

 

CONNECTORS

Quaife.net is currently working to update those connectors that require (including all major European acquirers) in order to ensure preparedness for the European SCA deadline of September 14, 2019.

 

HOW DO MERCHANTS IMPLEMENT 3D SECURE V2?


 

COPYandPAY

For customers integrated via COPYandPAY, the upgrade will be very simple. The COPYandPAY widget is updated to be able to handle the front-end interaction between the cardholder and the issuer. Customers will simply need to ensure they are sending the mandatory billing/customer fields, set the MPI type in the BIP interface and configure the merchant account. The look and feel of COPYandPAY will not change from the current version.

Server-to-Server

Customers integrated via Server to Server will need to be prepared to collect and send additional data fields to be used for risk-based authentication. The following information will need to be sent:

  • Browser Accept Header

  • Browser Language

  • Browser Screen Height

  • Browser Screen Width

  • Browser Timezone

  • Browser UserAgent

  • Browser IP Address

  • Browser Java Enabled

  • Browser Screen Color Depth When the challenge flow is triggered, the issuer will provide the


HTML that should be rendered on the merchant’s website (either in a lightbox or iFrame) where the user interaction with the access control server (ACS) will happen. The requirements from EMVCo are the following:

  • During the risk assessment phase, the merchant website should display a graphical element (e.g. a progress bar) indicating to the cardholder that processing is ongoing.

  • Include the logo of the card scheme, but don't include other graphical elements.

  • Display this processing screen at least for 2 seconds.