3D Secure and PSD2

Overview

3DS2 (3D Secure 2.0) is the latest authentication protocol version that uses risk-based analysis of over 100 data points to enable frictionless authentication when risk is low, only requiring customer challenges when necessary. PSD2 (Payment Services Directive 2) is a European regulation requiring Strong Customer Authentication (SCA) for online payments in the EEA, typically satisfied through 3D Secure 2.0 authentication.

Add 3D Secure data

To add 3D Secure (3DS) data to your transaction, you'll need to supply either an authentication ID or the authentication data.

{
  "threeDSecureData": {
    "authenticationId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

Add a PSD2 exemption

PSD2 requires that Strong Customer Authentication (SCA) is applied to all electronic payments including proximity and remote payments, within the European Economic Area (EEA) and the UK. However, you can request an exemption for certain types of transactions, such as low value transactions (under 50€).

To add an SCA exemption, add the following snippet to the body of your request.

{
  "psd2Data": {
    "scaExemption": "LowValue"
  }
}

Soft declines

When you request an SCA exemption and it's applied directly in the authorisation message without authentication being carried out beforehand, the transaction may be declined by the issuer. They'll provide a specific soft decline response code indicating that additional authentication is required.

Receiving any of these codes means that the issuer has requested that the transaction must be authenticated. In order to avoid another soft decline, you'll need a mechanism to retry the payment with the same card details and ensure that SCA takes place.

The following table lists the possible soft decline response codes and the provider(s) they apply to:

Handling soft declines

You must initiate a new transaction and authenticate it with challenge. The process should be seamless for the cardholder, so that when the transaction is soft declined they're simply taken to the authentication screen. You need to re-initiate the transaction automatically in the background without prompting the cardholder to enter any transaction data.

To do so:

• If you use PXP's integrated 3DS service, you need to send a pre-initiation request and then initiate the authentication with requestorChallengeIndicator = 04 (challenge requested as a mandate). See Pre-initiate an integrated authentication request for more information. Once authentication with challenge is done, you can proceed with initiating another transaction with the authenticationId so that we can send the 3DS data in the authorisation request to the provider.
• If you use a third-party provider for 3DS authentication, make sure to request the option that corresponds to requesting challenge as a mandate and send cardholderAuthenticationVerificationValue, directoryServerTransactionId, electronicCommerceIndicator, threeDSecureVersion and threeDSecureTransactionStatus upon successful authentication.

Liability shifts

A liability shift occurs when the responsibility for fraudulent chargebacks transfers from the merchant to the card issuer. In 3D Secure authentication, when a transaction is successfully authenticated, liability for fraud typically shifts away from the merchant to the issuer, protecting you from fraudulent chargeback costs.

The following table describes when a liability shift occurs.