Introducing Voice OTP and Multi-Channel Fallback in D7 Verify

When an OTP Doesn't Arrive

A user enters their phone number, requests a verification code and waits. If the code doesn't arrive, they may request another one, leave the process or try again later. For a business, that creates friction at a point where the user is trying to complete an important action.

SMS and WhatsApp are common ways to deliver OTPs, but a verification workflow doesn't always need to depend on a single channel.

D7 Verify is introducing Voice OTP and multi-channel fallback, giving businesses another way to deliver verification codes and more control over what happens when the primary channel fails. Voice OTP delivers the code through a phone call using text-to-speech, while multi-channel fallback can move the attempt to another configured channel under the supported fallback conditions.

Voice OTP: Deliver Codes Through a Phone Call

Voice OTP lets users receive their verification code through a voice call instead of a text message. D7 uses text-to-speech (TTS) to read the code aloud. The user enters that code in the application, and the Verify API validates it.

Voice is an additional delivery channel within D7 Verify, rather than a separate verification integration. Businesses can enable it and configure its priority within the supported channel configuration.

This gives developers another option when designing verification workflows. Depending on the configured flow, Voice can be the selected channel or an alternative used through fallback.

Multi-Channel Fallback: What Happens When the First Channel Fails?

Multi-channel fallback allows a verification workflow to move to another configured channel when delivery through the primary channel fails.

For example, a business could configure SMS as the first channel and Voice as the alternative. If the SMS attempt meets the product's fallback condition, D7 Verify can move to the configured Voice channel. WhatsApp may also be used in the channel order where supported.

The business can configure the preferred channel priority, determining which channel is attempted first and which alternatives follow. Fallback depends on the configured workflow and the system's delivery-failure handling; it should not be understood as a guarantee that every OTP will reach its recipient.

Consider a customer registering for an online service. The application requests an OTP, and the configured verification flow attempts to deliver it through SMS first.

If delivery fails under the configured fallback rules, D7 Verify can try the next channel in the priority order.

For example:

User requests an OTP

Primary channel: SMS

Delivery fails under configured rules

Fallback channel: Voice

Illustrative flow. Actual channel order and fallback behavior depend on the supported configuration.

The same principle applies when other supported channels are configured. A business can define its preferred order rather than relying on one fixed channel for every verification attempt.

This gives product teams more control over verification delivery without requiring them to build a separate application-level workflow for every channel.

Different businesses have different verification requirements. A service may prefer SMS as its primary channel, while another may prioritize WhatsApp for its users.

Configurable channel priority lets businesses decide which supported channel should be tried first and which alternatives should follow.

When setting up a verification flow, teams should consider:

• Which channels are supported for their intended destinations.
• Which channel should be the primary option.
• Which alternative channels should be used if delivery fails.
• How channel-specific costs affect the overall verification process.

The appropriate configuration depends on the application's requirements, the available channels, and the expected user experience.

Using multiple channels also makes it important to understand how verification attempts are charged.

D7 Verify uses channel-based billing: each attempt is charged according to the channel used. If an OTP attempt falls back to Voice, the Voice attempt is charged according to the applicable Voice pricing.

For example, if a verification attempt starts with SMS and subsequently uses Voice through fallback, the charges reflect the respective channels used. The exact cost depends on the applicable pricing.

Businesses should review current rates before configuring their verification workflows. Understanding the billing model helps teams choose a channel priority that suits both their users and their budgets.

When a verification attempt moves between channels, knowing which channel was used provides useful operational context.

D7 Verify analytics include channel and fallback information. This allows teams to review which channel was used for an OTP and how often fallback was triggered.

These details can help developers and product teams understand how their configured verification workflows are being used. They can also provide context when reviewing delivery issues or deciding whether a channel configuration needs to be adjusted.

D7 Verify uses a flow-based API. Developers configure a verification flow and then use the flow ID when requesting an OTP. The flow holds settings such as the channel, message content, OTP type, code length, expiry and retry options.

To explore the integration:

• Read the D7 Verify API documentation for the API workflow and supported operations.
• Follow the Getting Started guide to understand the setup process.
• Visit the D7 OTP Verification API page for an overview of the service.

Before implementation, confirm the availability of Voice OTP, the supported channel combinations, fallback conditions and applicable pricing for your account.

Voice OTP adds another way for users to receive verification codes, while multi-channel fallback lets businesses configure what happens when their primary delivery channel fails.

Together, these capabilities give developers more flexibility in designing OTP verification workflows, with configurable channel priority, visibility into channel usage and billing based on the channel used.

Explore D7 Verify to see how these capabilities fit your application's verification requirements.