3DS

3DS Overview

3-D Secure (3DS) is an industry-standard security protocol that provides an additional layer of protection for online credit and debit card payments, commonly referred to as Card-Not-Present (CNP) transactions. VGS supports the 3-D Secure 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 significantly reduces fraud. In some markets, such as the European Union, 3DS is a critical framework businesses rely on to comply with Strong Customer Authentication (SCA) regulations. The "3-D" refers to the three parties (domains) that securely interact during this process:

1. Acquirer: The card acceptor's bank or payment provider (the merchant's side).

2. Issuer: The cardholder's bank (the payer's side).

3. Interoperability: The card networks (Visa, Mastercard, etc.), systems (the internet, terminals, etc.), and service providers (VGS, Cardinal Commerce, etc.) that facilitate the exchange of data.

Note: This documentation provides a general 3DS overview and is not legal or commercial advice. VGS operates solely as a connectivity platform to facilitate secure data passthrough between its customers and payment-related services; we are not a Payment Service Provider (PSP) or Acquirer. You are responsible for your own regulatory compliance and all authentication and transaction logic. The 3DS standard and specifications are defined by EMVCo.

3DS Authentication vs Data Sharing

There are two options available with VGS's 3DS service: Authentication and Data Sharing. While both leverage the 3DS protocol, they serve different purposes. Authentication prioritizes compliance and liability protection, while Data Sharing optimizes for a seamless user experience and improved approvals.

Why Use 3DS Authentication?

3DS Authentication adds a layer of stronger authentication to the baseline 3DS, such as one-time passwords, that enable businesses to reduce risk and comply with critical regulations.

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

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

Why Use 3DS Data Sharing?

3DS Data Sharing allows businesses to share rich risk data with issuers without triggering a cardholder challenge. This background exchange helps "prime" the issuer's decision-making process to trust the user. However, unlike 3DS Authentication, 3DS Data Sharing usually does not shift chargeback liability to the issuer.

1. Authorization Uplift: By sharing data points like the cardholder's browser information and transaction details, you provide a digital fingerprint of the user's device and give issuers the context they need to approve low-risk transactions. This transparency reduces false declines and helps improve authorization rates, even without a full authentication challenge.

2. Seamless User Experience: Data sharing is informational only, it eliminates the possibility of a cardholder challenge (e.g., OTP). This guarantees a seamless checkout experience that preserves your conversion funnel, making it ideal for transactions where speed and a frictionless checkout are the priority.

3DS Authentication Customer Experience: Frictionless vs. Challenge Flows

VGS customers can leverage the 3DS service within the CMP platform to perform cardholder authentication. The 3DS service utilizes Risk-Based Authentication (RBA) that can make an authentication decision based solely on the data provided upfront, or to "step-up" the flow with a challenge that the cardholder needs to complete. 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.

3DS - Customer-Initiated Transaction vs Merchant-Initiated Transaction

3DS Authentication is used to verify the cardholder and establish trust with the card. Depending on who initiates the transaction, it falls into one of two categories:

• Customer-Initiated Transaction (CIT): A cardholder is attempting to perform an individual card-not-present transaction.

• Merchant-Initiated Transaction (MIT): A merchant is attempting to perform a subsequent transaction with a card that was previously used in a CIT.

3DS Authentication During CIT

• Key Characteristics:

  • Initiated by: Customer

  • 3DS required: Yes

  • Objective: Authenticate the cardholder and securely store the card

• Common Examples:

  • One-time purchases

  • First-time subscription signups

  • Saving a card on file

  • Initial setup of recurring or usage-based plans

• Important: Flag the transaction as CIT and include the 3DS authentication response in your authorization request.

3DS Authentication During MIT

In order to reduce friction, but retain the benefits of 3DS Authentication, ensure the merchant-initiated transactions are tied to a previously authenticated CIT.

This confirms to the bank that the MIT is based on a secure, previously authenticated transaction, and allows it to proceed without triggering 3DS again.

• Key Characteristics:

  • Initiated by: Merchant

  • 3DS required: No

  • Objective: Collect payment based on a previously established agreement

