3DS

3DS Overview

3D Secure (3DS) is an industry-standard security protocol that provides an extra layer of protection for online credit and debit card payments (known as Card-Not-Present or CNP transactions). VGS supports the 3DS protocol version 2.2.0 and above.

Its primary goal is to confirm that the person making an online purchase is the legitimate cardholder, which drastically helps prevent fraud. The "3-D" refers to the three parties (domains) that securely interact during this process:

  1. Acquirer Domain: Your bank or payment provider (the merchant's side).

  2. Issuer Domain: The cardholder's bank.

  3. Interoperability Domain: The card network systems (Visa, Mastercard, etc.) that connect the two banks.

Why Use 3DS2? The Benefits

We strongly recommend using 3DS2 because it offers two critical business advantages:

  • Chargeback Liability Shift: When a transaction is successfully authenticated via 3DS2, the liability for fraudulent chargebacks often shifts from your business to the card-issuing bank.

  • Regulatory Compliance: 3DS2 is the primary method for complying with global regulations, such as Strong Customer Authentication (SCA) under the European PSD2 directive, which mandates multi-factor authentication for many online payments.

The Customer Experience: Frictionless vs. Challenge Flows

VGS customers can leverage the 3DS service within the CMP platform to perform additional credential authentication. The 3DS2 service utilizes Risk-Based Authentication (RBA) to determine whether to interrupt the customer's checkout process. Qualifying transactions will proceed via one of two paths.:

1. Frictionless Flow

In the frictionless flow, the authentication occurs silently in the background without any interruption to the customer.

  • How it Works: Your system sends a rich set of data (including transaction details and a unique device fingerprint) to the cardholder's bank.

  • The Decision: The card-issuing bank reviews this data. If the transaction is deemed low-risk, it is approved and authenticated without requiring any action from the customer.

  • Benefit: This increases approval rates for legitimate customers and significantly reduces cart abandonment.

2. Challenge Flow

The challenge flow is initiated only when the card-issuing bank is not fully confident in the transaction based on the data alone (e.g., a high-value purchase or new device).

  • How it Works: The bank "challenges" the user to provide additional proof of identity. This is seamlessly embedded within your checkout page (no disruptive pop-ups).

  • Authentication Methods: The customer verifies their identity using Strong Customer Authentication (SCA) methods, such as:

    • Entering a One-Time Passcode (OTP) sent to their phone.

    • Approving the purchase through their mobile banking app.

    • Using biometrics (fingerprint or facial recognition).

  • Benefit: A successful challenge results in a liability shift for the merchant, providing the highest level of fraud protection.

Merchant Onboarding: Key Steps for 3DS Integration

1. Acquirer Setup:

  • The Merchant has to provide the Acquirer BIN registration info which they have with their current acquirer, this is required to onboard the merchant at VGS.

  • The same Acquirer BIN should be used consistently for both authentication (3DS) and authorization flows.

2. Production Activation:

  • Before submitting any Authorization requests (3DS) in Production, merchants must confirm with their acquirer or Payment Service Provider (PSP) that authorization processing is fully activated to successfully pass the 3DS data through. This step is critical to ensure smooth 3DS processing and prevent transaction mismatches.

3. Data Transmission:

  • VGS 3DS data is widely accepted. Merchants must embed the 3DS authentication result within their Authorization or Purchase requests. However each PSP, however, has its own requirements for processing external 3DS authentication details. To correctly map these values, refer to the PSP’s documentation or contact their support. Typically, fields such as ECI and CAVV (cryptogram) are required, and in some cases, additional parameters from the transaction info such as Directory Server or Access Control Server transaction IDs etc. may also be used.

  • The acquirer, gateway, or PSP will then transmit this information to the card issuer, confirming a successful 3DS authentication.

Using 3DS with VGS

  1. Account Setup & Prerequisites: Before you can use the 3DS APIs, your account must be configured.

    • Enable 3DS on Your Account: 3DS must be explicitly enabled for your VGS account. Please contact VGS Support or your designated VGS implementation representative to begin the onboarding process and have this feature activated.

    • Provide Merchant Information: As part of onboarding, you will need to provide your general business and required network information (listed below).

      • Acquirer BIN is used consistently for both authentication and authorization flows.

    • Configure Service Account: Once 3DS is enabled, configure your Service Account with the necessary permissions, including the 3ds:write scope (in addition to cards:read and cards:write).

  2. Onboarding Information: You will need to provide the following information to VGS to enable 3DS:

    • General Business Information

      • Business Type

      • Merchant Name

      • Merchant URL

      • Merchant Category Code (MCC)

      • Merchant Country

    • Required Network Information

      • Merchant ID (MID)

      • Acquirer BIN (must be used consistently for both authentication and authorization flows)

      • Acquiring Country

      • Requester ID (Only for Amex and Discover)

  3. Testing in sandbox: Once your account is enabled for 3DS:

    • Generate a service account with cards:read, cards:write, and 3ds:write scopes

    • Generate a JWT auth token from that service account

    • Use the token to first create a card in CMP

    • Then use the generated cardID to invoke the VGS 3DS Initialize and Authenticate APIs

You can also test your integration using the 3DS mocks available in the sandbox.

  1. Testing in production:

    • Before going live with a new processor or acquirer, perform the following control testing for each card scheme:

    • Verify your Account for 3DS: Contact your acquirer or Payment Service Provider to ensure that authorization processing is activated for your account to pass the 3DS data through. This ensures smooth 3DS processing and avoids transaction mismatches.

    • Challenge Flow Test: Run at least one successful challenge flow test per scheme (Visa, Mastercard, etc.). Each scheme must be tested separately;

    • End-to-End Verification: Conduct a full end-to-end authorization test to verify all components are working as expected before releasing full transaction volume.

PreviousNotificationsNext3DS Frictionless Flow

Last updated