RCS vs SMS in Retail and E-commerce: Which Message Belongs on Which Channel in 2026

This piece is for the person who owns retail or e-commerce messaging and has to decide, campaign by campaign, where each send goes. You get the capability difference, the coverage reality in the US right now, how the two bills are actually built, the fallback rules that stop you paying twice for the same message, and the metrics that tell you whether any of it worked.

What is the real difference between RCS and SMS for a retail program?

SMS is 160 characters of plain text from a number the shopper has no way to verify. It arrives on every phone sold in the last thirty years, and that is the whole argument for it.

RCS, Rich Communication Services, runs inside the same native messaging app, with no second app to install and no internet-dependent account to create. What it adds is everything SMS never had: your brand name and logo on a verified sender, images and video in the thread, product carousels, suggested replies and tappable actions, and delivery and read state back to you.

The row that decides most retail programs is the last but one, and it is the one that almost never appears in a comparison table. Read on.

The message is the same; what changes is whether the shopper can tell who sent it and whether she can act without leaving the thread.

Not everywhere. RCS pays for itself where the shopper has to make a choice, because that is where an image and a button remove a step.

• Product discovery and back in stock. She wanted it, her size was gone. A carousel showing the item in the two colors still available closes the loop inside the thread.
• Abandoned cart. The cart contents in the message, with one button to complete and one to say not now. The second button is worth as much as the first, because it tells you to stop.
• Order tracking and delivery exceptions. A status card beats a link into a portal she has to log into.
• Returns turned into exchanges. Offering the size that actually fits, with a picture, before the refund is processed.
• Loyalty and replenishment. A branded, verified message is the difference between a reorder prompt and something that reads like spam.
• Questions the product page does not answer. Fit, compatibility, delivery window. An AI agent answering inside the thread is the difference between a sale and a closed tab.

These are six of the eight journeys indigitall builds for retail and e-commerce, and the pattern across them is the same: the channel is chosen by the moment, not by the campaign.

Where does SMS still win, and it is not close?

Three places, and a retail program that moves them to RCS will notice.

One-time passcodes and anything security-adjacent. It has to arrive, on any handset, every time. SMS is the floor of the stack and the floor is where you put a passcode.

Urgency with no negotiation. A delivery exception, a store closure, a payment that failed. If it has to be read in the next ten minutes by everyone on the list, you send it on the channel that does not depend on device support.

The part of your list you cannot profile. Every list has handsets that will not negotiate RCS, and you do not get to know which ones in advance for the whole base. Whatever you cannot reach on RCS, you reach on SMS, or you do not reach it.

There is a fourth, quieter one. SMS is boring, and boring is sometimes the point. A shipping confirmation does not need a carousel.

This is the question that decides whether the rest of the plan is real, and it has moved a lot in eighteen months.

On Android, RCS is the default in Google Messages and has been for years. On iPhone the picture is newer and more conditional. Apple added RCS in iOS 18, and on 11 May 2026 it began rolling out end-to-end encrypted RCS messaging in beta for iPhone users on iOS 26.5, and only with supported carriers. Beta, and carrier by carrier. That encryption comes from RCS Universal Profile 3.0, which the GSMA published on 14 March 2025 and which also brought a richer deep link format for business messaging.

Read that operationally rather than as good news. It means that on any given day, a share of your US list resolves to RCS and the rest does not, the share moves as carriers and OS versions roll forward, and you do not control either. So the program has to be built for a channel that sometimes is not there.

Which is the opposite of how RCS is usually sold.

There is a second reason the share moves, and retail teams rarely plan for it: the recipient can switch the channel off. Google Messages carries a setting for RCS chats, and Google’s own support page tells users that turning it on and off is not advised because they will be removed from group chats. Shoppers use it anyway. The complaint that sends them there is promotional volume arriving in a channel they thought was for people, and the remedy they reach for is disabling RCS rather than unsubscribing from a brand.

That has a reporting consequence worth understanding before you set targets. A shopper who turns RCS off never appears in your numbers as an opt-out. Your fallback absorbs them into SMS, your RCS reachable count drops, and nobody asked to leave.

