# 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*](https://www.emvco.com/emv-technologies/3-d-secure/) *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. **Challenge Flow:**\ When a transaction requires step-up authentication, cardholders may be challenged by their issuing bank using methods such as OTP, mobile banking approval, or biometrics. Challenge flows are supported across **Visa, Mastercard, American Express, and Discover**. **Data Sharing (Data-Only Authentication):**\ The data sharing authentication flow allows merchants to send transaction and device data to issuers without triggering a cardholder challenge. This capability is currently supported for **Visa and Mastercard transactions only**. #### 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. VGS does not provide a 3DS mobile SDK currently. 3. **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 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:read` and `3ds:write` scope (in addition to `cards:read` and `cards:write`). 4. **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 NameDescription
acquirer_binThe network-assigned identifier for the acquirer. Acquirer BIN should be used consistently for both authentication and authorization flows.
acquirer_merchant_idUnique merchant identifier (MID) registered with the acquirer for that network.
acquirer_country_codeAcquirer’s registered country (ISO 3166 alpha-3 format, e.g., "USA").
category_codeMerchant Category Code (MCC). Four-digit business category classification.
nameMerchant's official business name as registered with the acquirer.
country_codeMerchant's registered country (ISO 3166 alpha-3 format).
website_urlMerchant'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 | #### Requestor Identifier Guidance per Network * **For Visa and Mastercard**, `acquirer_requestor_id` and `acquirer_requestor_name` are optional fields. These fields do not need to be sent in the authentication request. However, if you choose to send them, VGS supports the following format: * `acquirer_requestor_id = ENT_VGS_` * `acquirer_requestor_name = VGS_` * Please reach out to your VGS representative to obtain your CMP account ID. * **For American Express and Discover**, `acquirer_requestor_id` and `acquirer_requestor_name` are required fields. * **For American Express**, `acquirer_requestor_id` must be the scheme- or registration-specific requestor identifier associated with the merchant or entity for 3DS processing. This value depends on how the entity is registered for 3DS, such as merchant, aggregator, or another supported registration model. This value should not be generated arbitrarily. * **For Discover**, `acquirer_requestor_id` must be the registered requestor identifier associated with the merchant or entity under the acquirer for Discover 3DS processing. This value is received or coordinated during onboarding or registration and should not be generated arbitrarily. * **For both American Express and Discover**, `acquirer_requestor_name` can use the following format: * `acquirer_requestor_name = VGS_` * These values may also be referred to by the **card networks or 3DS providers** as `threeDSRequestorID` and `threeDSRequestorName`. #### 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. {% hint style="info" %} Use [this link](https://docs.verygoodsecurity.com/cmp/developer-resources/guides/testing/3ds) to start your integration and testing. Please contact or your designated VGS implementation representative to begin the onboarding process and have this feature activated. {% endhint %} #### **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. 1. VGS does not provide production test cards for 3DS validation. Any 3DS validation in production must be performed using real cards in live transactions. Before rolling out new `acquirer_requestor_id` or `acquirer_requestor_name` values broadly in production, validate the configuration with a production transaction. 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.