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)

3DS Terminology

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.

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.

Method URL

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:

Visa: 10.4

Matercard: 4837

American Express: ****F29

Discover: UA02

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:

Reminder: Test Credit Cards only work in a test environment using Rvvup Test mode. 

FAQs

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.