Reach is conditional at the measurement layer too. Google’s capability check only returns a successful response if the phone number has connected to the RCS service within the last 31 days, and outside that window the request returns a 404. So RCS reachability behaves as a rolling 31 day measurement rather than a stored property of a contact. You resolve it before each send, and a list segmented in January is wrong by March.

The last milestone is still marked beta and still depends on the carrier, which is why a US retail program cannot assume RCS reaches the whole list.

Why are the two bills not comparable?

Because they are not billed on the same unit, and this is where retail budgets get surprised.

SMS is billed per message, and a long message is billed as more than one. The arithmetic is unpleasant but it is arithmetic: recipients times segments.

RCS is billed differently. Every sender registers an agent with a billing category and a declared use case, and Google documents both. The billing category is conversational, for agents that engage in multi-turn conversations, or non-conversational, for agents that send messages without expecting frequent replies. The use case is one of OTP, transactional, promotional or multi-use. The same agent carries your brand, agent name, hosting region and description, and brand verification and launch are the deployment steps that follow.

Two consequences a retail team feels in month two. First, a campaign that invites a reply is priced as a conversation, so a carousel that gets three taps is not three times the cost of one. Second, your promotional agent and your transactional agent are separate registrations with separate approval, so the operational work is front-loaded and the compliance question is answered before the first send rather than after it.

None of which tells you whether RCS is cheaper than SMS. It tells you that the answer depends on how many turns the campaign expects, and that a single-turn shipping notification and a multi-turn product finder belong on different channels for reasons that have nothing to do with how they look.

A one-turn notification is cheap on SMS and a multi-turn exchange is cheap on RCS, which is why the channel is chosen per campaign and not per year.

How do you design the fallback so you never send the same thing twice?

The fallback is not a safety net bolted on at the end. It is the design.

The rule that makes it work is the one indigitall applies across every customer journey it builds: you start on the cheapest channel that can carry the message, and the moment the shopper completes the goal, she leaves the journey. The next, more expensive step only fires at whoever ignored the previous one.

In practice, for a retail program in the US:

1. Start on RCS where the message needs to be chosen from, on SMS where it needs to be read. This is a content decision, not a technical one.
2. Resolve capability before you send, not after. If the handset does not take RCS, that recipient starts on SMS. Same journey, different first step.
3. Set the exit condition on the goal, not on the send. Cart completed, size selected, return converted. Not “message delivered”.
4. Give the fallback a delay and a different shape. The SMS that follows an unopened RCS is not the same message with the pictures removed; it is the shortest version of the ask, with one link.
5. Escalate beyond text only when the margin pays for it. A voice agent closing a high-value cart is worth the call. The same call on a twelve dollar reorder is not. In Latin America the step after text is usually WhatsApp rather than voice, because that is where the shopper already lives; in the US it rarely is.
6. Keep consent per channel. Opt-in for RCS and an easy, mandatory opt-out is what indigitall’s own RCS documentation requires, and consent for one channel is not consent for another.

Step 3 is the one most programs get wrong, and it is the one that stops you paying twice.

The saving is not in the channel you pick first, it is in the shoppers who never reach step three because step one worked.

Delivery rate and click-through rate are the two numbers every channel vendor reports and neither one tells you whether the message made money. RCS makes this worse before it makes it better, because a rich message generates more taps and the taps flatter the report.

Measure these instead, and measure them against the same journey running on the other channel:

• Add to cart and checkout started, attributed to the send.
• Revenue per recipient, not per click. It is the only number that survives a channel change.
• Cost per resolved contact for anything post-purchase. A “where is my order” answered in the thread is a contact your team did not take.
• Second purchase rate at 30 and 90 days, for replenishment and win-back.
• Opt-out rate per channel, watched weekly. RCS is branded, so an opt-out on RCS costs you more than an opt-out on SMS.

Taps rise on RCS because the message invites them; only the last two stages tell you whether the channel earned anything.

