Your fintech app sends a one-time password. WhatsApp delivers it in under three seconds to 87% of your users. The remaining 13% never see the code — they're offline, haven't installed the app, or their carrier blocks the template. Without a fallback, those users abandon the transaction. With a message cascade fallback, the platform automatically reroutes the OTP through RCS, then SMS, within a pre-configured time window. The user authenticates. The transaction closes.
Most CPaaS providers offer multi-channel access. Few handle the cascade logic server-side — deciding when to abandon one channel and fire on the next, confirming delivery at each step, and charging only for the channel that actually worked. That difference separates a channel list from a routing engine. This article breaks down how messaging cascade works at the protocol level, what it costs, and how to configure it through a single API call.
A message cascade is a priority-ordered sequence of delivery channels. When the primary channel fails or times out, the system automatically attempts the next channel in the chain — without requiring a second API call from your backend. The cascade terminates as soon as any channel confirms delivery.
The concept borrows from network engineering: failover routing. In messaging, it means defining a rule like WhatsApp → RCS → SMS and assigning timeout thresholds per channel. If WhatsApp returns a delivery receipt within 30 seconds, the cascade stops. If not, the engine fires the RCS attempt. If RCS times out or the recipient's device lacks support, A2P SMS takes over as the final fallback — the channel that reaches virtually every phone on earth, regardless of OS, app, or data connection.
At BSG, we've seen that teams who implement cascade routing correctly report measurable improvements in two areas simultaneously: delivery rates climb above 99% on transactional messages, and per-message costs drop because the most expensive channel (SMS) is used only when cheaper channels have already failed.
How each channel fits into the cascade:
| Capability | RCS | SMS | |
|---|---|---|---|
| Reach requirement | App + internet | Android + data | Any mobile phone |
| Rich media | Yes | Yes | No |
| Engagement rate | 95–98% open | High (branded) | ~98% open |
| OTP cost per msg | $0.01–$0.04 | $0.0075–$0.015 | $0.05–$0.10+ |
| Cascade position | 1st (preferred) | 2nd (middle tier) | 3rd (terminal) |
Choosing one channel and routing all traffic through it looks simple on a whiteboard. In production, it creates two distinct failure modes that compound as your user base grows.
SMS reaches every mobile phone, with no app dependency and no data requirement. That universality comes at a cost. The global average A2P international termination rate hit $0.10 per message in Q1 2025 — the first time the global average crossed that threshold (Mobilesquared, 2025). In high-cost markets like Germany, France, and the Netherlands, A2P SMS rates run significantly higher. When you're sending 500,000 OTPs per month, even a $0.02 per-message saving across half your traffic translates to $5,000/month recaptured.
SMS also carries character limits. A single OTP message fits inside 160 characters, but marketing messages with links and product details often concatenate into two or three segments — doubling or tripling the cost per send.
WhatsApp messages achieve open rates that consistently outperform email by a wide margin — industry reports cite 95–98% visibility (Infobip, 2026). Since July 2025, Meta charges per delivered template message rather than per conversation window, with authentication message rates starting at $0.0135 in the US and as low as $0.004 for utility templates (Meta Developer Documentation, 2026). That's often cheaper than SMS for the same destination.
The problem: WhatsApp requires both an internet connection and the app itself. In markets with unreliable mobile data coverage — parts of Sub-Saharan Africa, Southeast Asia, rural Latin America — a meaningful share of your user base will not receive a WhatsApp message at the moment it matters most. For OTP delivery, a three-second delay is tolerable; a permanent non-delivery is a lost customer.
In our experience working with fintech and eCommerce clients across Africa and Southeast Asia, WhatsApp-only OTP flows show delivery gaps of 8–15% in low-connectivity regions. Adding SMS as a fallback closes that gap almost entirely.
BSG's cascade engine runs server-side, inside the routing layer. Your application sends one API request. The engine handles channel selection, timing, delivery confirmation, and billing — all before returning the final status to your webhook. Here's how each component operates.
The default priority chain is WhatsApp → RCS messaging → SMS, but the sequence is fully configurable per message type. For OTP traffic, you might prioritize WhatsApp → SMS (skipping RCS, which lacks universal OTP template support in some markets). For marketing broadcasts, the chain might start with RCS (rich media, verified sender, no app install) and fall back to Viber, then SMS.
Based on what we observe across the campaigns we support, the WA → RCS → SMS chain works best for transactional messages where speed and reliability both matter. For promotional use cases, clients often place RCS first because its rich media capabilities drive higher click-through rates than plain SMS, while still reaching Android users without an app install requirement.
Each channel in the cascade gets a configurable timeout window. The default is 30 seconds. If the delivery reporting does not arrive within that window, the engine moves to the next channel. You can adjust the timeout per channel: shorten it to 15 seconds for OTPs (where speed is critical) or extend it to 60 seconds for marketing messages (where a slightly delayed delivery is acceptable).
The timing logic matters more than most teams realize. Too aggressive (5 seconds) and you trigger unnecessary fallbacks — the user gets the WhatsApp message at second 7 and the SMS at second 6. Too generous (120 seconds) and the OTP expires before the fallback fires. We've worked with teams who tried 10-second windows and found 25–30 seconds delivered the best balance between speed and cost.
The cascade engine tracks delivery status at every step. When WhatsApp returns a "delivered" receipt, the engine marks the message as complete and does not fire the RCS Business Messaging or SMS leg. You are billed only for the channel that delivered the message. If WhatsApp returns "sent but not delivered" within the timeout, the engine fires the next channel. Your webhook receives a unified status object showing the full cascade path and which channel ultimately delivered.
This per-step confirmation is what separates a true cascade from a "multi-channel blast" — where all channels fire simultaneously and you pay for all of them regardless of which one the user actually reads.
Consider a SaaS platform sending 200,000 OTPs per month to a mixed audience across Europe and Latin America. Under an SMS-only model, at an average rate of $0.06 per message, the monthly OTP bill is $12,000. With a WA → SMS cascade, roughly 70–80% of those OTPs deliver via WhatsApp at an authentication rate of approximately $0.01–$0.04 per message (Meta Developer Documentation, 2026). Only 20–30% fall back to SMS.
The result: the same 200,000 OTPs cost between $7,200 and $9,600 per month — a 20–40% reduction depending on the destination mix. For the businesses we work with in high-volume OTP markets, this saving compounds month over month. Over a year, a platform sending 2.4 million OTPs recaptures $28,000–$57,000.
SMS-only vs. cascade: cost comparison for 200K OTPs per month:
| Metric | SMS-Only | WA → SMS Cascade |
|---|---|---|
| Monthly OTP volume | 200,000 | 200,000 |
| Primary channel rate | $0.06 (SMS) | $0.01–$0.04 (WA) |
| Fallback rate | N/A | $0.06 (SMS) |
| % via primary channel | 100% | 70–80% |
| Monthly cost | $12,000 | $7,200–$9,600 |
| Annual saving | $0 | $28,000–$57,000 |
For marketing and promotional traffic, the cost story is different. WhatsApp marketing templates are more expensive per message than SMS in some markets (for instance, $0.0625 per marketing message in Brazil). But the engagement difference changes the ROI math entirely. WhatsApp messages achieve click-through rates of 40–60%, compared to SMS's typical 5–15% (Infobip, 2026).
A cascade that starts with WhatsApp for a promotional campaign doesn't just save money — it generates more revenue per send. The SMS fallback catches the 10–15% of users who can't be reached on WhatsApp, ensuring no audience segment is abandoned. What our clients have found is that adding RCS as the middle tier for marketing increases overall campaign engagement by 10–18% compared to a direct WA → SMS cascade, because RCS's interactive elements (carousels, buttons, verified sender) outperform plain SMS for users who receive it.
The cascade is configured at the API request level. You do not need to build retry logic, manage webhook listeners for each channel separately, or write conditional routing code. BSG One API handles it.
A simplified request body for a cascaded OTP delivery:
{
"to": "+4915112345678",
"message": "Your verification code: 482901",
"cascade": {
"channels": ["whatsapp", "rcs", "sms"],
"timeout_sec": 30,
"callback_url": "https://your-app.com/dlr"
}
}The `channels` array defines the priority order. The `timeout_sec` field sets the per-channel window. The `callback_url` receives the final delivery status, including which channel delivered and the full cascade path. If you need different timeout values per channel, pass an array of objects instead: `[{"channel": "whatsapp", "timeout": 25}, {"channel": "rcs", "timeout": 20}, {"channel": "sms"}]`. SMS, as the terminal fallback, does not require a timeout.
Integration typically takes less than a day. If you already send Bulk SMS through BSG, you have the API credentials and webhook infrastructure in place. Adding cascade is a configuration change, not a re-architecture.
OTP and 2FA. The highest-stakes use case. A failed OTP delivery means a failed login, a failed transaction, or a lost customer. Cascade routing ensures the code reaches the user regardless of their channel availability. BSG's 2FA solution supports WhatsApp, SMS, voice, email, and Telegram as cascade channels. For a fintech client processing KYC verifications across Nigeria, Kenya, and the Philippines, switching from SMS-only to a WA → SMS cascade reduced OTP delivery failures from 11% to under 2%, while cutting per-OTP cost by approximately 30%.
Transactional notifications. Order confirmations, shipping updates, appointment reminders — messages that the recipient expects and needs. Starting with WhatsApp (where the message is richer, with tracking links and buttons) and falling back to SMS (where it's still actionable, just text-only) gives the best combination of experience and reach.
Marketing broadcasts. A product launch campaign can start with RCS (rich cards, branded sender, no app install for Android users), fall back to WhatsApp (interactive buttons, product images), and terminate at SMS (short text with a tracked link via BSG Short URL). This three-tier cascade maximizes both reach and engagement, and you only pay for the channel that connects.
If your OTP delivery costs are climbing or your transactional messages are hitting delivery gaps in specific markets, a message cascade fallback is likely the fix. BSG's cascade engine runs inside the routing layer — one API call configures the priority chain, timeout windows, and delivery confirmation logic. There is no additional SDK, no client-side code, no separate webhook for each channel.
Talk to BSG's team about configuring your cascade. We'll map your traffic, recommend the optimal channel priority for your markets, and get you live within a day.
The core content stays the same, but the format adapts to each channel's capabilities. An OTP code is identical across WhatsApp, RCS, and SMS. A marketing message may include a carousel on RCS, a button on WhatsApp, and a shortened URL on SMS. BSG's cascade engine handles the format mapping per channel automatically.
You are billed only for the channel that successfully delivers the message. If WhatsApp delivers within the timeout, you pay only the WhatsApp rate. If WhatsApp times out and SMS delivers, you pay only the SMS rate. You are never charged for both channels on the same message.
Yes. The BSG One API accepts per-channel timeout configuration. For OTP use cases, teams typically set 20–25 seconds for WhatsApp and 15–20 seconds for RCS, with SMS as the terminal fallback (no timeout needed). For marketing, longer windows — 45–60 seconds per channel — reduce unnecessary fallbacks without impacting urgency.
If all channels exhaust their attempts, the callback returns a "failed" status with the reason per channel (timeout, number not on WhatsApp, RCS not supported, SMS delivery error). Your application can then handle the failure — retry, route to voice OTP, or notify the user to try again.
Not every purchase intent pulls through. Customers often back out of the buying process and
Human activities and interactions are rapidly happening online. The digital space offers convenience and quick
In today’s fast-paced cybersecurity landscape, large enterprises confront a constant barrage of threats to their
