3-D Secure 2.0 Explained

Considering the rapid evolution of consumer behavior and the surge in payments made through digital channels like tablets, mobile phones and the Internet of Things in recent years, along with the increased fraud rates observed, the European Payment Service Directive (PSD) has introduced an updated version of the directive, known as PSD2.  

The new directive requires banks to open their customer data assets to third parties and also includes new safety requirements. It also led to the development of an enhanced security protocol known as 3-D Secure 2.0. PSD2 also introduces new transaction security measures such as Strong Customer Authentication (SCA), Risk Based Authentication (RBA) and Transaction Risk Analysis (TRA). Our research found that 73% of consumers say that multi-factor authentication makes their payment feel safer and more secure.

Find out more about Checkout.com's authentication solution.

3DS 1.0 vs. 3DS 2.0

Most shoppers have experienced, at least once, the limitations of the 3DS 1.0 protocol through non-browser e-commerce transactions; paying on mobile devices or in-app can sometimes be a frustrating experience and not quite user-friendly.

Understandably, businesses may initially be concerned that more authentication elements will inevitably mean more friction points, thus affecting the overall customer experience which will have a negative impact on conversion rates – but in fact, it will likely have the opposite effect. 

While drafting the PSD2, regulators kept these as central considerations and included a number of provisions that will allow merchants to maintain, and even improve, speed and user-friendliness.

With increased usage and popularity of these types of transactions, the new version of 3DS specifications is designed to deliver better integration with the merchant  – widening the limitations of 3DS 1.0, curbing cart abandonment rates and improving the user experience, all without compromising security. Let’s break down some of the key changes in 3DS 2.0 and what they'll mean for your business. 

What is Strong Customer Authentication (SCA)?

The new PSD2 introduces Strong Customer Authentication (SCA) which is an upgraded security measure that will be used to authenticate online payments which will require a combination of a minimum of two of the following authentication elements:

• Something the consumer knows:  One-time password, SMS code, PIN, password, personal information or security question.
• Something the consumer owns: Credit or debit card, key fob, mobile device, token, or wearable device.
• Something the consumer is: Biometric data like a fingerprint, iris scan, or facial or voice recognition.

However, in some instances, merchants may be exempt from the requirement to implement SCA. 

Here are some SCA exemptions:

1. Low-value transactions

Transactions valued at less than €30.00 will be exempt unless one of the following limits related to a low-value transaction is reached:  

• The total value spent on the card without SCA exceeds €100.00 within a 24-hour period
• The transaction count exceeds 5 within a 24-hour period.

In either case, SCA may be triggered by the issuer.

2. Low-risk transactions

Low-risk transactions may also be exempt from SCA. Low-risk transactions will be determined by assessing the average fraud levels of the card issuer and the acquirer that is processing the transaction. Depending on the degree of their risk and fraud levels, the transaction could be exempt from SCA, even when one of the low-value limits listed is reached:

• The fraud level is below 0.13% and the transaction value is less than €100.00
• The fraud level is below 0.06% and the transaction value is less than €250.00
• The fraud level is below 0.01% and the transaction value is less than €500.00

Some transactions under PSD2 are exempt from the SCA requirement and some others are simply out-of-scope.

3. Recurring plans and subscriptions

When a cardholder sets a recurring payment with a merchant, only the first transaction will have to be authenticated under SCA. SCA is not required for recurring transactions or returning customers unless the transaction amount changes, the returning customer interactions have hit the issuer count threshold, or if the transaction is considered a Merchant Initiated Transaction, meaning that the cost is usage-dependent such as a minibar bill or a parking fee.

What is Risk-Based Authentication (RBA)?

An important advantage of 3DS 2.0 is that it facilitates a richer exchange of data between the cardholder’s device and the issuer – essentially, enabling the issuer to perform Risk-Based Authentication (RBA). 3DS 2.0 will allow for an exchange of over 100 data elements on each transaction, factoring data points like a shipping address, device ID, and previous transaction history, in order to assess the risk level of each transaction. Depending on the issuer’s decision, the authentication will then either go through a frictionless flow, when the transaction is perceived as secure or through a challenge flow, where the user may be prompted to provide further verification.

According to Mastercard, through this data validation measure, it is expected that 90% of all transactions will not require a challenge to authenticate the user thus reducing overall friction and cart abandonment rates. Even better, users will not need to provide a password or SMS in order for the merchants to benefit from the liability shift.

With 3DS 1.0, there is a security protocol in which a bank page appears and confirms that there is no need to authenticate for this transaction – this can be an unnecessary friction point. However, with 3DS 2.0, the redirect or bank page will no longer be displayed to the user which will create a smoother, faster flow toward checkout completion. 

What is the user experience when there is a challenge?

