3D Secure Transactions

On This Page

• EU Regulations
• Compliance
• Authentication
• Exemptions
• 3D Secure Transactions
• When 3D-Authentication is Complete

EU Regulations

We can take care of your payments’ compliance.

We meet the European Union’s (EU) Second Payment Service Directive (PSD2) Regulatory Technical Standards (RTS) on Strong Customer Authentication (SCA). All Opayo payments taken within the European Economic Area (EEA) undergo 3D Secure authentication unless an exemption applies. You can learn more from the PDS2 Compliance page.

Compliance

To keep you compliant, we use a 3DSv2 authentication service. Advantages include:

• An up to 90% approval rate when submitted for authorisation.
• Liability is shifted from merchants onto the card issuer and, or acquirer in cases of a chargeback.

Authentication

95% of 3DSv2 transactions are expected to be “frictionless”. The payments experience is improved because:

• The cardholder is unaware that authentication has even taken place.
• You don’t need to re-direct the cardholder to the Access Control Server (ACS) for them to enter two-factor authentication.

Challenges

When the 3D Secure scheme needs more information about an authentication request:

1. It can request that the cardholder is “challenged”.
2. You must then re-direct the cardholder to the ACS using the ACSURL.
3. The cardholder must then complete two-factor authentication before returning to your website with the authentication result (ARes).

Exemptions

Some transactions are exempt from PSD2 including Low value Transactions (LVT) and secure corporate payments. We advise leaving the exemption handling to the card issuer and acquirer.

When a merchant asks for an exemption, liability for chargebacks is automatically shifted to the merchant. There is a higher chance that the transaction is refused when the card issuer does not agree to the exemption.

Merchant Initiated Transactions (MITs) are out of scope of PSD2. However, the original eCommerce transaction must have performed 3D Secure authentication and the cardholder challenged. This is achieved by submitting the Apply3DSecure field with a value of ‘1’ or ‘3’ in your Direct Transaction Registration POST.

3D Secure Transactions

To request a 3D Secured authorisation:

1. When your customer checks out their basket, collect their details and display a payment page secured with your 128-bit SSL certificate.
2. The page POSTs to a script on your site which pre-validates the data. It then formats and sends a normal server-side Direct Transaction Registration POST to Opayo.
3. The POST is validated against your IP address list and the data checked for errors.

When found correct, the details are sent using an authentication request to the 3DSv2 directory service. This tests the conditions in the following table.

When the card and issuer are part of the 3D Secure scheme, Opayo Direct will know instantly when:

• The authentication is successful or not (a frictionless authentication).
• The 3D Secure scheme requires the cardholder to enter their security credentials (a challenge authentication).

Frictionless Authentication

For a frictionless authentication, the 3D Secure scheme has enough information about the cardholder to provide an instant authentication result. When the authentication process has completed the transaction is submitted for authorisation.

If authentication fails, we check your 3D Secure rule base and determine if you want to proceed with the authorisation, or not. If authorisation does not proceed, you will receive an authorisation status of REJECTED and a 3DSecureStatus informing of the authentication result.

Challenge Authentication

When the 3D Secure scheme requests a challenge, we:

• Format and encode a 3D Secure request message called a CReq.
• Reply to your POST in the Response object with the CReq.

The Response object contains:

• A unique transaction code called the VPSTxId (Opayo Direct’s unique transaction identifier).
• A URL called the ACSURL. This is used to direct the cardholder to the 3D Secure authentication page at their Issuing Bank.

Your server creates an automatically submitted HTML form that POSTs the user, and the CReq fields to the ACSURL.

From your customer’s perspective, they have entered their card details on your payment page, clicked submit, and been transferred to their card issuer to validate their 3D Secure credentials.

We recommend that:

• The VPSTxId value is stored against your own unique payment identifier (VendorTxCode). You will require the VPSTxId when returning the authentication response to Opayo Direct in a later step.
• You POST the threeDSSessionData with the value of VPSTxId. This allows you to link the CReq provided by Direct with the CRes provided by the ACS and the payment session associated with the relevant VendorTxCode.

When 3d-Authentication is Complete

When your customer completes 3D-authentication, their Issuing Bank will redirect them back to a script on your site using the ThreeDSNotificationURL. The customer returns to your site with:

• The threeDSSessionData of the transaction (if you provided it), and
• The results of their authentication in a Base64 URL encoded field called the CRes.

We take care of decrypting and decoding this information for you. Your ThreeDSNotificationURL page only needs to send the following to us in a Base64 URL Encoded format:

• A Server-side HTTPS POST containing the VPSTxId, and
• The CRes fields.

We determine when authentication is successful from the CRes.

When authentication is successful:

• The original Opayo Direct POST details are retrieved,
• Authorisation is obtained from your acquiring bank.

Results are returned in the Response object of your ThreeDSNotificationURL POST with a:

• Status (authorisation result)
• 3DSecureStatus (authentication result)
• CAVV value (a unique authentication code)

When authentication is not successful

We check your 3D Secure rule base and determine how you want to proceed.

When you want to obtain authorisations for non-3D-authenticated transactions, we request an authorisation from your acquiring bank and reply as normal. If not, we return a REJECTED message and do not obtain an authorisation.

Authentication Data Errors

We return either a MALFORMED, INVALID, or ERROR when:

• Your CRes does not match VPSTxId sent with the CReq, or
• Data elements are missing, or
• Data elements fail validation.

Displaying Authentication Results

Your ThreeDSNotificationURL should update your database with the authorisation result and display a completion page to your customer.

Related Pages

• Direct Transaction Registration POST
• SCA Exemptions
• PDS2 Compliance