Updated November 2020 with new enforcement dates
In this blog post, we’ll dive more deeply into the mechanics of 3-D Secure (3DS2) and Strong Customer Authorization (SCA), the two main—and related—requirements of the new PSD2 regulation. We’ll discuss the various parties and their interactions in order to provide higher-level context into where your subscription business fits into the overall scheme and how Recurly will help to facilitate the authentication process.
For background on PSD2, see this blog, posted in May.
Meet the players
Let’s start with an overview of the various parties involved in 3DS2/SCA and how they interact with each other from a systems perspective.
The bank that issued the credit or debit card being used to pay for goods or services associated with the transaction.
The bank holding the merchant account that will receive funds in exchange for goods or services.
Access Control Server (ACS):
A service either hosted by or related to the Issuer. ACS is responsible for displaying challenge URLs, generating device fingerprints, and verifying that the cardholder is non-fraudulent.
Merchant Plug-In (MPI):
A module, designed to facilitate 3-D Secure/SCA verification and prevent payment card fraud. Verifies the card number with the card Issuer and checks if it is enrolled in the 3-D Secure program. Typically, this is provided by your payment gateway to facilitate interactions between you and the Issuer responsible for completing the SCA process.
Understanding the SCA flows
The actual interaction between the parties and/or systems noted above can take many different forms, depending on the transaction. Specifically, we can subdivide SCA into a few different flows, with each requiring various levels of engagement from your customers and/or requiring a few extra steps from you in the implementation process. These flows are as follows:
Just as the name implies, this requires the least amount of effort from you and your customers. In fact, it is completely seamless and is the most preferable case if it can be facilitated. In this flow, the card Issuer/ACS determines that it has enough information to authenticate the transaction without any further verification steps. In the initial transaction attempt, Recurly will pass in any available customer details to your configured Payment Gateway/MPI, which will work with the ACS to determine if a frictionless flow can be utilized.
In some cases, the ACS may require a device fingerprint as additional verification data before it will authenticate the transaction. While this will not require any interaction from your customers, there are a few extra steps that are required on your part to ensure this happens. In order to simplify the integration on your behalf, Recurly facilitates device fingerprinting by leveraging tools provided by your Payment Gateway.
This flow requires direct interaction between your customer and the Issuer/ACS before the Issuer can complete the authentication process. The Issuer can do one of two things: accept the transaction or request request further proof of the customer’s identity. If the latter occurs, your customer will be prompted for additional information to confirm their identity. Similar to the fingerprint flow, Recurly helps to facilitate this interaction by leveraging components provided by the MPI and ACS. The actual challenge can take several different forms depending on the Issuer/ACS, including passcode verification or biometrics.
Not all MPIs are alike
Given that 3DS2 is a specification, many implementation details are left up to the discretion of individual Payment Gateways/MPIs, which means that integration tools and methods can vary substantially depending on the payment gateway(s) that you’re using. As such, the time and effort required can also vary along with the complexity of a particular solution. Additionally, if you wanted to change your payment gateway at some point in the future, it’s likely that you would need to re-implement your SCA integration.
Given that Recurly leverages multiple payment gateways as part of our platform offering, we’ve decided that we must provide a solution that solves these problems for our customers.
The Recurly Solution
Recurly provides a SCA solution that minimizes the complexity and effort required for you to integrate. Our solution builds high-level abstractions around the low-level functionality provided by many of the MPIs/Payment Gateways and the ACS.
MPI/Payment gateway agnostic
The Recurly solution provides a one-to-many integration that normalizes the MPI/Payment Gateway’s specific implementations of SCA, giving you the flexibility to use the solution that you need today, without being locked into it should your business needs evolve. This allows you to build your SCA flows once without the need to start from scratch if you decide to migrate to a different Payment Gateway/MPI.
Leverage existing tools and reduce time-to-market
Our solution is provided to you as an enhancement to existing platform components that you’re likely already using. On the client side, we’ve augmented Recurly.js with additional functions to handle aspects such as device fingerprinting and rendering customer challenge flows. To support server-side interactions with the MPI/Payment Gateway, we’ve augmented the Recurly API with some additional fields. Ultimately, our aim is to enable you to complete your SCA implementation in hours instead of days.
The Recurly SCA framework, along with a comprehensive integration guide, is available here. Please look for additional blog posts and be sure to read all emails from Recurly on this topic. Businesses not prepared to be compliant with PSD2 on the day it goes into effect (December 31, 2020 for the EU; the UK Financial Conduct Authority (FCA) has delayed enforcement to September 14, 2021) will see their revenue severely impacted.