• Common Examples:

  • Recurring subscription payments (e.g., streaming platforms)

  • Usage-based billing (electricity, cloud storage)

  • Delayed charges (such as post-checkout hotel charges)

  • No-show or cancellation fees

  • Installment payments

• Important: Flag the transaction as Merchant-Initiated and include references to the original CIT.

Merchant Onboarding: Key Steps for 3DS Integration

1. Acquirer Setup:

• The merchant must provide the Acquirer BIN registration information, obtained from their current acquirer, within the merchant_info object when submitting the 3DS authentication request.

• 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. Supported Transaction Type for 3DS: For 3DS authentication, we currently support only the Goods/Service Purchase transaction type.

2. 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 [email protected] or your designated VGS implementation representative to have this feature activated.

   • 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).

3. Merchant Information:

• Overview

  • To perform 3D Secure (3DS) authentication through VGS, you must supply specific merchant_info values in the API request that identify the merchant to the card networks. This information is provided during acquirer onboarding and ensures that authentication requests are correctly recognized by issuers and aligned with your specific transaction processing setup.

  • The core requirement is to maintain precise alignment across the transaction lifecycle. The merchant_info values provided in the 3DS authentication request must match exactly with the acquirer and network identifiers you will use for the subsequent authorization of that transaction.

  • For example, if you generate a 3DS authentication cryptogram (CAVV) using a specific acquirer_bin and acquirer_merchant_id, the CAVV created will work only with that specific acquirer. Therefore, you must submit that resulting cryptogram for authorization through that exact same acquiring entity. Mismatched identifiers between the 3DS authentication step and the final authorization step for transaction processing can lead to declined transactions or liability disputes.

• Multi-Acquirer Merchants

  • Merchants often choose to process their transactions through different acquirers based on factors like card network, region, or currency to optimize costs and approval rates. Consequently, critical identifiers like acquirer_bin and acquirer_merchant_id (MID) can vary per transaction.

  • Because these values can change at a transaction level, your system must dynamically populate the merchant_info blob in the 3DS request to specify exactly which acquirer identifiers will be used for the final authorization. Ensure your system selects the correct information based on:

    • The merchant account

    • The acquirer designated for transaction processing

    • The card network being authenticated

  • This ensures that each authentication request matches the values used later during the authorization.

• What You Need to Collect from Your Acquirer

  • Each merchant must provide the following values for every card network they process. These fields map directly to the merchant_info object in the VGS 3DS Authenticate API. These values are required because issuers validate the merchant identity as part of 3DS processing. Using incorrect values can lead to authentication failures.

VGS Field Name	Description
acquirer_bin	The network-assigned identifier for the acquirer. Acquirer BIN should be used consistently for both authentication and authorization flows.
acquirer_merchant_id	Unique merchant identifier (MID) registered with the acquirer for that network.
acquirer_country_code	Acquirer’s registered country (ISO 3166 alpha-3 format, e.g., "USA").
category_code	Merchant Category Code (MCC). Four-digit business category classification.
name	Merchant's official business name as registered with the acquirer.
country_code	Merchant's registered country (ISO 3166 alpha-3 format).
website_url	Merchant's official website URL.

• Some networks require extra data fields within the merchant_info object.

Card Network	Field Name	Requirement
American Express & Discover	acquirer_requestor_id	Required
	acquirer_requestor_name	Required
Visa & Mastercard (Production)	acquirer_requestor_id	Optional
	acquirer_requestor_name	Optional

1. 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

   • The Sandbox uses a simplified, network-agnostic configuration for testing. All fields within merchant_info are required. Fixed, static values are provided for testing and must be used for all Sandbox transactions.

Use this link to start your integration and testing. Please contact [email protected] or your designated VGS implementation representative to begin the onboarding process and have this feature activated.

Go-Live:

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

2. 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.

3. 3DS Flow Test: Run at least one successful challenge and frictionless flow tests per scheme (Visa, Mastercard, etc.). Each scheme must be tested separately;

4. 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.