- RCS fallback to SMS is not automatic on every platform. Some providers require you to configure it explicitly, and a misconfigured waterfall silently drops messages rather than delivering them as SMS.
- Billing logic varies sharply: some providers charge for both the failed RCS attempt and the SMS fallback, effectively doubling your per-message cost on non-RCS devices.
- Per-carrier delivery data is a feature gap. Most platforms report aggregate delivery status. Only a handful expose carrier-level breakdowns that let you diagnose why fallback fired.
- WhatsApp-first waterfalls (WhatsApp then RCS then SMS) are technically possible on a few CPaaS platforms, but they require separate sender registration and are not a single toggle.
- The RCS capability check happens before send on well-architected platforms. On poorly-architected ones, it happens at delivery time, which means the fallback delay can push a time-sensitive message outside its conversion window.
RCS fallback to SMS is the mechanism that automatically sends a standard SMS when RCS delivery is not possible, whether because the recipient’s device does not support RCS, their carrier has not enabled it, or they lack a data connection at send time. The RCS SMS fallback path is where billing, latency, and reporting gaps actually surface , and US providers handle it differently enough to matter. Some check RCS capability before sending and route accordingly, others attempt RCS first and fall back on failure, and a few do not offer automatic fallback at all. Billing, reporting depth, and waterfall configuration options differ enough between platforms that choosing the wrong one can double message costs or leave you blind to delivery failures.
Why Fallback Logic Matters More Than Your Provider’s Marketing Suggests
Most platform marketing treats RCS fallback as a solved problem, a checkbox buried in a features page. It is not. The mechanics of when a provider checks for RCS capability, what it does on a failure, and whether it bills you for both attempts determine your actual cost per delivered message and your actual delivery rate.
There are two fundamentally different architectures: pre-send capability checks and post-attempt fallback. A pre-send check queries a carrier lookup or operator database before the message is dispatched, routes to RCS if capable, and routes directly to SMS if not. Post-attempt fallback sends RCS first, waits for a failure signal, then sends SMS. Post-attempt fallback introduces latency. For a flash sale with a 30-minute window, a 60-to-90-second fallback delay can mean the message arrives after the offer expires.
The second variable is what triggers the fallback. Device incapability is obvious, but carrier-level RCS unavailability is less so. A recipient might have an RCS-capable Android device on a carrier that has not provisioned RCS for their account tier, or their phone may be temporarily on a network segment without RCS routing. If your provider does not distinguish between these conditions, you cannot diagnose delivery failures or improve your routing logic over time. The RCS business messaging platforms overview covers sender setup in detail; this article focuses on what happens after the message leaves your platform.
The AboutMartech Fallback Audit: Four Checks Before You Commit to a Provider
Evaluating a provider’s fallback implementation comes down to four specific questions. Together, they form what we call the AboutMartech Fallback Audit, a repeatable set of checks that surfaces the operational and financial risk before you sign a contract.
Check 1: Pre-send or post-attempt capability detection?
Ask the provider whether their RCS capability check happens before the send or at delivery time. Pre-send routing means no wasted RCS attempt on a non-capable device. Post-attempt means you may wait for a timeout before the SMS fires. The answer changes your effective send speed and, on high-volume sends, your cost.
Check 2: Dual-billing or single-billing on fallback?
Some providers charge an RCS message rate for the failed RCS attempt and a separate SMS rate for the successful fallback. Others charge only for the channel that delivered. Get this in writing. On a list where 30 percent of recipients are on non-RCS devices, dual-billing at standard rates can add meaningful cost at volume.
Check 3: What granularity does the delivery report expose?
Aggregate delivered/failed is not enough. You need to know how many messages fell back, to which carrier, and why. Providers that expose carrier-level data let you track whether T-Mobile RCS delivery rates are declining, whether Verizon subscribers are falling back disproportionately, and whether a specific handset model is triggering failures. Without that, you are managing a black box.
Check 4: Is WhatsApp included in the waterfall, and how is it sequenced?
If you want a WhatsApp-then-RCS-then-SMS waterfall, confirm whether the platform supports all three channels natively or whether it requires third-party integrations. A native waterfall means the platform manages the preference logic and billing in one place. A stitched integration means you manage it yourself, with the error surface that implies.
How Does RCS Fallback to SMS Actually Work at the Carrier Level?
RCS over IP uses the Jibe platform for carriers running Google’s hosted RCS infrastructure, or carrier-native RCS cores for operators running their own. When your CPaaS platform sends an RCS message, it submits to the carrier’s RCS gateway. The gateway checks whether the destination MSISDN (phone number) has an active RCS profile registered. If no profile exists, the gateway returns a capability failure.
What happens next depends entirely on your provider’s implementation. A well-built platform treats that capability failure as a routing signal and immediately sends the SMS equivalent. A less mature platform may log the failure and require your own code to trigger the SMS send. Some platforms, particularly developer-focused CPaaS tools, expose this as a webhook event that you must handle programmatically. Marketing platforms built for non-technical operators typically abstract this into an automatic fallback toggle.
One condition that catches teams off guard: a recipient may have RCS provisioned but be offline or on a Wi-Fi network that blocks the RCS port. In that case, the RCS message queues but does not deliver. The carrier does not immediately return a failure. Your platform may wait for a configurable expiry window before triggering SMS fallback, or it may never trigger fallback at all if the message eventually delivers as RCS when the device reconnects. This distinction matters for time-sensitive campaigns. Confirm whether your provider lets you set a maximum wait time before fallback fires, and what the default is.
Which US Providers Handle Fallback, and What Do They Actually Expose?
The US RCS provider market divides into three categories: CPaaS platforms with developer APIs, marketing automation platforms with managed RCS senders, and carrier-direct connections. Each handles fallback and reporting differently.
CPaaS platforms: Twilio, Sinch, Vonage, Bandwidth
Twilio offers RCS via its Messaging API with SMS fallback configurable at the message level. Twilio’s implementation uses a pre-send capability check against its carrier database. Fallback fires automatically if the check returns non-capable, and Twilio charges only for the channel that sends. Delivery webhooks include a channel indicator, so you can identify which messages fell back. Carrier-level breakdowns require pulling logs and segmenting by the recipient’s number prefix, which you have to do yourself. Twilio does not surface a native per-carrier dashboard.
Sinch acquired MessageBird and runs RCS through its Conversation API, which supports channel prioritization including WhatsApp, RCS, and SMS in a configurable waterfall. Sinch’s Conversation API charges per conversation on WhatsApp and per message on RCS and SMS, so dual-billing risk exists if the RCS attempt registers before fallback fires. Sinch’s reporting console shows channel-level delivery data, but carrier-level granularity is not part of the standard dashboard. For the comparison between Twilio and Sinch’s RCS implementations specifically, the Twilio vs Sinch RCS breakdown covers API depth and pricing structure in detail.
Vonage (now part of Ericsson) handles RCS through its Messages API with fallback to SMS. The platform supports automatic fallback but the capability check timing varies by carrier integration. Vonage’s reporting is more limited than Twilio’s at the raw API level, though its dashboard provides basic delivery status.
Bandwidth operates as a carrier-connected CPaaS and has direct relationships with US carriers for RCS routing. This means capability checks can be more accurate because Bandwidth queries carrier systems more directly than over-the-top providers. Bandwidth’s reporting is enterprise-focused and generally requires account management to access granular delivery data rather than self-serve dashboards.
Marketing platforms: Braze, Attentive, Klaviyo
Braze supports RCS through its Canvas messaging workflows with SMS fallback. Braze’s strength is the orchestration layer: you can build a Canvas that sends RCS to capable devices and SMS to others within the same campaign, with delivery data flowing back into user profiles. Braze does not expose carrier-level delivery data natively, but its Currents data streaming product can push delivery events to a data warehouse where you can segment by carrier yourself. For teams who want to connect this data back to their broader customer data infrastructure, the CDP comparison for B2B teams covers how platforms like Braze integrate with the broader stack.
Attentive focuses primarily on SMS and MMS for e-commerce and has RCS in limited release. Its fallback handling defaults to SMS automatically. Attentive’s analytics are strong for SMS campaign metrics but do not currently surface RCS-specific delivery breakdowns in a way that exposes fallback rates by carrier.
Klaviyo added SMS natively and has discussed RCS integration, but as of now its RCS support is limited compared to its SMS depth. Teams building RCS flows through Klaviyo should confirm current channel support directly with the platform before committing.
Enterprise and carrier-direct options
Syniverse and Infobip both offer RCS with fallback at enterprise scale and have deeper carrier relationship networks than most CPaaS platforms. Infobip’s platform includes an omnichannel routing engine that supports WhatsApp, RCS, and SMS waterfalls natively, with delivery reporting that goes deeper than most self-serve platforms. Infobip markets per-carrier delivery insights as a feature, though access to that data typically requires an enterprise contract rather than a self-serve plan.
Fallback Capability Matrix: Provider-by-Provider
| Provider | Fallback type | Capability check timing | Dual-billing on fallback? | Per-carrier delivery data | WhatsApp waterfall support |
|---|---|---|---|---|---|
| Twilio | Automatic (toggle) | Pre-send | No (single charge) | Via log export only | Separate integration required |
| Sinch Conversation API | Automatic (channel priority) | Pre-send | Possible (per-attempt billing) | Channel-level; not per-carrier | Native (WhatsApp, RCS, SMS waterfall) |
| Vonage Messages API | Automatic | Varies by carrier | Confirm with account team | Basic dashboard only | Supported via Messages API |
| Bandwidth | Automatic | Pre-send (carrier-direct) | Confirm with account team | Enterprise reporting; not self-serve | Not natively |
| Braze | Automatic via Canvas | Pre-send | No (channel-level billing) | Via Currents export | Supported in Canvas |
| Infobip | Automatic (omnichannel engine) | Pre-send | No (delivered channel only) | Per-carrier (enterprise tier) | Native (full waterfall) |
| Attentive | Automatic (SMS default) | Pre-send | No | SMS-focused; RCS limited | Not currently |
Note: Billing model and feature access vary by contract tier and change without notice. For each provider in your shortlist, request the fallback billing clause in writing and ask specifically whether a failed RCS attempt generates a billable event before the SMS fires. The table reflects publicly available documentation and reported platform behavior.
What Happens If the Recipient’s Phone Does Not Support RCS?
If a provider has pre-send capability detection, nothing happens on the RCS channel at all. The message goes directly to SMS without an RCS attempt, without an RCS charge, and without any delay. This is the correct behavior and the easiest to verify: ask the provider to show you a test message sent to a known non-RCS number and confirm the webhook event shows a direct SMS send rather than an RCS failure followed by an SMS send.
On platforms without pre-send detection, the sequence is: RCS attempt dispatched, carrier returns a capability failure or the message times out, fallback SMS triggers. The time between attempt and fallback depends on the carrier’s failure response time and the platform’s timeout configuration. Google’s own RCS fallback documentation notes that when a recipient lacks RCS capability or data connectivity, the platform should fall back to SMS, but the implementation of that fallback is the platform’s responsibility, not the carrier’s.
A device can also lose RCS capability mid-campaign. A user who travels internationally and switches to a SIM without RCS provisioning will receive RCS as SMS for the duration of their trip. Platforms that cache capability checks can incorrectly flag a number as RCS-capable based on a stale lookup, sending RCS messages that queue indefinitely rather than falling back immediately. Ask providers how frequently they refresh their capability cache for individual numbers.
Can You Set a WhatsApp-Then-RCS-Then-SMS Waterfall?
Yes, on a small number of platforms. Sinch’s Conversation API is the most mature self-serve implementation of a full three-channel waterfall in the US market. Infobip supports it at the enterprise tier. Braze supports it in Canvas for teams that have set up all three senders, though it requires configuring each channel separately with the relevant sender IDs and approval workflows.
The practical complexity is the sender registration layer. WhatsApp requires a WhatsApp Business API account approved through Meta. RCS requires a verified business sender, a process described in detail in the RCS business sender verification guide. SMS requires 10DLC registration for application-to-person messaging in the US. Running all three means maintaining three separate compliance and registration tracks, each with its own approval timeline and sender identity requirements.
The sequencing logic also matters. A WhatsApp-first waterfall should attempt WhatsApp only for contacts who have opted in to WhatsApp specifically. Sending WhatsApp messages to recipients who never opted into that channel creates a compliance problem, not just a delivery one. The platform needs to maintain channel-specific consent flags per contact and only attempt a channel if consent exists. Most platforms do not enforce this automatically. You have to build the consent check into your waterfall logic. For a broader look at how WhatsApp fits into channel strategy versus SMS, the WhatsApp vs SMS channel comparison covers the strategic trade-offs without the failover mechanics this article focuses on.
Do You Get Charged for Both the RCS Attempt and the SMS Fallback?
It depends entirely on the provider and how their billing is structured. Three billing models exist in the market:
- Delivered-channel billing: You pay only for the channel that successfully delivered. If RCS fails and SMS delivers, you pay the SMS rate. Twilio operates this way. This is the lowest-risk billing model for lists with mixed RCS capability.
- Attempt-based billing: You pay for each channel attempt, regardless of delivery outcome. A failed RCS attempt plus a successful SMS fallback means two charges. Some conversation-based billing models (common in WhatsApp pricing) create this exposure. Confirm whether RCS attempts that fail before delivery count as a billable event.
- Negotiated model: Enterprise contracts often negotiate a flat rate per delivered message that covers fallback. Bandwidth and Infobip typically operate in this tier.
To make the billing difference concrete: say a team sends 500,000 messages to a list where 35 percent of recipients are on non-RCS devices. At $0.01 per RCS message and $0.0075 per SMS, delivered-channel billing costs $3,250 for the RCS portion and $1,312 for the SMS fallback portion, totaling $4,562. Under attempt-based billing where both the failed RCS attempt and the SMS fallback are charged, the cost rises to $3,250 (failed RCS attempts) plus $3,250 (successful RCS) plus $1,312 (fallback SMS), totaling $7,812. These figures use industry-typical rates as placeholders, not a vendor quote , your actual numbers will differ. The underlying point holds regardless: the billing model matters more than the headline per-message rate, particularly at volume. For a broader view of how SMS and RCS pricing structures compare across platforms, the SMS marketing platform comparison covers tiered pricing models in detail.
Which Platforms Expose Per-Carrier Delivery Insights?
Genuine per-carrier delivery data, meaning delivery rates broken down by T-Mobile, Verizon, AT&T, and smaller carriers, is rare in self-serve messaging platforms. Most platforms report aggregate delivery status: delivered, failed, pending. A few go further.
Infobip’s enterprise reporting layer includes carrier-level delivery breakdowns as part of its analytics suite. This is the most complete implementation in the US market for RCS-specific data, though it requires an enterprise contract. Bandwidth has access to carrier-level data by virtue of its carrier-direct connections but surfaces it through account management rather than a self-serve dashboard. Twilio exposes enough data in its message logs that a technically capable team can reconstruct carrier-level delivery rates by matching recipient numbers to carrier prefixes using a carrier lookup database, but it does not do this for you natively.
For teams who need carrier-level data and are building their analytics in a warehouse, the approach is to pipe Twilio or Braze delivery events via Currents or webhooks into a data warehouse, enrich the recipient number with a carrier lookup API, and then query fallback rates by carrier. This is genuinely useful: if T-Mobile is showing higher-than-expected RCS fallback rates, it may indicate a carrier-side RCS provisioning issue rather than a device issue, and that distinction affects how you respond. For teams building this kind of enrichment pipeline, the Sinch alternatives comparison covers several providers that offer carrier enrichment as part of their messaging stack.
How to Diagnose a Fallback Rate That Seems Too High
A fallback rate above expected norms is one of the most useful signals in your messaging analytics, and one of the most commonly ignored. When RCS fallback rates spike, three categories of causes explain most cases.
Stale capability cache
If your provider cached RCS capability data and a carrier changed provisioning rules, your list may show devices as RCS-capable when they are not. The symptom is a sudden increase in RCS message failures followed by SMS fallback, with no corresponding change in your list composition. The fix is to ask your provider to refresh the capability cache for your recipient pool.
Carrier-side RCS degradation
US carriers occasionally have RCS gateway outages or provisioning issues that affect delivery without completely disabling the channel. The symptom is elevated fallback on a specific carrier while other carriers show normal delivery. This is where per-carrier delivery data pays for itself. Without it, you see an aggregate delivery dip and cannot tell whether it is your content, your sender ID, or a carrier infrastructure issue.
Device or OS changes
A major Android OS update or a carrier profile update can temporarily disable RCS on affected devices. The symptom is a sudden fallback spike that resolves over 24 to 48 hours as devices update and re-register their RCS profiles. Tracking fallback rate by send date against OS release dates can identify this pattern.
Frequently Asked Questions
What does SMS fallback mean in RCS messaging?
SMS fallback is the automatic delivery of a message as a standard SMS when RCS delivery is not possible. This happens when the recipient’s device does not support RCS, the carrier has not provisioned RCS for that subscriber, or the device lacks a data connection. A well-configured platform detects the capability gap before sending and routes directly to SMS. A poorly configured one attempts RCS first, fails, then sends SMS, adding latency and sometimes adding a second billable event.
Why do messages go back and forth between RCS and SMS?
Channel switching happens because RCS capability is checked at send time, and conditions change between sends. A recipient who is on Wi-Fi for one message and on cellular-only for the next may receive the first as RCS and the second as SMS if their carrier’s RCS gateway requires a data connection. Some platforms cache the last known capability state and continue sending RCS even when the device has temporarily lost RCS connectivity, which leads to messages queuing rather than falling back promptly.
Is there a charge for both the RCS attempt and the SMS fallback?
It depends on the provider’s billing model. Some providers, including Twilio, charge only for the channel that successfully delivered a message. Others charge for each attempt, meaning a failed RCS attempt and a successful SMS fallback produce two charges. Enterprise contracts often negotiate a flat delivered-message rate that covers both. Always confirm the billing model for fallback scenarios in writing before committing to a provider, particularly if your recipient list has a significant proportion of non-RCS devices.
Can I build a WhatsApp-then-RCS-then-SMS waterfall in a single platform?
Yes, but only on a small number of platforms that support all three channels natively. Sinch’s Conversation API and Infobip’s omnichannel engine are the most complete implementations in the US market. Braze supports all three channels in Canvas but requires separate sender setup for each. The practical constraint is not the platform logic but the sender registration: WhatsApp requires a Meta-approved Business API account, RCS requires a verified business sender, and SMS requires 10DLC registration. All three must be active before you can run the waterfall.
How do I know if a recipient can receive RCS messages?
Providers with pre-send capability detection query a carrier database or the RCS network directly to determine whether a given phone number has an active RCS profile before dispatching the message. You can also use carrier lookup APIs independently to enrich your contact list with device and carrier data, though these do not always include real-time RCS registration status. The most reliable signal is your platform’s delivery data: a high fallback rate on a specific number indicates persistent non-RCS capability on that device or carrier.
What is the difference between RCS message fallback and SMS failover?
The terms describe the same mechanism at different levels of abstraction. RCS fallback refers specifically to the channel-level switch from RCS to SMS when RCS delivery fails. Channel failover is the broader concept that applies to any messaging architecture where a secondary channel activates when the primary channel cannot deliver, including email-to-SMS fallback, push notification-to-SMS fallback, or WhatsApp-to-RCS-to-SMS waterfall logic. In practice, most marketing teams use the terms interchangeably, but CPaaS documentation tends to use “fallback” for the RCS-to-SMS switch and “failover” for multi-channel waterfall configurations.
Do all US carriers support RCS, and how does that affect fallback rates?
T-Mobile, Verizon, and AT&T all support RCS, and GSMA has been pushing for universal RCS adoption across the US market. Smaller carriers and MVNOs (mobile virtual network operators) have uneven RCS support. An MVNO running on a major carrier’s network may or may not pass through RCS capability depending on how their carrier agreement is structured. This is why fallback rates can differ significantly across your list even when most recipients appear to be on major carriers. The subscriber’s MVNO status, not just their underlying network, determines RCS availability.
The Claim Your Provider Will Not Make Upfront
Every RCS provider markets the channel’s higher engagement rates and richer message formats. Almost none of them proactively explain their fallback billing model, their capability check timing, or the granularity of their delivery reporting. Those details live in documentation, contract addenda, and support tickets, not the sales deck.
Most teams encounter the real billing model on the invoice after their first large send, not before it. The Fallback Audit framework in this article gives you the questions to ask before that send happens. Pre-send capability detection, delivered-channel billing, and per-carrier reporting access are not standard across the market. They are features worth negotiating for specifically, and in some cases worth changing providers to get.
For teams building or evaluating their broader messaging stack, the fallback question is inseparable from your customer data infrastructure. The platforms that do this best are the ones that treat RCS, WhatsApp, and SMS as channels in a unified routing layer rather than separate products. That architectural decision determines whether you can build the waterfall logic, the reporting, and the consent management in one place or whether you are stitching three separate systems together and hoping the seams hold.
