Skip to content

    3D Secure - 3DS 1.0

    Overview

    3D Secure is a security protocol that is designed to provide an additional layer of security for payment cards and online transactions. The name 3D comes from the three-domain model designed to provide an additional layer of secure authentication between the financial authorization process and online authentication process. The three domains used to provide this security are:

    • Acquirer Domain: It encompasses systems and functions of the acquiring bank (merchant's bank) and the merchant receiving the transaction payment. The main component of the domain is Merchant Plug-In (MPI) that creates and processes payer authentication messages and then returns control to the merchant software for further authorization processing.
    • Issuer Domain: It encompasses systems and functions of the card issuing financial institutions and its customers. The main component of the domain is Access Control Server (ACS) that verifies whether authentication is available for a card number and device type
    • Interoperability Domain: It encompasses systems, functions and messages that allow the Issuer Domain and Acquirer Domain to interoperate. Its components are globally operated and managed by card schemes. The main component of the domain is Directory Server (DS) that authenticates the 3DS Server requests and validates the 3DS requestor as trusted and registered.
    3D Secure at a Glance

    The following 3 D Security authentication services are supported and integrated on Payengine:

    • American Express SafeKey
    • Mastercard SecureCode
    • Visa Secure (formerly Verified by Visa)

    Benefits of 3D Secure usage

    Main benefits of 3D Secure for the merchants can be found listed below:

    • Liability shift: When a chargeback occurs, merchants are typically liable for this transaction. With 3D Secure, the liability is shifted from merchants onto merchants' issuing banks.
    • Chargeback protection: When merchants use Verified by Visa, merchants are guaranteed to never receive a chargeback. This protection helps secure merchants against friendly fraud or chargeback fraud.
    • Interchange benefits: Merchants may be able to access lower interchange fees and benefit from longer payment terms with acquirers.
    • Customer confidence: Customers will feel more confident knowing that there is an extra level of security in place to protect their data.
    Pay Engine - 3D Secure - Flow

    Step 1 - Check Enrollment

    A precondition that may trigger launching of 3DS flow is executing of Authorizing transaction request (either Preauth or Debit) from merchant to Payengine using either Payment Instrument ID or plain written payment card data.

    Based on Preauth/Debit transaction request from a merchant, Payengine submits a Check Enrollment request on the Cardholder PAN via 3DS environment.

    The purpose of Check Enrollment request is to identify whether payment card is enrolled in 3D Secure program. Depending on response of the Check Enrollment request are possible the following two scenarios:

    1. Payment card is enrolled in 3DS program, then status of the Authorizing transaction will be set to 'PENDING' and consumer will be redirected to a 3DS URL.

    Response of the transaction will contain the following specific parameters:

    • threeDs field in meta object with value "2"
    • redirectUrl that will redirect the consumer to 3DS Authentication page

    threeDs field can show one of the following possible values:

    ValueDescription
    0No 3DS Transaction or failed
    1Card is not enrolled or issuer does not support 3DS
    2Successful

    Example Response of Authorizing transaction (Debit) for payment card enrolled in 3DS program

    {
        "createdAt": 1555499517921,
        "modifiedAt": 1555499517992,
        "merchantId": "Merchant-11111111-1111-1111-1111-111111111111",
    1. Payment card is not enrolled in 3DS program, then the flow will continue as synchronous one which means that:
    • there will be no redirect URL ("redirectUrl" field in Authorizing transaction response will be with null value)
    • status of the Authorizing transaction will be either SUCCESS or FAILURE

    Example Response of Authorizing transaction (Debit) for payment card not enrolled in 3DS program

    {
        "createdAt": 1552053906342,
        "modifiedAt": 1552053906403,
        "merchantId": "Merchant-11111111-1111-1111-1111-111111111111",

    Step 2 - Cardholder Authentication

    In 3DS Enrolled Card option, once the 3DS page loads, the consumer authenticates in most of the cases via a permanent password.

    After authentication process, Payengine receives the Authentication result.

    You can find below an example for 3DS page shown on the consumers.

    Verified by VISA example

    Step 3 - Authorizing the transaction by the Acquiring bank

    Once Payengine receives Authentication result from 3DS environment, an Authorization request with card details and the Authentication result is submitted to the Acquiring bank (ConCardis GmbH for all payment cards except Amex). The Acquiring bank authorizes the transaction by communicating with the credit card network and Issuing bank.

    In response Payengine receives the result of the Authorization request which can be either success or failure.

    Step 4 - Redirecting Cardholder to the payment result page

    Based on provided response of Authorization request Payengine updates status of the order and redirects consumer to either Success or Failure page for the payment.

    Was this helpful?

    What was your feeling about it?