Implement OOB flow (issuer authentication)

Overview

The 3DS OOB flow with issuer authentication is used when your rules decide to challenge a transaction and your issuer backend is configured to authenticate the end user in the issuer application.

To control when OOB challenges are triggered, configure thresholds and conditions in Configure rulesets for 3DS decisioning.

User experience

Flow

High‑level OOB with issuer authentication flow - Step 1.

High‑level OOB with issuer authentication flow - Step 2.

Sequence diagram

Prerequisites

• Card products are configured in the D1 backend and in the payment network directory server.

• The end user and the card are registered in the D1 backend .

1 - AReq/ARes

Authentication request and response flow.

2 - CReq/CRes and OOB challenge from issuer

D1 triggers the issuer authentication by API.

3 - Final CReq/CRes and notification

D1 gets the authentication result and ends the 3DS flow.

Backend integration

When the 3DS decision requires an OOB challenge, your issuer backend is asked to authenticate the end user:

1. Receive the authentication request: the D1 backend calls your backend via the Authenticate request.

2. Trigger issuer authentication: start your ID&V flow in the issuer application (for example, push notification + CDCVM/biometrics, or any supported SCA method).

3. Expose the result: provide the outcome through Get Authentication Result so the 3DS challenge can complete.

4. Receive the final notification: at the end of the flow, you are informed about the authentication details via Notify 3DS Card Operation.

Best practices

• Keep the OOB authentication responsive (push within seconds) to minimize challenge timeouts.

• Surface clear approve/deny choices in the issuer application and map them deterministically to the result you return.