How does RCS fall back to SMS?

Per recipient, and whether it is on depends on the send path. On SimplyRCS an API send falls back by default (`fallbackToSms` is true unless you set it to false), a campaign falls back only when you add fallback steps in the campaign builder (up to three, in descending richness: RCS, then MMS, then SMS), and a bot's replies in a conversation fall back automatically. In every case the account needs an active SMS or MMS number to fall back to. With fallback on, the platform checks each destination number's RCS capability before delivering: phones that can receive RCS get the branded, rich version; phones that cannot get the same message as SMS or MMS instead. You author once, and the delivery report shows the channel each recipient actually received.

Who decides when a message falls back to SMS?

Two decisions. You decide whether a send may fall back at all: on SimplyRCS an API send falls back by default unless its fallbackToSms flag is set to false, a campaign falls back only through the fallback steps you add (RCS, then MMS, then SMS), and bot replies fall back automatically; every path needs an active SMS or MMS number on the account. Once fallback is on, the platform decides per recipient, from an RCS capability check made at send time: if the device, carrier or setting cannot receive RCS at that moment, the message is delivered as SMS or MMS instead.

Does the customer notice the fallback?

They see a plain text message rather than a branded, interactive one, in the same conversation thread. What they should not see is nothing at all, which is the point: fallback trades richness for reach, so a time-sensitive message still goes out to a phone that cannot take RCS.

Do we pay RCS or SMS rates when a message falls back?

You pay for what was actually delivered. A message that falls back is billed at the SMS or MMS rate, not the RCS rate. On SimplyRCS the delivery report shows which messages landed as RCS and which fell back, so the bill can be reconciled against real delivery rather than estimates.

Does fallback require a separate 10DLC registration?

Yes. The fallback rides your registered 10DLC number, so a brand and campaign registration must be in place for the SMS leg to be deliverable. RCS verification and 10DLC registration are separate approvals and you need both for an RCS-first program to work end to end.

RCS Fallback to SMS: Per Recipient, Set Per Send

Fallback is the mechanism that makes an RCS-first programme safe to adopt before every customer is RCS-ready. It answers the objection every marketing team raises first, which is what happens to the people who cannot receive it. The answer is that they still get the message, in the format their phone supports, without anyone building a parallel campaign. It is also why what RCS messaging is can be answered without a reach caveat attached.

What happens at send time

The sequence is short and entirely invisible to both sides.

You submit one message to one audience. Fallback is on unless you turned it off: the fallbackToSms flag on an API send defaults to true, a campaign uses the fallback steps you added, and a bot reply falls back on its own.
The platform checks each destination number's capability. A result is reused for 24 hours for that number and sender, then looked up again, because capability changes as people change device, carrier, or settings.
RCS-capable numbers receive the rich message: verified sender, images, rich cards, suggestion buttons.
Everyone else receives a degraded but coherent version over SMS, or MMS where the message carries media.
Delivery results come back tagged with the channel each message actually went out on.

There is a second kind of fallback worth knowing about. A number can be RCS-capable and the RCS delivery can still fail, for example if the handset never comes online within the message's time-to-live. Falling back in that case has to be driven by delivery state, not by a timer alone, or the customer can end up with the same message twice. The safe sequence is:

Send the RCS message and wait for its DELIVERED receipt for a set window that suits the message (minutes for a passcode, longer for a promotion).
If no receipt arrives, revoke the RCS message before doing anything else. Google's RBM best practices describe revoking an undelivered message so it cannot arrive late.
Send the SMS version only if the revoke succeeds. A failed revoke usually means the RCS message was delivered in the meantime, so sending SMS as well would duplicate it.
Key every fallback on the original message ID, so a retried job or a late receipt cannot trigger a second SMS for the same message.

When you evaluate a platform, ask which of these steps it performs for you on each send path (API, campaigns, bot replies) and which you configure, and check the answer against the delivery events it actually reports.

What a rich message looks like when it degrades

This is where most of the design work is, and it is worth doing deliberately rather than leaving to a default. A rich card has an image, a headline, a description, and buttons. SMS has none of those things. So the fallback version has to carry the same intent in text: the core message survives, and any suggested action becomes a link.

The practical rule is to write the SMS version as a real message rather than as a stripped card. If the RCS message says "Your order shipped" with a Track button, the SMS should say "Your order shipped. Track it: [link]", not "Your order shipped." with the action silently gone. Check the fallback copy in preview before every campaign, because the failure mode is quiet: the message arrives, it just does nothing.

What fallback does to your bill

Billing follows actual delivery. RCS rates apply to messages delivered as RCS, and carrier SMS or MMS rates apply to the rest. The capability check itself is billed per completed check per phone number; a result reused within 24 hours and a check that fails are free, and running a check never gates or filters a send. The capability check itself is billed per completed check per phone number; a result reused within 24 hours and a check that fails are free, and running a check never gates or filters a send. The capability check itself is billed per completed check per phone number; a result reused within 24 hours and a check that fails are free, and running a check never gates or filters a send. This is exactly why the delivered-as breakdown matters: without it, you cannot reconcile an invoice, and you cannot tell whether your RCS share is growing. Our published rates are on the pricing page and every line of a bill is itemised on billing transparency.

MMS deserves a specific warning here. A media-carrying message that falls back becomes MMS, which is materially more expensive than SMS. A campaign with a large image and a low RCS-capable share can therefore cost more than expected, and the fix is usually to reconsider whether the image is doing enough work to justify carrying it to non-RCS recipients.

Fallback through the RCS API and integrations

Fallback is not an app-only feature. On the RCS messaging API the same decision is a field on the send call, fallbackToSms on POST /v1/messages/send, and the response reports whether fallback was used and on which channel. The flag defaults to true, so a CRM, a ticketing tool or an agency's own system that sends RCS messages through the API gets fallback unless it sets fallbackToSms to false, and it reads the per-recipient channel back from the message report rather than inferring it. The RCS API overview walks through the send-to-reply sequence, the developer hub holds the API documentation and the published reference, and the webhook guide covers the events that say what was delivered. When comparing RCS API providers, ask each the same question: is fallback a parameter of the send, and does the delivery report name the channel per recipient?

Why registration still matters

Fallback also needs somewhere to go: the account must have an active SMS or MMS number, on every send path, or there is nothing to fall back to. The SMS leg then rides that registered 10-digit number, so your 10DLC brand and campaign registration is what keeps it deliverable. Leading with RCS does not remove the requirement, it just means fewer messages take that path. 10DLC vs RCS sets out how the two layers fit together.

Key facts

Fallback is decided per recipient by a capability check at send time, not from a stored list; a check result is reused for 24 hours per number and sender.
One authored message covers both paths; rich content degrades to SMS, or to MMS when media is attached.
Billing follows actual delivery, so a provider should report the delivered-as breakdown back to you.
MMS fallback costs more than SMS, so heavy media on a low-RCS audience is the case to watch.
On SimplyRCS fallback is on by default for API sends (fallbackToSms: false turns it off), configured as up to three fallback steps (RCS, MMS, SMS) on a campaign, and automatic for bot replies; every path needs an active SMS or MMS number on the account. The message report records the primary channel, the actual channel and the fallback reason for every recipient, and each leg is billed at its own published rate.