The new protocol encourages frictionless authentication where possible and delivers a better use of dynamic one-time passcodes when it is required.

For example, the new 3D secure 2.0 protocol allows merchants to embed the authentication process in their checkout flow, rather than displaying the bank page, resolving the clunky user experience that 3DS 1.0 sometimes delivers.

With a growing number of cardholders now using their bank’s mobile apps, the authentication process through the challenge flow will detect the presence of the banking app and open it, optimizing the authentication flow.

What is Transaction Risk Analysis (TRA)?

Last but not least, the new protocol introduces Transaction Risk Analysis (TRA) which is the proprietary risk fraud analysis that issuers and acquirers will apply on each transaction. It is based on an algorithm built to detect the cardholder’s spending or behavioral patterns. Other risk factors analyzed include cardholder location, merchant location, monetary threshold, and real-time fraud rates for e-commerce transactions.

How is Checkout.com getting ready for 3DS 2.0 and PSD2 SCA mandate? 

Checkout.com’s proprietary 3DS 2.0 solution was recently certified by EMVCo in January 2019. EMVCo consists six member organizations which include American Express, Discover, JCB, Mastercard, UnionPay, and Visa, and is supported by other industry stakeholders, issuers, acquirers, processors, vendors, and merchants. EMVCo manages and evolves the EMV® Specifications and related testing processes.

We have undergone the implementation of new risk engine rules while obtaining relevant Card Schemes certifications under PSD2.

Checkout.com will apply a phased approach intended to minimize the impact on the majority of merchants who are currently using Checkout.com’s 3DS 1 solution. This will also give merchants time to prepare for an integration method that best suits their needs. The approach will coincide with the EMVCo rollout of the next 3DS 2.0 protocol version and the newly supported workflows and features such as ‘merchant-initiated payment authentication requests’ and ‘merchant-applicable SCA exemption flags’ in the authentication requests.

Phase I will have no impact on merchants who are already using 3DS 1. Phase II will introduce merchants to a wider selection of integration options and use of exemption flags in the authentication. Subsequent phases will offer more features and value-added services as they become available.

Phase I: April 2019

Checkout.com launches our 3DS 2.0 solution, a fully integrated browser solution that uses the existing Checkout.com 3DS 1 integration. Checkout.com will gather all required information on behalf of the merchant and there is no need to change your current 3DS 1 integration.

3DS 2.0 does not currently support ‘merchant-initiated payment authentication requests’ nor the ‘merchant-applicable exemption flags’ in the authentication workflow. Therefore, Phase I will support the merchant-applicable exemption flags in the authorization workflow. This may result in ‘soft-decline’ authorization responses where the issuer will request a 3DS authentication prior to authorizing the transaction.

Merchant-initiated transactions such as recurring transactions (except the initial transaction and given that the recurring amount does not change) are PSD2 exempt and can be submitted directly during authorization. Our systems are prepared to properly flag these authorization requests as ‘merchant-initiated recurring transactions’ and as ‘PSD2 exempt’ to ensure the highest conversion rates.

Phase II: October 2019 (or earlier if supported by the Card Scheme networks)

Checkout.com launches the next version of our 3DS 2.0 solution, a fully-integrated browser,  SDK solution, and 3DS 2.0 API for merchants who already have the ability to gather and submit all required information. This solution also applies to merchants who have the ability to manage the PSD2 SCA logic either on their own or via an intermediate provider. 

In Phase II, merchants will be able to submit additional optional fields to help with issuer RBA decisioning; this will require integration changes. Merchants will also be able to submit authentication and authorization in two steps, submit authentications through Checkout.com, and submit authorizations through a third-party, and vice-versa.

Moving the industry to the next 3DS 2.0 version is dependent on the EMVCo certification lab and Card Scheme networks’ readiness. The current expectation is that the industry will not be ready to support the next 3DS 2.0 version by the PSD2 mandate on September 14, 2019. We will provide further updates on the next 3DS 2.0 version as they become available. 

When should you begin transitioning?

Merchant readiness and Card Scheme 3DS 2.0 onboarding activities are already underway. For existing customers, Checkout.com will ensure a seamless transition. Merchants based in Europe will automatically be enrolled in the new protocol in time for the PSD2 mandate.

Checkout.com will switch traffic onto 3DS 2.0 gradually, starting with European-based merchants whose issuers support the new protocol. If the new version is not yet supported by the issuer, the request will automatically default to 3DS 1. Checkout.com will switch on full 3DS 2.0 support in each region in conjunction with the Card Scheme networks’ rollout schedule.

Current Card Scheme networks rollout plan:

• April 2019 in Europe
• October 2019 in the U.S., Canada, and Latin America countries
• April 2020 in Asia Pacific, Central and Eastern Europe and Middle East countries 

