What are RCS payments?

How an RCS payment actually works

The flow has five parts, and only one of them is RCS-specific.

1. A trigger in your billing, ordering or collections system: an invoice falls due, an order is ready to confirm, a renewal is coming up.
2. A message from your verified agent stating what is owed, by when, and for what, usually as a rich card with the amount and a reference the customer will recognise.
3. A suggested action, the Pay now button, which is an Open URL action pointing at a checkout scoped to that one invoice. Where your policy allows, the link can carry the customer into a page that already knows who they are, so there is no login step.
4. The payment itself, on your payment provider's page or inside your app. The card number never enters the thread, which keeps the message channel out of PCI scope and is exactly what the compliance rules on this subject require.
5. A confirmation back over RCS, a receipt with the amount and reference, triggered by your payment provider's webhook, so the customer sees the loop close in the same conversation.

Delivery, read and tap events come back to you through webhooks, which is what lets you measure paid-within-24-hours per message rather than guessing from bank deposits.

What is and is not possible in the US today

There is no card entry, no wallet and no payment rail inside the RCS thread on US carriers today. The purchase always happens on a page or in an app that the message opens. That is a smaller gap than it sounds, because the drop-off in a payment reminder is almost never unwillingness to pay; it is the three steps between reading the reminder and finding the invoice, and the button removes all three. If an in-thread payment step arrives on US carriers, the flow above still holds and only the button's destination moves.

Apple's separate Apple Messages for Business channel supports paying with Apple Pay inside a conversation; that is Apple's programme for iPhone, not RCS, and it is not what an RCS agent sends.

RCS vs SMS for a payment reminder

RCS vs SMS has the channel comparison in full; the row that matters for payments is the first one, because a request for money from an anonymous number is the exact shape of the fraud your own alerts warn customers about.

Where RCS payments are used

• Bill and invoice reminders: utilities, insurers, lenders, clinics and service businesses, where the reminder and the payment are one tap apart. See RCS for financial services and RCS for insurance.
• Collections: a UK debt-resolution service reported 30% higher payment rates with interactive RCS (vendor-reported, listed in The State of RCS 2026). The mechanism is trust: a verified sender asking for money is the opposite of the anonymous text a customer has learned to ignore.
• Checkout inside a conversation: reorders, restock alerts and abandoned-cart recovery, where the product is already chosen and the message only has to carry the customer to a checkout. RCS and conversational commerce covers the plumbing.
• Receipts and confirmations: the return leg, a verified confirmation of what was paid, which also happens to be the message customers most want to be able to trust.

The adjacent flow is the fraud alert: same verified sender, same one-tap response, the opposite direction of money.

Consent and compliance

A payment reminder is transactional, but it is still a business text and needs consent to be sent at all; how RCS consent works covers what counts. Send it from a transactional RBM agent rather than the promotional one, so a marketing opt-out never silences a bill. Keep card data on the payment page, never in the thread. For medical billing, is RCS HIPAA compliant sets out what may and may not go in the message. The verified sender is the anti-phishing mechanism: the name, logo and checkmark are drawn by the phone from the approved agent record, which is what stops a fraudster imitating your payment prompt (what is a verified sender).

What it costs

On SimplyRCS an RCS payment prompt is a rich card with a button, billed at the $0.0039 text rate; add an image and it is $0.0150. Where a phone cannot take RCS, the same prompt falls back to SMS at $0.0039 with the link in the text. SimplyRCS charges nothing per transaction; your payment provider's fees are unchanged. The full rate card is on the pricing page.

Setting up RCS payments, step by step

Step 1. Pick the trigger. Decide which event sends the prompt: an invoice falling due, a failed card-on-file retry, an instalment date or an order awaiting confirmation. Start with the one whose drop-off costs you most and add the rest once the numbers are in.

Step 2. Build the template once. Create a rich card with the amount, due date and reference as variables, sent from your transactional agent, and write the SMS fallback text at the same time so a phone without RCS gets the same link.

Step 3. Point the button at a scoped checkout. Set the Pay now button to an Open URL action carrying each customer's own checkout link, scoped to that one invoice and, where your policy allows, already signed in so there is no login step.

Step 4. Subscribe to delivery, read and tap events. Turn on the webhooks so every prompt is measurable per message rather than inferred from bank deposits.

Step 5. Send the receipt from the success webhook. When your payment provider confirms the payment, trigger a confirmation back over RCS with the amount and reference, so the loop closes in the same thread.

Step 6. Measure paid-within-24-hours against SMS. Send the same reminder as plain SMS to a comparable group and compare the share paid within a day. That is the number that decides whether the channel is earning its keep.