Skip to main content

​
RCS billing and metering model

RCS is billed per message against your prepaid wallet, on the same trigger-and-refund rules as the rest of the messaging channels. This page is the money view of RCS: what a message costs, when the debit lands, the two billing tiers you declare for an agent, which sends never enter billing at all, and how to reconcile RCS spend after the fact. The brand and agent approval lifecycle lives on RCS brand and bot approval lifecycle; reach detection and SMS fallback live on RCS capability check and SMS fallback.

​
What you pay for on RCS

RCS charges per message, at submitted — the moment the RCS provider accepts the handoff. The debit lands at send time, before delivery completes, so your wallet reflects the spend the moment the send goes to the wire. This is the same rule SMS, MMS, email, and push follow; the per-channel billing rules note in the billing API reference and the Channel charge trigger model state it for every channel in one table. Three consequences follow from the trigger:
  • No double-bill on delivery or read. A later DLR delivered or read receipt updates the message row’s status and fans out to your webhooks, but it never posts a second charge. One submitted message is exactly one debit.
  • Terminal failure refunds. When the provider reports a terminal failure — failed, undelivered, or rejected — the shared DLR pipeline’s refund arm credits the charge back to your wallet as part of the same hand-off that commits the status. A sent or delivered receipt never reaches the refund arm.
  • Pre-submit rejections are free. If the provider refuses the handoff before accepting it (an unapproved agent, a rejected payload), no charge ever posts.

​
Conversational vs Non_Conversational billing category

RBM (Rich Business Messaging) pricing splits agent traffic into two tiers, and you declare the tier per agent at creation with the billing_category field: Conversational or Non_Conversational. The same field is accepted on the combined setup call and on agent updates, and RBM is moving toward making the declaration mandatory, so set it explicitly rather than leaving it unset. Operationally, the two tiers classify how the agent is used:
  • Conversational marks an agent whose traffic is part of user-initiated conversations — the subscriber messages the agent first, or replies inside an open conversation window.
  • Non_Conversational marks agent-initiated traffic outside a conversation window — alerts, one-time codes, notifications, and scheduled updates the subscriber did not prompt.
Carriers price the two tiers differently, and the declaration is expected to match how the agent actually behaves; it is part of the agent’s directory submission, not a per-message switch. Two things Orbit deliberately does not do:
  • Orbit does not set RBM prices. The per-message price that lands in your wallet is the resolved rate for your plan and volume, the same way every other channel resolves rates (see pricing and rate resolution and the pricing page for your rate card). This page defines when and what Orbit meters, not the carrier rate tables behind the tiers.
  • Orbit does not re-classify your traffic. The value you send is stored on the agent record and passed through verbatim on every submission and resubmission. Pick the tier that matches the agent’s real traffic pattern when you create it, and update the agent if the pattern changes.

​
Capability check before you pay

RCS only bills recipients who can actually receive RCS. Before a send dispatches, the reach scan checks whether the destination can render RCS; a recipient without an RCS-capable device or client never produces an RCS submission and never enters RCS billing. See RCS capability check and SMS fallback for the probe contract and the codes a not-capable send reports. When a send falls back to SMS, you are billed for the leg that actually submitted. If the RCS leg was accepted and later failed terminally before the fallback fired, the RCS charge is refunded by the refund arm and the SMS leg is charged as SMS at its own per-segment rate — you pay for what reached the wire, per channel. The ordered-chain rules, including which leg a charge belongs to, live on Cross-channel fallback. Combined with the pre-submit-rejection rule above, the practical summary is: an unreachable recipient costs you nothing on RCS, and a recipient who lands on SMS costs you exactly one SMS.

​
Test mode

Two zero-rated lanes exist while you are evaluating RCS:
  • The platform agent during approval. Your production asset is a Google-approved agent, and approval takes days. While your agent application is pending, the platform’s approved demo agent carries your verification sends, and traffic on that shared lane writes zero-cost, test-stamped ledger rows rather than debiting your wallet — the same shared-asset posture described on The channel test-account model. Once your agent is approved, the shared lane ends and sends bill normally.
  • Simulated test mode. Sends made with a dv_test_sk_* key (or inside the sandbox) are persisted and receipted by a simulated provider but never dispatched, and post no charge; the rows are stamped as test so they stay out of production spend. See Sandbox, test mode, and the provisioning model and the Sandbox model for the boundary.
In both lanes the usage row is written anyway, so cost analytics stay complete; the row simply carries a zero amount and a test marker.

​
Reading your RCS spend back

Three surfaces read the same ledger back, at three granularities:
  • Usage records are the row-level feed: one record per RCS message with units, the persisted price and currency, the terminal status, and timestamps. RCS bills per message, so an RCS row reports units of 1 (unlike multipart SMS, which reports its segment count). Filter the feed on channels=rcs and sum units × price per currency to reconcile against wallet debits; the reconciliation walk is on Usage records: the per-record billing feed.
  • The CDR export returns every finished message — RCS included — with its billed units and terminal status, for workbook-side reconciliation against the usage feed. See CDR export.
  • The spend series (GET /api/v1/billing/spend-series) gives the per-day aggregate your dashboard chart renders, RCS rolled into the messaging total. Aggregates can legitimately differ in rounding from a row-level sum; for any dispute, the row-level ledger is the source of truth (see Channel cost rollup vs the billing ledger model).
Refunds on terminal failure appear as credits on the wallet ledger, so a period’s net RCS spend is submitted debits minus refund-arm credits — reconcile both sides, not just the debits.

​
Cross-references