Implement SMS OTP flow

Overview

When a 3DS transaction is challenged and the OOB flow is unavailable, the D1 3DS service falls back to the SMS OTP challenge.

User experience

Flow

The following diagrams summarize the SMS OTP flow when OOB is not available.

High‑level flow overview - step 1.

High‑level flow overview - step 2.

Sequence diagram

Prerequisites

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

• The end user and card are registered in D1.

1 - AReq/ARes

Authentication request/response (AReq/ARes).

2 - OTP challenge

OTP generation, delivery, and validation.

3 - Final CReq/CRes and notification

Final challenge request/response (CReq/CRes) and outcome notification.

Backend integration

There are two ways to deliver the OTP:

1. D1 sends the SMS to the end user

   • The D1 backend uses the end user’s phone number provided by the issuer backend during registration.

   • D1 generates the OTP and delivers it by SMS.

2. Issuer backend sends the SMS to the end user

   • D1 generates the OTP and delivers it to the issuer backend via the DeliverOTP operation.

   • The issuer backend is responsible for sending the SMS to the end user.

   • For request/response details, see the D1 API reference.

Operational considerations:

• OTP format and TTL (expiry), maximum attempts, resend limits

• Localization of SMS content and sender ID

• Delivery provider retries/fallbacks and delivery status tracking

• Avoid logging OTP values and sanitize PII

• Rate‑limit OTP requests to mitigate abuse