A customer reading your message on their phone can pay for the thing in the message without ever touching a card number. Direct Carrier Billing (DCB) puts the purchase on the mobile operator bill — the same invoice the subscriber already pays every month — so checkout is a phone number, an amount, and a confirmation, not a sixteen-digit PAN. Devotel Orbit ships DCB as a first-class commerce rail next to card-based checkout, so a campaign, a reply, or an agent's message can end in an operator-billed charge without leaving the conversation.
This guide walks through what DCB actually is, where the rail lives on Orbit, how a merchant gets onboarded and how a charge moves through its lifecycle, how settlement reconciliation works, and the decision cases where operator billing beats card rails. For the retention side of commerce — coupons and recovery artifacts that persist past the message — the loyalty, referrals, and wallet outbound guide covers the wallet half of the same rail.
What Direct Carrier Billing is
DCB is a payment method where the mobile operator collects the money. The buyer approves a charge against their phone number — on prepaid plans it draws from the airtime balance, on postpaid plans it lands as a line item on the monthly invoice — and the operator settles with the merchant later, minus its revenue share. The buyer needs no card, no bank account, and no payment app; the only identifiers in play are the MSISDN and the operator the SIM belongs to.
That changes who can buy. In markets where card penetration is low but mobile subscription penetration is near-universal — much of the Gulf, North and West Africa, South and Southeast Asia — a card-only checkout excludes most of the addressable base. DCB reaches prepaid buyers and underbanked buyers on the device they are already reading your message on, and it skips the PCI scope that comes with handling card data at all.
The trade-offs are real. Operators take a materially larger revenue share than card acquirers, per-transaction caps are low (tens of dollars, set per operator), and settlement arrives in batches on the operator's cycle with deductions you have to reconcile — not in a same-day payout. DCB is the right rail for small-ticket digital goods and services sold to a mobile-first base; it is the wrong rail for high-ticket carts.
Where the rail lives on Orbit
The DCB surface sits inside the messages commerce workspace as Messages → Commerce → Direct Carrier Billing, with three workbenches on one page:
- Merchant configuration — the merchant record: settlement currency, category, per-transaction cap, and the tenant-level operator coverage map.
- Charges — the workbench where you initiate an operator-billed charge and walk it through its lifecycle.
- Settlement reconciliation — where captured charges are checked against the operator's settlement amounts and discrepancies surface per record.
Two properties matter before any charge runs. The coverage map is tenant-level: each merchant declares which country + operator pairs it may bill against, so coverage is set in your workspace configuration, not by a platform-side list. And the charge itself is a payment dip on the operator's billing system — it is never an outbound message send, and the buyer's raw MSISDN is never stored on the charge record: the surface keeps only a masked form.
Merchant onboarding and the charge lifecycle
Onboarding a merchant is a configuration step, not a provisioning ticket:
- Name the merchant and pick its settlement currency — the currency the operator settles in and every charge is denominated in.
- Set the category and the per-transaction cap — the ceiling every individual charge is checked against.
- Define the operator coverage map: country + operator pairs, each marked
live,pilot, orunsupported. A charge only initiates against a live pair.
From there a charge moves through an explicit lifecycle, with the status visible on the charge pill:
| Step | What happens |
|---|---|
initiated | The charge is opened against a buyer MSISDN on a live operator pair, referencing the merchant. |
| operator dip | The operator request is built for the carrier-billing route and submitted; the amount lands on the operator bill. |
captured | The merchant confirms the charge — the amount is now owed and enters the settlement batch. |
failed | The charge is declined before capture; nothing reaches the operator settlement. |
refunded / partially_refunded | The captured amount is returned, in full or down to a partial remainder. |
charged_back | A captured or partially refunded charge is clawed back through the operator; the chargeback is counted at reconciliation. |
Each transition is a deliberate action on the charge, and the amounts are cumulative: a partially refunded charge carries both the captured and refunded amounts, so the net a settlement should pay is derived, never re-typed.
Settlement reconciliation
Operators settle in batches, and their totals do not always match your ledger — revenue-share deductions, currency rounding, and clawbacks all show up as drift. The reconciliation workbench exists to catch that drift record by record.
Each captured or partially refunded charge has an expected net: captured minus refunded. Against that you enter the operator's settled amount per record — or leave it blank to settle at the expected net when the operator files match. Reconciling produces a report with matched, mismatched, missing, and unexpected records, a chargeback count, and the total delta, so a discrepancy reads as "this charge settled short by this amount," not as a monthly aggregate that someone has to untangle in a spreadsheet. Charges enter the batch only in a state that belongs there — captured or partially refunded — so an initiated-then-declined charge cannot pollute the settlement.
When DCB beats card — and when it does not
Use operator billing when the audience and the ticket size fit:
- Low-card markets. Where the reachable base is prepaid and underbanked, a card field is a hard stop and a phone number is not.
- Small-ticket digital goods. Game credits, stickers, premium content, micro-subscriptions — the operator cap sits above the cart, so the high revenue share is priced in.
- In-conversation conversion. The buyer never leaves the message thread for a payment page, so the confirmation rate the conversation earned survives checkout.
Stay on card rails when the cart exceeds the operator cap, when you need same-day settlement rather than the operator's cycle, or when your margins cannot absorb the operator share. The right answer for a given audience is determined at the tenant level — the coverage map you configure declares which operator pairs are live for your merchants.
Pairing checkout with RCS and WhatsApp
DCB earns its keep where the conversation already is. Orbit runs RCS and WhatsApp as first-class messaging channels with SMS as the fallback chain you configure, so the checkout message reaches the buyer on the richest channel they opted into. The pattern: deliver the offer on RCS or WhatsApp — a rich card with a real buy action — and let the payment complete as an operator dip on the buyer's phone number instead of a redirect to a card form. For markets where the channel mix itself is the open question, the channel fallback matrix lays out the reach and consent trade-offs per channel.
The pickup mechanics differ per channel — RCS surfaces a native action, WhatsApp carries the confirmation in-thread — but the successive states of the charge are identical either way, because the rail under the message is the same one.
Frequently asked questions
What does the buyer need to pay via DCB?
A mobile phone number on an operator the merchant covers. The charge is approved against the MSISDN and lands on the operator bill — prepaid airtime or postpaid invoice. No card, no bank account, no payment app.
How do I set which countries and operators a merchant can bill?
In the merchant's coverage map: a list of country + operator pairs, each marked live, pilot, or unsupported, set at the tenant level per merchant. Charges initiate only against live pairs, and you can widen or narrow the map as markets open or close.
What states can a charge be in?
Initiated while awaiting the operator dip, captured once the merchant confirms, declined before capture, refunded in full or partially, charged back through the operator, or failed. The status pill shows the current state and the captured/refunded running amounts.
How does settlement reconciliation work here?
Reconciliation compares each captured or partially refunded charge's expected net — captured minus refunded — against what the operator actually settled, and reports matched, mismatched, missing, and unexpected records plus the total delta. A blank settled amount means "settle at the expected net"; a typed amount models an operator discrepancy.
When should I prefer DCB over card checkout?
When the audience is low-card — prepaid, underbanked, mobile-first — and the ticket size fits under the operator cap. Card rails stay right for high-ticket carts, fast settlement needs, or margins that cannot absorb the operator revenue share.
Published 3 September 2026.