The anchor to hold onto: indigitall’s published case with Soriana reports that web push alone drives 20% of total sales, which is the kind of figure that only appears when a channel is measured on revenue rather than on opens. Do the same arithmetic for RCS and for SMS separately, or you will never know which one earned the lift.

What do you check before you deploy either one?

• Which of your handsets resolve to RCS today, by carrier and OS, and how you will re-check it.
• Whether your sender is verified and your agent approved, with the right use case declared.
• Whether the fallback to SMS is automatic, and what triggers it.
• Whether consent is captured and stored per channel, and whether opt-out works on both.
• Whether the vendor publishes its security posture, SOC 2 and ISO 27001 included, or only mentions it on a call.
• Whether the profile that decides the next message is the same profile across channels, or five copies of it in five tools. A unified customer profile is what makes the ladder possible.
• Whether your reporting can separate revenue by channel, or only clicks.

Passcodes and delivery exceptions stay on SMS for reach; discovery, cart and exchange move to RCS because the shopper has a choice to make.

The rule underneath the whole table: the channel is chosen by the retail moment and by the action the shopper has to complete, not by the campaign. Use this as the decision, not the feature list.

And the honest version of the recommendation: if you can only run one channel well, run SMS well. If you can run two, put RCS in front of every moment where the shopper has a decision to make, keep SMS underneath it, and never let the same person receive both for the same goal.

The wider version of this question, across every channel and not just these two, is the one covered in the guide to omnichannel e-commerce. And if you want the full mechanics of RCS as a channel rather than the retail decision, there is a dedicated RCS marketing guide, alongside the SMS channel page for how the fallback is operated.

FAQs: RCS vs SMS for retail and e-commerce

Is RCS replacing SMS for retail messaging?

No, and a retail program built on that assumption will drop messages. RCS is richer and better branded, but its reach in the United States is still conditional on device, OS version and carrier, and end-to-end encrypted RCS was still rolling out in beta on iOS 26.5 as of 11 May 2026. SMS remains the floor of the stack, which is why it is the fallback and why passcodes and urgent alerts stay on it.

Can iPhone users receive RCS business messages?

Yes, since iOS 18, and with end-to-end encryption in beta from iOS 26.5 on supported carriers as of 11 May 2026. The practical answer for a sender is that support varies by carrier and OS version, so you resolve capability per recipient before the send rather than assuming it for the list.

Can a shopper turn RCS off after opting in to your program?

Yes, and it is the reachability risk nobody budgets for. Google Messages exposes a setting for RCS chats that the recipient controls, and Google advises against toggling it because the user gets removed from group chats. When someone uses it, your messages fall back to SMS, your RCS reachable count falls, and no opt-out is recorded against your brand. Treat reachability as something you measure before every send.

Is RCS more expensive than SMS for an e-commerce campaign?

It depends on how many turns the campaign expects, because the units differ. SMS is billed per message and per segment. RCS agents are registered with a billing category, conversational or non-conversational, and a declared use case, so an exchange with several taps is priced as a conversation rather than as several messages. A single-turn notification and a multi-turn product finder will not compare the same way.

What do you need before you can send RCS as a retailer?

A registered agent carrying your brand, an agent name, a hosting region, a billing category (conversational or non-conversational) and a declared use case (OTP, transactional, promotional or multi-use). Brand verification and launch are the deployment steps that follow. Plus opt-in consent and an easy, mandatory opt-out, which is the same requirement indigitall documents for the channel.

How do you stop a shopper receiving the same message on both channels?

By making the exit condition the goal rather than the send. The shopper leaves the journey when the cart is completed or the size is chosen, not when a message is delivered, and the next channel only fires at whoever did not act. Without that rule the fallback becomes a duplicate.

Which metrics actually show whether RCS worked?

Revenue per recipient, add to cart and checkout started attributed to the send, cost per resolved post-purchase contact, second purchase rate at 30 and 90 days, and opt-out rate per channel. Click-through rate rises on RCS almost by construction, so it is the least useful of the numbers you will be shown.

About the Authors