How should I start preparing?

• All EEA merchants will need to ensure that they can support 3DS 2.0 by September 14, 2019. This includes merchants who have not previously used 3DS 1.
• All merchants should plan to adopt or migrate to the next 3DS 2.0 version between April and September 2019 to ensure you fully benefit from SCA exemptions, including the support of additional optional fields.
• Merchants who take advantage of the SCA exemption without an authentication request, and the issuer responds with a ‘soft-decline,’ should be prepared to automatically send a 3DS 2.0 authentication with a challenge request and if successful, follow with another authorization. Similarly, if an issuer does not yet support 3DS 2.0 authentications then a merchant should use 3DS 1 as the default.
• Merchants should ensure that they can provide all required data elements and, later on, optional fields as per the phased schedule in order to fully benefit from RBA-frictionless flow.
• Merchants who take a more complex approach to risk management and the check out user experience should work with their Checkout.com Customer Success Managers to develop exemption strategies that best suits their business needs.
• Merchants that have regular returning customers, and who are able to demonstrate a low fraud rate, should make use of the trusted beneficiaries exemption available in Phase II.
• Merchants should make changes to their websites to support  3DS 2.0 and update with Card Schemes’ new 3DS 2.0 program logos.

How can I optimize the payment experience under PSD2?

Not all transactions require SCA under PSD2. Some transactions are out-of-scope or are exempt. In these cases, SCA is determined based on the merchant and/or Checkout.com’s transaction risk assessment.

Checkout.com will offer 3DS decisioning based on a combination of factors including whether a transaction is out-of-scope or qualifies for an exemption, risk assessment, optimization of user experience, and liability protection.

Merchants are encouraged to use exemptions as much as possible to ensure a frictionless user experience while also keeping fraud rates low and meeting the PSD2 mandate. We have updated our systems to ensure that correct transaction types and exemption scenarios are flagged to help issuers recognize when SCA is not required and authorize accordingly. 

What is the difference between authentication and authorization, and what are the implications of requesting an exemption in either of the two workflows?

• Authentication ensures that the cardholder is the legitimate owner of the card. Where required, authentication must take place before the authorization under 3DS.
• Authorization is a separate process whereby the issuer may approve or decline a payment transaction submitted by a merchant.
• Exemptions are scenarios that EU regulators have agreed to exclude from the SCA mandate.

Either workflow can be used to indicate the nature of the transaction – whether it is out-of-scope, requires SCA, or is being processed under one of the exemptions. Transactions that are out-of-scope are most likely to be sent directly to authorization without authentication being requested.

A merchant can exercise an exemption via the authentication workflow before sending an authorization request. The advantage of this approach is that if the exemption is rejected by the issuer, the cardholder is still present to complete any required fields, even if this delays authorization.

Where PSD2 applies, we recommend sending transactions for authentication first and apply for as many exemptions as possible. This will ensure higher conversion rates and more successful authentication requests in the future.

A merchant can also submit an authorization and request an exemption directly. The advantage of this approach is that the authentication workflow can be skipped altogether if the issuer accepts the exemption. However, if the issuer declines the exemption and requests authentication, the payment completion may be delayed or the cardholder may no longer be present to perform the authentication.

Checkout.com will apply the exemption flags in the authorization workflow and merchants should be aware that the issuer has the right to request resubmission via 3DS if they determine that authentication is required. 

If no exemption flags are used in either workflow, the decision will be determined by the issuer. 

So what is considered in-scope or out-of-scope?

In-scope:

• One-time cardholder-initiated transactions (CITs) are considered in-scope under SCA. However, some exemptions do exist such as ‘low-value amount’ (under 30 Euro) transactions.
• Adding a credential-on-file (COF), or provisioning of a token are in-scope under SCA, unless the merchant obtains the updated information via the Scheme Account Updater or token services.

Out-of-scope: 

• Merchant-initiated transactions (MITs) are out-of-scope under SCA since they are based on prior cardholder agreements. SCA is required for the initial transaction when the cardholder agrees to the terms under which future MITs are processed. 
• Mail order telephone order (MOTO) transactions are out-of-scope under SCA, but future versions of 3DS 2.0 will optionally support these to help better manage the merchant risk.
• If the issuer or the merchant is located outside the EEA, those transactions are considered out-of-scope under SCA. SCA should be applied to these transactions on a ‘best effort’ basis.
• Transactions made with anonymous prepaid cards are not subject to the SCA mandate.
• If you check the validity of card numbers and expiry dates using an authorization account verification, then the transaction is not subject to the SCA mandate.

To use the trusted beneficiary service, a merchant will need to send an enrollment request to the issuer to be added to a cardholder’s trusted beneficiaries list. SCA is required for enrollment.

