We introduced readers to the Payment Services Directive 2 (PSD2) and Strong Customer Authentication (SCA), 3D Secure 1 (3DS1) and 3D Secure 2 (3DS2) in a previous blog post – What is PSD2 and What Does Strong Customer Authentication (SCA) Mean for You? My colleague Stefan covered what the revised directive means for business in Europe, how it will impact online shoppers and merchants at a high level, and how merchants should prepare for SCA compliance. In this article, I’m going to dive a bit deeper into the impact of the revised directive, specifically for 2Checkout merchants selling into Europe and their European clients.
What Was the Original 3D Secure Purchase Flow?
As a quick reminder, in 3DS1, once a customer enters the card details to make a payment, they are redirected to a 3D Secure page provided by their issuing bank (this is NOT controlled in any way by the merchant or 2Checkout). The authentication usually implies that the customer enters a static password or a code she receives via SMS on her mobile device.
The main problem with this process has been the redirect itself, and the fact that the page and the whole process were not optimized for today’s smartphones. According to previous tests we’ve run, 3D Secure 1 had a drop-off rate of 5 to 15% at the checkout, especially in countries where authentication wasn’t widely adopted by issuing banks.
Differences in User Experience between 3D Secure 1 and 3D Secure 2
As hinted above, 3DS1 has a clunky user interface and, on top of that, it looks suspicious and can make customers feel less secure, leading them to abandon the checkout. The good news is that 3DS1 will slowly become history and 3DS2 will be the new kid on the block in the EU.
3D Secure 2 – The Frictionless Flow
The additional good news is that 3DS2 comes along with frictionless authentication. What does that mean? Well, more data will be sent to the cardholder’s bank, who can then use this information to complete the authentication in a “frictionless” manner, without additional shopper input. This is probably the biggest difference between 3DS1 and 3DS2.
When we say “more data,” we mean 100+ data points sent to the cardholder’s bank to assess the transaction risk. If the customer’s bank believes it to be a safe transaction, the customer goes through the frictionless flow in which she has nothing left to do and the payment is sent for authorization and capture of funds. If you are using the 2Checkout hosted or inline ordering engines, we’ve got you covered and there’s nothing you need to do. If you are using our APIs, we recommend collecting more customer data to facilitate the frictionless flow.
3D Secure 2 – The Challenge Flow
If the frictionless flow is not possible because there is not enough information, or the information available triggers the need for authentication, the order goes through what is called the “challenge flow.” Another major improvement in user experience with 3SD2 is related to this flow. More precisely, 3DS2 is designed to embed the challenge flow directly within web and mobile checkout flows, without requiring full page redirects. If a customer authenticates on your site or webpage, the 3DS2 prompt appears by default in a modal on the checkout page (browser flow).
Strong Customer Authentication (SCA) requires banks and card issuers to authenticate their customers by using at least two independent elements between what a customer knows (such as a password or a pin), what she owns (a smartphone or token), or what she is (fingerprint, facial features). Any combination of the two will ensure the SCA requirements are met; failure to authenticate results in a declined transaction. The benefit is that 3DS2 offers more flexible ways to authenticate, in line with SCA requirements. Banks can now offer innovative authentication experiences through their mobile banking apps (sometimes referred to as “out-of-band authentication”). Instead of entering a password or just receiving a text message, the cardholder will now be able to authenticate a payment through their banking app by just using their fingerprint or even facial recognition. We expect many banks to support these smoother authentication experiences with 3DS2.
So, to conclude, the authentication process provides a better user experience, is mobile ready, embeddable, and more user-friendly, with static passwords replaced by tokens and biometrics. The improved user experience of 3DS2 is important, as this new regulation will most likely require authentication on European payments more often than before, which means the UX improvement can help reduce the negative impact on conversion. In order to prevent this, an integrated and up-to-date payments engine is key to maximize conversions. This is what 2Checkout also offers. Keep reading to see how.
3D Secure 2 – The Exemptions
SCA has some options to improve conversion by leveraging what are called “exemptions.” The first one refers to low-value transactions, i.e. less than 30 euro for one-off transactions. Another exemption refers to low-risk transactions, which are determined by a real-time risk analysis performed by the 2Checkout system and transmitted to the issuing bank, which will allow the exemption.
Although in general an issuing bank will allow, for example, a low-value transaction to go through a frictionless flow, it can happen that based on the pre-shared risk parameters from the merchant, the bank’s transaction analysis system may decide SCA is still required. This cannot be controlled by the merchant or the payments provider. To prevent SCA in such cases, it’s important to share as much data around shopper account information, the customer herself, and the environment she is utilizing. There are approximately 145 possible parameters to share with the banks, out of which a handful are mandatory.
Another very important exemption refers to recurring transactions, as long as the charge is made for the same amount, for the same payee, and the same recurring cycle. In our subscription-based business, we see a lot of recurring transactions where the individual transactions share similar characteristics. However, they are related to a higher-level mandated Customer Initiated Transaction, called a CIT. By setting up a proper SCA-based mandate with the associated issuer, an issuer ID is supplied for the follow-up transactions. These transactions are considered Merchant initiated Transactions, or MIT. The MIT transactions are out of scope for SCA.
Other more exotic exemptions are whitelisting and secure corporate payments. Whitelisting is where the customer grants the merchant/ payment provider access to her account to debit it. To our knowledge, a very limited set of issuing banks have made this capability available. Also out of scope of SCA are items like prepaid cards, mail/ telephone order (MOTO) transactions and one-leg out transactions (i.e. where one of the players – either of the payer or the payee – is based outside of the EU). To manage these, we are utilizing an up-to-date Bank Identification Number (BIN) database to identify issuers based outside of the European Economic Area (EEA) or transactions that use anonymous cards.
Exemptions are key for better conversions but are challenging to manage. It is our task as a payment provider to build an ordering engine that adapts and optimizes the use of these exemptions.
Transition Period – 3D Secure 1 Fallback
Until all issuing banks are up to speed with 3SD2 (and no, not all will be ready by the September 14 deadline), for each European online transaction, behind-the-scenes payment providers like 2Checkout will have an automated check in place to see if the issuing bank supports 3DS2 or not. If they do, we’ll go through the new 3DS2 process flow. If the issuing bank of the card holder is not yet ready with 3DS2, they will still be obliged to have 3DS1 in place in order to comply with SCA mandates. In such cases, your end-customer will be presented with the legacy 3DS1 experience through a redirect. This will actually be tough on payment providers that didn’t support 3DS1 flow before (since it wasn’t that widely adopted by the banks), as they will have to develop support for both models to avoid taking the hit from authorization declines from banks that won’t be ready with 3DS2. Luckily for 2Checkout, this is not an issue since we already had 3DS1 support in all our ordering engines and APIs.
3D Secure 2 Flow Examples
Now that the basics are covered, here’s how it will look when a customer decides to buy your products, services, or plans with 2Checkout’s support in place.
When a customer initiates an online transaction and submits her payment information (Step 1 of the purchase flow), 2Checkout will check with her issuing bank (Step 2, behind the scene), who will flag transactions that can proceed with the frictionless flow. As a result, in the next step (Step 3), the customer will see the Payment Confirmation or the Thank You page, once the payment is authorized.
Example of a «frictionless flow» when exemptions are applied.
If, however, the issuing bank decides that the information provided doesn’t qualify for an exemption, they will send 2Checkout the request to initiate the challenge flow and ensure that authentication takes place. From the end-customer’s perspective, this will mean that a modal window or pop-up will open with the message from her issuing bank, prompting her to authenticate through her mobile banking application (Step 2 in the image below).
When exemptions are NOT applied, the transaction goes through the «challenge flow». Steps 1 & 2.
The next steps of the purchase (Step 3 and 4) happen within the mobile banking application. The design and flow on the actual banking app is something that each bank designs and controls – what is being depicted below is a sample mockup from a bank that implemented a biometric authentication (through fingerprint). Once the authentication is completed, the transaction can be authorized, the “approve this payment through your banking app” pop-up disappears, and the customer is presented with the payment confirmation page (Step 5).
When exemptions are NOT applied, the transaction goes through the «challenge flow». Steps 3-5.
Now, authentication will not always go smoothly. The customer might not have her mobile device close by, or there might be an issue with the bank application or the mobile internet connection. In such situations, it’s best to have an alternative solution in place and offer your end-customers the chance to finalize the purchase by using either a different credit or debit card or by choosing an alternative payment method such as iDeal, SofortBanking, or SEPA direct debits. Within the EU, alternative payments will be an interesting alternative to card payments. Do not be mistaken, they already have strong customer authentication embedded in them, but the difference is that their users are well-accustomed to those flows, ensuring high conversion rates. Another payment method that can be used as an alternative is PayPal.
With 2Checkout, this process is handled through a retry page that allows the customer to choose from other available payment alternatives to complete the purchase.
When the transaction goes through the «challenge flow» and authentication fails. Good practice is to offer an alternative payment method and continue with the purchase.
As mentioned above—and it’s so important that it’s worth repeating—recurring transactions are treated as exemptions, as long as the charge is made for the same amount, for the same payee, and the same recurring cycle. Even though subscription renewals are exempted, and we ensure they are flagged as a Merchant Initiated Transaction (MIT), there is a chance that some issuing banks will still require SCA to complete the recurring payment. The end-customer, therefore, needs to be brought back in session to complete authentication.
In order to tackle these use cases, we help our merchants with dedicated email notifications sent out to inform and collect SCA from end-customers. If 3DS2 verification is needed and your customer isn’t prompt in authenticating a transaction, then the bank will decline the payment. In such cases, it’s essential we communicate this to your customers by sending them 3DS2 email reminders bringing them on-session to complete the verification needed.
When a recurring transaction does not go through as an exemption, the customer receives a message asking her to authenticate in order to continue the subscription.
Once «in session», the customer can proceed with the 3DS2 authentication and the recurring transaction can continue uninterrupted.
PSD2 and SCA Impact – Final Thoughts
As a wrap-up, it’s worth noting that we’ve upgraded our checkout pages (both hosted and inline) to support the new European directives. We’ve also included the new 3DS2 protocol into our APIs and payment pages in a way that is designed to keep changes for merchants at a minimum, and minimize the impact of SCA on checkout conversions.
The first issuing banks are already gradually supporting 3DS2, but the whole changeover process will still take some time. Therefore, 3DS1 and 3DS2 will exist side by side as standards until further notice, and we expect both will be accepted by banks and card issuers for a while longer. Our platform was designed to detect whether authentication is needed, and, depending on what the card issuer supports, either use 3DS2 to authenticate the customer or fall back on 3DS1 when the new version isn’t yet supported by the respective bank.
We believe successful handling of exemptions will become a key component for building a first-class payments experience that minimizes friction. We also expect there will be differences in how national regulators and even individual banks will support exemptions and we are building solutions to help manage this complexity for you.
In the meantime, if you want to learn more about this and dive deeper into use cases for possible feature impacts, view our webinar on “All you need to know about PSD2 and Strong Customer Authentication if you sell online” and read more resources and our FAQs on the 2Checkout dedicated PSD2 landing page.
