Skip to main content

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

​
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). 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.
3DS authentication handled on the issuing side3DS authentication handled on the issuing side
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:
For how these events are delivered, how they are wrapped and how to verify their signatures, see Webhook & WebSocket.

​
Do you need 3DS forwarding?

Whether 3DS forwarding is offered in the DeCard-Managed modelIf 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.

​
Next steps