What else should I be aware of? 

• The issuer has the final decision on whether to accept or apply an exemption; they can apply SCA or decline the transaction.
• For low-value-accumulated-amount transactions, while the regulation allows the merchant and acquirer to apply for an exemption, this is not practical since the merchant nor the acquirer have visibility of the velocity limits that apply to the exemption.
• Recurring transactions should be treated as out-of-scope MITs instead of applying for a recurring transactions exemption.
• The Card Schemes will require minimum performance levels for authorization approvals, fraud, and abandonment rates to be met by issuers. European issuers will also be required to offer their cardholders biometric authentication solutions via smartphones, which have the lowest abandonment and fraud rates, therefore resulting in the highest sales conversion rates.

PSD2 requires that SCA be applied for all electronic payments when an issuer and a merchant are both within the European Economic Area (EEA) by September 14th, 2019, unless specific exemptions apply. Checkout.com has rolled out its 3DS2 hosted solution to enable merchants to comply with the new SCA requirements, optimize the cardholder experience, boost conversion and avoid declined payments for non-compliance.

3D Secure 2.0: Checkout.com Hosted Solution

When designing our 3DS 2.0 solution, we wanted to remove complexities for merchants and their customers and provide an easy upgrade path from 3DS 1.0 to 3DS 2.0. We made sure to maintain the same integration experience for both versions of 3D Secure through the use of a middleware called the Interceptor. By doing so, if you had already built support for 3DS 1.0 in the Unified Payments API, there was no additional work required when we released our 3DS 2.0 solution.

Checkout.com’s 3DS 2.0 hosted solution will ensure you comply with PSD2 and will support different SCA factors, improve cardholder user experience, limit fraud through data sharing and transaction risk analysis, and enables the use of exemptions. 

With 3DS 2.0, merchants can pass on ten times more data than with 3DS 1.0. While 3DS 1.0 may support SCA, it is not fully adapted to PSD2.

For example, 3DS 1.0 does not:

• Include the possibility of using exemptions
• Use all forms of SCA approaches

In addition to rolling out our 3DS 2.0 solution, we are also enhancing our internal risk procedures to assess and score each transaction in real-time. The score will then be used in the application of Transaction Risk Analysis (TRA) exemptions.

The Exemption Optimization Service is another real-time service that will be included to ensure that a transaction is authenticated if a transaction falls under PSD2, and where applicable, is authenticated using an exemption strategy.

We haven’t stopped there. Checkout.com is already working on the next phase of 3DS 2.0 enhancements called 3DS 2.1. 

Read more: Best practices for secure online payment processing

How SCA will impact your checkout flow.

Unified Payments API: Checkout.com's Integrated Solution

When requesting a payment through the Unified Payments API, we will attempt to automatically detect if it falls under the SCA mandated area. If it does, we’ll provide you with a redirection URL that your customer should be sent to. This then brings them to the Interceptor, a piece of middleware that is responsible for identifying if any exemptions can be applied, collects all the necessary information about the cardholder (device information, for example) and trigger the authentication request to the issuer if necessary.

If the frictionless flow is triggered, we immediately request the authorization and send the cardholder straight back to your online store without any further action needed from them. If there is a challenge requested, the Interceptor handles all of the back and forth between the cardholder and issuer on your behalf before again requesting the authorization and sending your cardholder to your online store.

We also have a fallback mechanism. If it isn’t possible to perform a 3D Secure 2.0 authentication, we’ll send the cardholder down the 3D Secure 1.0 route to ensure that authentication takes place regardless. Again, all of this complexity is handled internally by Checkout.com whilst providing a seamless payment experience for your customers.

To meet ever-changing consumer and regulatory demands, businesses require a payment service provider that constantly iterates, adapts and improves upon their solutions.  Our Unified Payments API is designed to future-proof your payments, so you spend less time with integrations and more time focusing on your business. 

While the EBA reiterated that all actors, including card schemes, issuers, and merchants, must take the necessary steps to apply or request SCA, the EBA has exceptionally accepted that national competent authorities across Europe may decide to work with PSPs and relevant stakeholders, including consumers and merchants, to provide additional time for SCA compliance.

The local competent authorities may decide to provide limited additional time with an aim to:

• Allow issuers to migrate to SCA compliant authentication approaches 
• Allow acquirers to migrate their merchants to solutions that support SCA

In order to achieve consistency across the EU, the EBA will communicate deadlines by which the businesses will have to complete their migration plans later this year.

Due to market pushback and lack of industry readiness, the EBA recognized the challenges for meeting the September deadline and may grant extensions on an “exceptional basis.” However, Checkout.com highly recommends completing your SCA compliance requirements as soon as possible in order to reduce your risk of declined payments.