3DS Guide: are you compliant with the latest standards?

3DS 2 sparks concerns in merchants and providers alike. The desire to fortify payment-processes without adding more friction is challenging, and gaps still exist between what’s considered optimal and the reality.

In the past, 3DS authentication was performed with an OTP (One Time Passcode). The updated 3DS process aims to reduce false declines and improve user experience all around — creating a faster and more secure checkout experience.  

 

What the EMVco* realized was that online fraud is expanding and companies need to validate the security of transactions and customer identification. The earlier version of 3DS also caused a drop in conversion rates due to unfriendly checkout flows.  

New best practices for 3DS2 

Designed around the principles of Strong Customer Authentication (SCA), the significant difference between 3DS 1 and 3DS 2 is that user authentication now uses 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).   

 

3DS 2 flow corresponds with the data accumulated from 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.  

 

Strong Customer Authentication (SCA) has become mandatory for all online transactions in Europe. Card Issuers (Banks) need to implement the aforementioned two-factor authentication for all card payments. While some exemptions apply, merchants are advised not to rely on exemption-flows and adhere to the most secure flows to ensure the highest approval rates.   

 

How 3DS benefits merchants

In spite of the challenges, 3DS 2 has many benefits to both merchants and customers. It allows payment providers to send more data to the cardholder’s issuing bank, e.g., device and order history. The bank can use this data for future recognition and prevent recurring requests for the user’s identity authentication, making frictionless authentication a common practice. 3DS 2 also gives buyers more options to authenticate their identities, e.g., via a thumbprint, app-based authentication, or a one-time password. Authenticated transactions end up having a better approval rate in the authorization step.  

How the 3DS flow works

When buyers insert 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– i.e., the type of merchandise within the purchase, 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 that would be — face recognition, fingerprint, a one-time verification code, etc.   

 

After the buyer provides the requested information in the validation step, the issuer then reviews it and decides whether to approve/decline the transaction. The flow is now complete.  

3DS2 Guide Infographic
Download the infographic

What you need to remember

3DS 2 is not free from potential downsides, primarily because it’s still in its formation state. Banks, for instance, 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. The added step 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.  

 

Customer experience challenges

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 due to technical difficulties or broken flows at the backend. Our data analysis team recently discovered that many banks did not implement all requirements such as responsive web design, two-factor authentication, and other technological conditions that significantly affected customer experience. Conversion rates due to these gaps have plummeted to 30%-40%.   

 

Possible flows and exemptions

Exempting users from SCA flow increases the probability of frictionless transactions (i.e., without an additional authentication step) and decreases the chances of user dropouts. Suppose you are a merchant whose business model includes a card-on-file functionality, one-click payments, or recurring payments. In these cases, you can enroll associated transactions via flows that are eligible for exemptions from 3DS. Bear in mind that the decision of whether to grant the exemption lies with the card issuer. Once transactions are exempted, the chargeback liability shifts back to you (as the merchant).  

 

Possible exemptions include:  

  • A Transaction Risk Analysis (TRA) – In this case, the authorization request to the issuer is flagged as ‘low risk’ (TRA flag). Be aware that the issuer may deny this claim and require strong authentication while utilizing a Soft Decline response code.   

 

  • Recurring Transactions and Merchant Initiated Transactions – Only subscription or recurring cycles will require SCA. Subsequent charges will be exempted. A transaction is considered “recurring” if it is for a fixed amount. Suppose the amount changes over time (such as when utility bills are based on usage, like electricity, telecom services, car-sharing, etc.). In that case, 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 with the reason code – Soft Decline.  

 

  • Trusted beneficiaries – this exemption enables cardholders to add businesses they trust to a list of authorized beneficiaries to be held by the issuing bank. Once a Merchant White Listing (MWL) is obtained, cardholders can complete their electronic payments without the step-up authentication when shopping at that merchant’s store in the future. White-listing merchants increase frictionless user experience and hence reduces cardholders’ shopping cart abandonment. However, you should be aware that merchants cannot white-list themselves, and cardholders can remove merchants from their white list at any time. As required within GDPR regulations, the consent of a cardholder is needed to white-list a merchant.  

What we do to help with your 3DS compliance

Implementing 3DS 2 and streamlining 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, PayU has set up to do the following:   

 

  • Via its orchestration platform, PayU 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 its 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 – we have two ways to manage Soft Decline: On behalf of the merchant, we can step in and automatically initiate the authentication process using 3DS. The merchant can also handle Soft Declines via the PaymentsOS API. The decline reason code must be checked for each canceled order by retrieving the transaction details.   

 

   

What about non-European Merchants?

While records reveal that 22% of online payments are lost via 3D Secure, the reasons for that lie mainly because of field ‘readiness’, or lack thereof. While it is still mandatory only in European countries, other markets are also warming up to the idea of implementing 3DS 2, to increase the security of their payments and frictionless customer experience.  

  

3DS 2 is useful for more than just payments. Adding cards to digital wallets, open banking services, and financial services apps, etc. are to name a few of its other uses. These might contribute to the spread of 3DS 2 beyond Europe— to LATAM, the USA, Asia, and more.   

 

 

Please make sure to check our  Documentation  for more information regarding the different scenarios, implementation processes, and requirements needed 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 developing global interoperability and facilitating the adoption of secure technology to combat card fraud, while allowing innovation in the payments industry. More about EMVCo,  here.   

1