Fitting 3D-Secure with payments architecture
This post is not an explainer about 3D-Secure 2.X (3DS2). If you are looking for a better understanding of this topic before diving in, here’s a list of resources that we’ve curated to answer the following questions:
As we know, regulation in Europe through Payment Services Directive 2 (PSD2) is driving the current implementation deadlines for 3DS2 in Europe as it is the most well known solution to achieve strong customer authentication on card payments.Yet, no matter the card scheme, previous versions of 3DS—3DS2.1 and 3DS2.0—all failed to meet the European Banking Authority’s requirements to achieve compliance for PSD2’s SCA requirement. Outside of Europe, Issuers in Canada, Latin America, and the U.S. are to support 3DS 2.2 and dynamic linking this year even though there is no regulation prompting these updates. Dynamic linking is a critical facet for the 3DS2.2 implementation to sufficiently meet PSD2’s requirements for SCA.
Looking past the COVID crunch on resources, the difficulty of the 3DS2 implementation varies from merchant to merchant. When implementing 3DS2, Bryan Penny at American Express cleverly calls out four critical considerations for merchants.
- How will 3DS2 integrate into the merchant’s existing architecture and payment flows?
- How much will 3DS2 cost the merchant?
- What are the merchant’s latency requirements?
- How much fulfillment time does the merchant have before shipping the order?
All four are valid questions that need to be jointly answered by both the fraud and payments teams within a merchant organization. These answers will differ from merchant to merchant but are heavily dependent on each merchant’s current payments architecture. The availability of the PAN is critical in these decisions since the Access Control Server (ACS) won’t grant 3DS authentication approvals without it. To shield the PAN, merchants often use tokens provisioned by their PSPs, but these tokens are not interchangeable with other PSP tokens. Each merchant must qualify how vital it is to its business to have flexibility and redundancy between providers on this soon to be mandatory functionality.
The OpEx cost considerations with 3DS are also considerable. Merchants with a single PSP relationship may get bundled pricing on their authentications and authorizations. For merchants leveraging a multi-processor model, they will expect to pay a flat per-transaction fee for each 3DS call. As 3DS2 isn’t widely in production yet, we don’t know if this additional fee justifies the cost of sending every transaction to a network’s Directory Server for the opportunity of better approval rates. What we do know is that in markets without an SCA mandate, 3DS2 approvals can lead to declines in authorization rates. We know that when the network stands in for the issuer authorization rates drop. Fortunately, we also know that when an issuer approves a hard challenge to a 3DS2 request, approval rates lift, thus fulfilling the promise of SCA’s safer and improved approval rates.
Critically, we also know that latency is a massive concern with the 3DS2 protocol. As noted in Payment Insecurity: How Visa and Mastercard Use Standard Setting to Restrict Competition and Thwart Payments Innovation:
The architecture of 3DS2 is essentially similar as 1.0, but now with greater amounts of data passing through (theoretically). There were timeout conditions that led to greater cart abandonment with 3DS1 and this is the same with 2. (p. 42)
At the 2019 EMVCo Annual Forum, there were only a handful of live implementations of 3DS2, with none completing a “frictionless flow” authentication in under 10 seconds. Even the Mastercard Authentication Guide for Europe admits as much.
As declined authorizations followed by an authentication and another authorization will add an estimated 10 seconds latency, some Cardholders may abandon such transactions. (p. 28)
Let’s get to the bottom of this.
First, let’s assume a merchant’s known latency from their gateway to their 3DS Server to the Directory Server takes no more than 400 milliseconds round trip. Let’s also incorporate the fact that many issuer implementations are being passed a risk score from their ACS, not the actual data transmitted in the 3DS fields. A decision on such a risk score takes milliseconds. It is our opinion that the increased latency lies with the Directory Servers because they are single-threaded gates that connect the CardinalCommerce 3DS server and the CardinalCommerce ACS. Given that the most significant two card schemes maintain their servers on company-owned soil, latency to support global transaction volume was already a concern. It will be interesting to understand how the cardholder data they collect for fraud scoring will achieve compliance with the recent Data Transfer ruling in Europe and Brexit. One wonders how long it takes to buy land and build a data center in Europe during a pandemic.
But isn’t there any good news for merchants?
Yes. First and foremost, Julie Ferguson and Una Dillon of the Merchant Risk Council have done a fantastic job bringing the current state of 3DS awareness to the forefront. If you haven’t visited yet, here it is again:, What’s the current state of 3D-Secure? It’s that informative. Secondly, there are still paths merchants can take to achieve compliance and maintain their flexibility.
When we assembled the 2020 Payment Vendor Report, we found it necessary to identify the gateways and hubs that support their own EMVCo certified 3D-Secure (3DS) servers. Two participants in the report can offer their clients this setup, ACI Pay.On and Mastercard Payment Gateway Services (MPGS). Neither has to acquire a merchant’s transaction to perform 3DS services. Neither product is subject to PSD2 regulations. The connections both gateways offer greatly assist merchants in achieving 3DS2 compliance by minimizing the number of parties to a transaction and providing merchants the flexibility to route transactions to best lift approval rates. As testified to by Nilixa Devlukia of Open Banking and Helene Ofer-Zaher of the European Banking Authority, SCA rests with the issuer. Changing acquirers would not make a difference.
In the same way that merchants load balance transaction routing to improve approval rates, or mitigate chargebacks, we expect to see merchants perform the same tactics to leverage exemptions such as delegated authentication, whitelisting, and transaction risk analysis. Pay.On and MPGS provide some of the base to accomplish those goals.
In addition to its hundreds of payment connections, PAY.ON Payments Gateway is EMVCo certified for 3DSecure versions 1.0 and 2.1. Further, ACI also operates its own Merchant Plug-In (MPI) for in-line 3DSecure support, and it supports authentication processing to third-party providers such as Cardinal Commerce.
MPGS supports 3-D Secure 1.0 directly and is integrated with Mastercard’s 3-D Secure 2.2 server, allowing merchants to leverage the latter and fallback to the former. MPGS offers authorization processing directly to the Issuer via Banknet, referenced as Switch-to-Issuer (“S2I”). S2I allows the MPGS to perform authorizations through the Mastercard network without needing to connect to the merchants’ acquirers. After authorization, a draft capture file is sent to the merchant’s acquiring bank to trigger settlement. This unique flow allows for fewer authorization hops, faster response times, and higher availability.
To learn more about MPGS and ACI Pay.On as well as other services providing payment gateway and orchestration services, download a free edition of the 2020 Payment Vendor Report.
Get in touch with the Paladin team
subsidiary of MVB Bank, Inc.
301 Virginia Avenue,
Fairmont, WV 26554