The 3DS 2 Guide for Payment Professionals
January 2021 marked the beginning of a new year and the official implementation of 3DS 2 guidelines for online transactions in Europe (the UK is due on 17 September 2021).
3DS 2 sparks concerns in merchants and providers alike. As with many new regulations/changes, the gaps between what’s desired and what exists are profound, and require time to adjust and align with all of the players involved in making this operation work. Let’s shed some light on what’s changed and what is required of you to comply.
The Then vs. The Now (3DS 1 vs. 3DS2)
While in the past 3DS was performed with the use of a OTP, The need to change 3DS grew in importance to reduce false declines and to improve the user experience while performing online payments.
What the EMVco* realized was that online fraud continues to expand, and thus requires better validation to ensure the security of transactions and customer identification. 3DS 1 also caused a drop in conversion rates, since cardholders had to undergo an unfriendly flow.
That’s when 3DS 2 was born. Designed around the principles of Strong Customer Authentication (SCA), the significant difference between 3DS 1 and 3DS 2 is that customer authentication should now be performed with at least two of the following identification methods: “something the user knows” (e.g., password), “something the user is” (e.g., fingerprint), “something the user owns” (e.g., mobile device).
The 3DS 2 flow corresponds with the data received from the actions the user performs in the device (such as fingerprint authentication, device ID, IP address, and more), and responds accordingly to finalize the user’s authentication.
As regulations came into effect in 01.01.2021, SCA is now mandatory for all online transactions in Europe— Card Issuers (Banks) in Europe are now obligated to use the above two-factor-authentication for all card payments. While there are some exemptions to the above (which we’ll break down shortly), merchants are still advised not to rely on exemption-flows and calculate the most secure scenarios to ensure high approval rates.
While it may seem an obstacle at first, 3DS 2 has many benefits to both merchants and customers. Firstly, it allows payment providers to send more data to the cardholder’s issuing bank, e.g., device and order history. The bank can then use this data to recognize the customer for future purchases and prevent recurring requests for the user’s authentication. This has the potential to optimize the flow for buyers and create frictionless authentication for future purchases. 3DS 2 also gives buyers more flexible ways to authenticate their identities, e.g. via a thumbprint, app-based authentication, or a one-time password. Transactions that were authenticated will have a higher approval rate in the authorization step.
How does the new flow look like?
The flow begins when a buyer wishes to purchase an item/service. After inserting their card information, the merchant receives their request and enrolls them via the relevant 3DS flow.
Once the issuer receives a payment request, they review the contextual data in which it was made– the type of merchandise being purchased, the buyer’s shipping location, device type, etc.
At this point, the issuer may deem the information sufficient to approve the transaction. Otherwise, they may request the buyer to prove their identity with additional information.
While most transactions are frictionless – and occur without the buyer’s awareness – the issuer may occasionally request to perform a simple challenge to prove their identity. The issuer decides which challenge should be completed — a face recognition, a fingerprint, a one-time verification code, or else.
After the buyer provides the additional information, the issuer then reviews it and decides whether to approve/decline the transaction. The flow is now complete. Thanks to the additional information received, the issuer can rest assured of the buyer’s identity and accommodate their request.
The significant bits you need to know
3DS 2 is not free from potential downsides, primarily because it’s still in its formation state. Some gaps still exist between what’s desired and what exists in the field. For instance, banks are required to perform 2-step authentication flows, which means that a one-time passcode is insufficient and requires an additional step, e.g., confirmation via a bank application, fingerprint, face ID, etc. This turns out to be tricky, as even the most advanced banks—who have implemented the two-stage-verification— can still lose a hefty percentage of transactions due to 3DS.
Effect on customer experience
The new requirements may be foreign to many customers at first and can impact conversion rates and increase abandoned carts at checkout. Failure to complete payment flows can be either due to an unfamiliar authentication process or as a result of technical difficulties or broken flows at the backend. Our data analysis team recently discovered that many banks did not manage to implement all requirements such as responsive web design, two-factor authentication, and other technological conditions that significantly affect customer experience. Conversion rates due to these gaps have plummeted to 30%-40%.
Possible flows and exemptions
Exempting users from an SCA flow is useful since it increases the chance that the transaction will be frictionless (i.e., without an additional authentication step) and decreases the chances of user drop-outs. Suppose you are a merchant whose business model includes card-on-file like functionality or are processing one-click payments or recurring payments. In that case, you can enroll these payments via flows that are eligible for exemptions from 3DS. Bear in mind that the decision of whether to grant the exemption lies within the card issuer. Once they are exempted, the chargeback liability shifts back to you (as the merchant). Possible exemptions include:
- A Transaction Risk Analysis (TRA) – This scenario can be implemented when a transaction is considered low risk. In that case, ZOOZ sends the authorization request to the issuer flagged as low risk (TRA flag). Be aware that the issuer may deny this claim and require strong authentication utilizing a Soft Decline response code.
- Recurring Transactions and Merchant Initiated Transactions – Only the subscription or recurring cycle’s initial transaction or recurring cycle will require SCA. Subsequent charges will be exempted. A transaction is deemed “recurring” if it is for a fixed amount. In case the amount changes over time (such as when some utility bills are based on usage, like electricity, telecom services, car-sharing, etc.), such transactions will be called MIT (merchant initiated transaction) and will also be exempted. In both cases, the merchant must obtain the cardholder’s consent for charging the card.
- Soft decline – The card issuer always decides whether or not to honor the exemption. If strong customer authentication is deemed necessary by the issuer, the authorization will be declined using a specific reason code – Soft Decline.
- Trusted beneficiaries – this exemption enables cardholders to add businesses they trust to a list of trusted beneficiaries to be held by the issuing bank. Once trusting a merchant, which is also termed as Merchant White Listing (MWL), cardholders can complete their electronic payments without the step-up authentication when shopping at that merchant in the future. Whitelisting merchants increase frictionless user experience and hence reduces cardholders’ shopping cart abandonment. You should be aware though, that merchants cannot white list themselves, and cardholders can remove merchants from their white list at any time. As required within GDPRregulations, the consent of a cardholder is needed to whitelist a merchant.
What we do to help with your compliance
The implementation of 3DS 2 and streamlining of procedures will take some time and further adjustments of all parties involved (issuers, banks, customers, and gateways alike). To equip you with the necessary tools and peace of mind, ZOOZ has set up to do the following:
- As an orchestration platform, ZOOZ helps you monitor and spot decreases in acceptance rates due to 3DS. Thanks to the solution’s intuitive nature, you can easily change the configuration if you spot a drop according to your chosen parameters. Prevalent cases might be linked to a Bank’s choice of two-factor combination. Each bank decides independently of their product and compliance strategy in regards to SCA requirements.
- Based on online transaction monitoring, we can optimize the conversion by routing 3DS authentication type for the better performing one (3DS 1 and 3DS 2) and communicate with Card Schemes and Issuing Banks to fix issues, improve process UX, and increase conversion rates.
- Soft Decline – ZOOZ has two ways to manage Soft Decline: On behalf of the merchant, ZOOZ steps in and automatically initiates the authentication process using 3DS. The merchant is also able to handle Soft Declines via the PaymentsOS API. The decline reason code must be checked for each canceled order by retrieving the transaction details.
What lies ahead for 3DS 2
While records reveal that 22% of payments are lost when authenticated using 3D Secure, the reasons for this are rooted deep within the gaps in field-readiness. One of our customers has recently said that while “3DS 2 is the most discussed topic in the payment industry nowadays, yet we still witness many market gaps. While we view the implementation of 3DS 2 as a positive step and recognize its importance, real-time readiness is still lacking. So it’s up to us at this point to conduct thorough, ongoing checkups to ensure that transactions are processed smoothly”.
ZOOZ, as a payment orchestration platform, makes sure to support 3DS and related flows to give our customers the flexibility to change and supervise our customers’ payment flows to ensure that even in times of uncertainty, their payment processes are secure and optimized to the max.
Please check our Documentation for more information and drill down scenarios, implementation, and requirements to ensure your utmost compliance.
* EMVCo is collectively owned by American Express, Discover, JCB, MasterCard, UnionPay and Visa, and was formed in 1999 to enable the development and management of specifications to address the challenge of creating global interoperability and to deliver the adoption of secure technology to combat card fraud, while enabling innovation in the payments industry. More about EMVCo, here.