What is 3D Secure?
3D Secure or "3DS" (the most recent version is called EMV 3-D Secure) is a protocol for securing card payments, which is standardized between the various card schemes. This protocol allows the card issuing banks to evaluate the payment request and issuer a challenge to the customer to authenticate themselves. In turn, if this authentication is successful, the merchant will be granted a liability shift for “fraud” chargebacks - where the issuing bank will assume financial responsibility for instances where payments are made fraudulently.
The 3DS protocol, now termed “3DS 1.0,” was created in the early 2000’s by Visa under the brand “Verified by Visa” and eventually the other card schemes created their own services to conform to the protocol. In 2016, ahead of the PSD2 regulation enforcement in Europe, EMVco was contracted to produce the next version of 3DS (colloquially referred to as 3DS 2, but officially branded as EMV 3-D Secure)
To help understand the various components and responses from 3DS authentication, we’ve put together a glossary of the acronyms and other 3DS-specific verbiage.
|3D-Secure or “Three Domains of Security” is the authentication protocol
|Payment Service Directive 2 is an EU regulation for payments
|Strong Customer Authentication - the regulatory requirement for qualifying payments in PSD2
|Cardholder Authentication Verification Value (sometimes presented as “AVV” as in the case for Mastercard) is the cryptogram that indicates a payment is authenticated
|E-Commerce Indicator Flag is a numeric value to indicate what kind of payment is being made, as well as its level of authentication
|Transaction ID is a value previously utilized for 3DS 1.0
|An indication of whether or not the liability for fraud has been moved to the issuing bank
|Access Control Server is the entity which performs the risk evaluation and the authentication on behalf of the card issuer in a 3DS authentication flow
|3DS Server / MPI
|3D-Secure Server or as it was previously termed “Merchant Plug-In” provider in 3DS 1.0 is the entity that handles the merchant’s requests for authentication
|Customer Initiated Transactions - these are payments where the customer is present
|Merchant Initiated Transactions - these are payments where the customer is not present such as a recurring monthly subscription
How Does The Rvvup Integration Work?
The Rvvup Pay by Card integration will run 3DS on all transactions by default, as this is the best way to comply with the PSD2 regulations for “customer initiated transactions”, which we’ll cover in a later section. This means that as soon as a customer has input their card details and confirms their order, a 3DS authentication will take place before the payment is made.
For a deeper look into how 3DS authentications work, see the steps below:
3DS Version Support - PReq Message
When your Pay by Card integration requests a 3DS authentication, the integration will first assess if the issuing bank can support 3DS 1.0, or the newer EMV 3DS (sometimes referred to as 3DS 2.0). This is facilitated by the Preparation Request Message or “PRes” message which is carried out ahead of any 3DS, and cached for performance improvements. In addition to the 3DS versions supported, the “method URL” for the issuing bank’s ACS will be provided at this step.
Before the authentication challenge is made, the issuing bank’s 3DS provider (which is called an ACS server or “Access Control Server” which may be a third party or the bank may run this server itself) will run a data collection URL to help their risk assessments. This data collection is facilitated by running the “method URL” on a pixel on screen.
Authentication Request - AReq Message
Once the method URL completes, a request for a 3DS authentication is made via the AReq message. This message will include all of the payment information that your payment form has collected (billing address, email, customer name, etc) as well as additional device and browser data collected by the Rvvup payment integration running on your payment page.
At this point there are a few possible outcomes from the response:
- Challenge Needed - The issuing bank has determined that the customer needs to pass an authentication challenge, and a URL is provided in the response
- Frictionless Authentication - The issuing bank has determined that no challenge is needed and provides a cryptogram for payment authentication (a CAVV/AVV, along with an ECI of 05 or 02)
- Card Scheme Authentication - The issuing bank is not responsive and the card scheme has stood in using an ATTEMPTS server to provide a cryptogram for payment authentication (a CAVV/AVV along with an ECI of 06 or 01)
- Authentication Rejection - The issuing bank has determined that this authentication request should be rejected prior to a challenge
- Error - An error occurred in the 3DS request and the authentication request has failed.
Authentication Challenge - CReq
If the authentication request ended with a requirement for a cardholder challenge, a URL will be made available in the response and the customer will be sent to their issuing bank to complete the authentication challenge. This may be in the form of a QR code to approve the payment via their bank app, a 2FA code, or any other authentication method the customer’s bank utilizes. In some cases, customers will not actually have to take any action or pass a challenge to complete this step successfully.
From here, there are a few possible outcomes from the authentication request:
Successful Authentication - The customer successfully completes the authentication, and the issuing bank will provide a cryptogram for payment authentication (a CAVV/AVV, along with an ECI of 05 or 01) when you verify the result
Unsuccessful Authentication - The customer failed the authentication, and the
Customers can also leave, time out, or experience an error during the challenge itself (which may or may not manifest as an error depending on the issue they experience).
Authentication Confirmation - RReq
Finally, when the authentication step is completed, the results will be verified with the issuing bank’s ACS, where the authentication cryptogram and ECI flag will be retrieved and attached to the payment authorisation.
↪️ Liability Shift
As mentioned previously, successfully authenticated payments will shift the liability of fraudulent payments from the merchant to the issuing bank of the customer’s card. In practice this means that when a customer wants to dispute a payment with their bank because the payment was fraudulent, the card schemes would not allow the authenticated payment to result in a chargeback to the merchant, and rather the issuing bank would need to compensate their cardholders for these instances.
Specifically, the following chargeback reason codes should be prevented:
American Express: ****F29
In some rare cases, such as payments where the card scheme has authenticated the payment instead of the issuing bank, the issuing bank may be able to successfully create a chargeback using a fraud/unauthenticated reason code. In these cases, you will be able to win the dispute by including the payment details of your transaction in the dispute, proving the authentication.
PSD2 and SCA
The “Payment Service Directive 2” or “PSD2” regulations were approved in the EU in 2015 (and it should be noted that these regulations were also adopted by the UK’s FCA as well) to, among other stated objectives, to clarify and impose the regulatory technical standards for “strong customer authentication” or “SCA”. For card payments, this largely means the utilization of 3DS where customers are present for the payment referred to as “customer initiated transactions” or “CIT”.
SCA - Definition
“Strong Customer Authentication” is defined as containing two of the following three authentication factors:
- Knowledge: Something your customer knows e.g. a password
- Possession: Something a customer has e.g. a smartphone or other connected devices
- Inherence: Something your customers are e.g. a biometric such as fingerprint or face ID
The original version of 3DS could not allow issuing banks to conform to these requirements, but this is now the case with 3DS 2.0.
SCA - Enforcement
All of the parties involved with in-scope payments are deploying requirements to comply with these regulations, but the main parties that are being directly regulated are your customer’s card issuing banks - as they have requirements to not approve in-scope transactions which do not have SCA. The various card schemes have also added new decline codes to help indicate that a given payment was declined specifically for needing SCA.
Beyond this, the card schemes and merchant acquiring banks have rolled out their own requirements to have merchants start using 3DS 2.0 on their in-scope transactions.
SCA - Card Payment Scope
Not all card payments fall into the “scope” of PSD2’s SCA requirements. To help understand what payments and payment flows are included in the requirements, see the broad rules below
- “Both Legs In” - In order to fall within the regulations, both “legs” of the payment (meaning the card issuing bank, and the merchant’s acquiring bank) must both be within the EEA & UK. This means if your customer’s card is issued outside the EEA e.g. the card was issued in the US, you will not be required to run 3DS on that payment.
- Customer Initiated Transactions (CIT) - Another requirement for the payment to be in-scope is when the payment is being initiated by the customer. For example this would be the case for a standard online purchase i.e. an e-commerce experience.
- Recurring / Merchant Initiated Transactions (MIT) - Conversely, recurring payments such as subscriptions, or other “MIT” payments such as a cleaning fee billed after the fact, would not require an authentication to be completed so long as the initiation of the subscription/MIT contract was done so with SCA in the first place. This would effectively mean that the first payment/acceptance of the card information for a subscription would always require 3DS.
3DS Transaction Scenarios
As described above in the 3DS integration deep drive, there are a number of potential outcomes for 3DS authenticated transactions.
Below is a matrix of the various outcomes, their descriptions, parameters you should expect, and how to test them:
|ECI (Visa / Mastercard)
|05 / 02
|The card issuer sends a challenge to your customer where they successfully authenticate
|Successful Frictionless Authentication
|05 / 02
|The card issuer approves the authentication without a challenge
|06 / 01
|The card scheme steps in to provide an authentication value
|07 / 00
|The card issuer sends a challenge to your customer where they fail the challenge and do not authenticate
|07 / 00
|The card issuer rejects the authentication request without presenting a challenge
|07 / 00
|An error occurred during the 3DS authentication which prevented the card issuer or stand-in server from providing authentication
Reminder: Test Credit Cards only work in a test environment using Rvvup Test mode.
Do Apple Pay payments require 3DS?
Apple Pay payments do not require 3DS authentication as its inherent authentication protocols have been approved for SCA between Apple and the participating issuing banks.