> ## Documentation Index > Fetch the complete documentation index at: https://docs.anglpay.com/llms.txt > Use this file to discover all available pages before exploring further. # 3-D Secure with multiple connections > Learn how 3-D Secure works when a transaction can be routed to more than one connection, and how to set up 3DS configurations for multiple acquirers. Many merchants route card transactions to more than one connection, for example to fail over when a connection is down or to use different acquirers per currency. This page explains how 3-D Secure (3DS) behaves in those setups, and how to set up your [3DS configurations](./setup) to match. ## How 3DS works across connections A [Flow routing rule](/guides/dashboard/flow/card-transactions#action-route-to-connection) can list more than one connection. Gr4vy tries each connection in order, and moves on to the next one after a [failure or retriable decline](/guides/dashboard/flow/card-transactions#failures-and-retriable-declines). 3DS runs at most once per transaction: 1. Gr4vy authenticates the card on the first connection in the list that has 3DS turned on. It uses the acquirer details of the scheme profile or merchant account configuration that [matches the transaction](./setup#scheme-profile-resolution). 2. The connection authorizes the transaction with the 3DS result. 3. If the transaction is retried on the next connection, Gr4vy sends the same 3DS result to that connection. The buyer isn't authenticated again. Some details affect which connections receive the 3DS result: * Connections that can't accept 3DS data from Gr4vy are skipped once a transaction has a 3DS result. * If a retry uses a different card scheme, for example with [co-badged routing](/guides/dashboard/flow/card-transactions#co-badged-routing), the 3DS result isn't sent. The result is only valid for the scheme it was created for. * If 3DS fails, the transaction isn't retried on another connection. [Native 3DS](./native) and [Click to Pay](/guides/features/click-to-pay/tas) work the same way. They authenticate before a connection is chosen, and the same rules decide which connections receive the result. ### Connections that run their own 3DS Some payment services run 3DS themselves and redirect the buyer to their own page. Once a payment service redirects the buyer, Gr4vy can't retry the transaction on another connection. Connector pages list this as **3-D Secure (provider-hosted)**. ### Connections with 3DS turned off 3DS isn't always run on the first connection. If the first connection in the list has 3DS turned off, Gr4vy sends the transaction there without 3DS. If that connection declines and Gr4vy retries on a connection with 3DS turned on, the buyer is asked to authenticate at that point. To keep the experience consistent, use the same 3DS setting on every connection in a routing rule, or list the connections with 3DS turned on first. ## Liability shift after a retry The 3DS result contains the acquirer details of the configuration that Gr4vy used to authenticate. When a transaction is retried on a connection with a different acquirer, the authorizing acquirer doesn't match those details. Most acquirers accept a 3DS result obtained with the details of another acquirer, and pass it on to the issuer. However, liability shift isn't guaranteed in this case. It depends on the acquirer and the card scheme rules. This is a trade-off between two risks: * **Without failover**, a transaction fails when its connection is unavailable. * **With failover**, a transaction can still succeed, but may lose liability shift when it's authorized by a different acquirer. Most merchants prefer to keep failover and accept the risk of losing liability shift on those transactions. If liability shift matters more than acceptance for some transactions, don't route them to connections with a different acquirer. ## Setting up 3DS configurations for multiple acquirers A merchant account configuration isn't linked to a connection. Gr4vy picks it based on the card scheme, currency, and metadata of the transaction only. See [matching a merchant account configuration](./setup#matching-a-merchant-account-level-configuration) for the full rules. Use the pattern that fits how you split transactions between acquirers. ### One acquirer for all transactions Add one configuration per card scheme, for all currencies, with empty metadata. This is the simplest setup, and it also covers failover connections. ### Different acquirers per currency Add one configuration per card scheme and currency, with the details of the acquirer for that currency. Route each currency to the matching connection with a Flow rule. Gr4vy picks the configuration for the transaction's currency automatically. Optionally, add a configuration for all currencies as a fallback. Configurations for a specific currency are always picked before it. ### Different acquirers per card scheme Each configuration already belongs to one card scheme. Add each scheme's configuration with the details of the acquirer that processes that scheme, and route each scheme to the matching connection with a Flow rule. ### Choosing the acquirer per transaction If your own system decides which acquirer processes each transaction, send that choice as transaction `metadata`. Use the same key and value in both places: * A [Flow routing rule](/guides/dashboard/flow/card-transactions#conditions) with a metadata condition that routes the transaction to the connection for that acquirer. * A 3DS configuration with the same metadata and the details of that acquirer. For example, a transaction with the following metadata matches both a routing rule and a 3DS configuration that use `"acquirer": "acquirer-b"`. ```json theme={"system"} { "metadata": { "acquirer": "acquirer-b" } } ``` Gr4vy doesn't check that the routing rule and the 3DS configuration agree, so keep them in sync when you change either one. For [native 3DS](./native) and [Click to Pay](/guides/features/click-to-pay/tas), set the metadata on the checkout session. A configuration with empty metadata for the same scheme and currency is picked before a newer configuration with metadata. See [choosing between matching configurations](./setup#choosing-between-matching-configurations). ### Many acquirers or merchant IDs in one account Avoid setting up many connections with different acquirer merchant IDs in a single merchant account. Features like [split routing](/guides/dashboard/flow/card-transactions#split-routing-condition) and failover can send a transaction to any of those connections, but the 3DS configuration can only match one acquirer. This makes it hard to predict which acquirer details are used. Instead, use a separate [merchant account](/guides/features/merchant-accounts/overview) for each set of acquirer details. Each merchant account has its own connections, Flow rules, and 3DS configurations. If your account doesn't have multiple merchant accounts enabled, contact your account manager.