> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thedecard.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 3DS Strong Authentication

> How 3DS strong authentication works in the DeCard-Managed model: DCS closes the loop directly with the card network, 3DS challenges are not forwarded to the partner, and the partner has no 3DS integration work to do.

## DCS handles 3DS directly on the issuer side

In the DeCard-Managed model, 3DS strong authentication is handled directly between DCS and the card network: generating, delivering and verifying the code all happen on the issuer side, so you have no 3DS integration work at all. As a licensed issuer running its own BINs, DCS takes on the issuer's authentication duties and absorbs this extra strong-authentication step in the online payment path on your behalf.

This page explains how 3DS is handled in the DeCard-Managed model and what the partner does, or does not, need to do.

<Note>
  The DeCard-Managed model currently **does not forward 3DS challenges to the partner**; there is no capability for handing an OTP or challenge to the partner over a webhook for delivery. If your business genuinely requires the partner to deliver the 3DS code or to guide the user through authentication inside its own app, raise it with the DCS team: that capability already exists in the other integration model, Partner-Managed.
</Note>

## What Three-Domain Secure (3DS) is

3DS (Three-Domain Secure, 3D Secure) is the security protocol used in online payments to verify the cardholder's identity, adding an extra verification step to the payment flow based on the risk of the transaction.

* Lower-risk transactions can be let through **frictionlessly**.
* Higher-risk transactions, such as large payments, or transactions where the merchant asks for it, trigger a **challenge**: the cardholder has to confirm their identity, typically with a one-time password (OTP), before the transaction can continue.

This extra step is how 3DS confirms cardholder identity and reduces fraud.

## How 3DS works in the DeCard-Managed model

In the **DeCard-Managed** model, authorization decisions are made **inside DCS** and act on the user's own balance (see [Authorizing Transactions](./authorizing-transactions)). Consistently with that, **3DS strong authentication is currently handled directly between DCS and the card network** and is not forwarded to the partner:

1. The cardholder pays with the card at a merchant.
2. The merchant sends a 3DS authentication request to the card network.
3. The card network (Visa, for example) routes the authentication request to DCS as the issuer.
4. DCS triggers the authentication step and delivers a one-time password (OTP) to the cardholder.
5. The cardholder enters the code in the authentication iFrame displayed by the merchant.
6. DCS returns the authentication result to the card network and the transaction continues.

<Frame>
  <img className="block dark:hidden" src="https://mintcdn.com/dcs-0bf7a937/oUoeUKtwWWK2o-Li/imgs/en/diagrams/va-3ds-flow-light.svg?fit=max&auto=format&n=oUoeUKtwWWK2o-Li&q=85&s=3720a10b7988922c21d8532e8521adfd" alt="3DS authentication handled on the issuing side" width="656" height="390" data-path="imgs/en/diagrams/va-3ds-flow-light.svg" />

  <img className="hidden dark:block" src="https://mintcdn.com/dcs-0bf7a937/oUoeUKtwWWK2o-Li/imgs/en/diagrams/va-3ds-flow-dark.svg?fit=max&auto=format&n=oUoeUKtwWWK2o-Li&q=85&s=8f8a3fbb583de364f82c79c848622310" alt="3DS authentication handled on the issuing side" width="656" height="390" data-path="imgs/en/diagrams/va-3ds-flow-dark.svg" />
</Frame>

> In this setup, **the partner has no 3DS integration work to do**: DCS generates, delivers and verifies the code on the issuer side, and **no 3DS challenge webhook is sent to the partner**.

## About 3DS forwarding (passing the code to the partner)

"3DS forwarding" means passing the OTP and challenge details **to the partner** over a webhook, so that the partner controls the last mile of delivery through its own channels, such as SMS, email or WhatsApp.

**The DeCard-Managed model does not currently offer this capability**, which means:

* This page **does not cover** the fields of a 3DS challenge webhook, the `flowsType` modes (`OTP_DELEGATE` / `OOB`) or a result callback endpoint. In the DeCard-Managed model, 3DS authentication is closed out on the issuer side and nothing is handed to the partner.
* If your business genuinely needs the partner to deliver the 3DS code or to guide the user through authentication inside its own app, raise it with the DCS team. That capability already exists in the other integration model, Partner-Managed.

## DeCard-Managed webhook events (and where 3DS fits)

For reference, these are the webhook event types the DeCard-Managed model currently sends. **None of them is a 3DS challenge event**:

| Event type `type`             | Meaning                                 |
| ----------------------------- | --------------------------------------- |
| `BALANCE_CHANGE`              | Digital asset or balance movement       |
| `CARD_TRANSACTION`            | Card transaction (authorization) record |
| `CARD_TRANSACTION_SETTLEMENT` | Card settlement record                  |
| `CARD_PHYSICAL_SHIPPING`      | Physical card shipping information      |
| `ORDER_STATUS`                | Top-up (FOMO) order status              |
| `QR_ORDER_STATUS`             | QR Pay order status                     |
| `CARD_APPLY`                  | Card application status                 |
| `CARD_STATUS`                 | Card status change                      |

> For how these events are delivered, how they are wrapped and how to verify their signatures, see [Webhook & WebSocket](../../integration-resources/webhook-websocket).

## Do you need 3DS forwarding?

<Warning>
  **Whether 3DS forwarding is offered in the DeCard-Managed model**

  If you need 3DS challenges (OTP or OOB) forwarded to you over a webhook so that you can deliver them through your own channels, **raise it with the DCS team**. The capability already exists in the other integration model, Partner-Managed, including both the `OTP_DELEGATE` and `OOB` modes and the result callback endpoint.
</Warning>

## Next steps

* How authorization is completed inside DCS: [Authorizing Transactions](./authorizing-transactions)
* The full authorization mechanism (sequences, authType, fields): [Authorization (handled inside DCS)](./authorizing-transactions)
* Receiving transaction and balance notifications: [Webhook & WebSocket](../../integration-resources/webhook-websocket)