> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Commerce hub overview > Orient yourself to the Messages → Commerce hub: one persistent cart that resolves to in-thread WhatsApp checkout, a hosted pay-by-link, direct carrier billing, an AI-shopping storefront, or recurring subscriptions. # Commerce hub overview The Commerce hub under **Messages → Commerce** (`/messages/commerce`) is one surface for every checkout rail in Devotel Orbit. Instead of building per-channel carts, you run one persistent cart that resolves to the payment method the buyer can actually use: native in-thread pay where the channel supports it, a hosted pay-by-link everywhere else, direct carrier billing for operator-billed digital goods, recurring subscriptions that reuse a stored mandate, and an AI-shopping storefront that third-party agents can discover and drive. This page is the orientation. Use it to understand the five sub-surfaces, pick the right rail for a use case, and find the deeper guides and API references. ## Who can access the hub The hub and each sub-page are guarded to **owner**, **admin**, and **developer** roles. Operators, agents, or read-only seats do not see Commerce in the Messages menu. ## What the hub covers | Capability | Best when | Console page | Entry-point API | | - | - | - | - | | **In-thread checkout** | The buyer is on WhatsApp (Pay), Apple Messages for Business (Apple Pay), or web chat, and you want them to pay without leaving the conversation. | `/messages/commerce` | `POST /api/v1/commerce/whatsapp-checkout` | | **Hosted pay-by-link** | The buyer is on SMS, email, Telegram, Viber, voice-IVR, or any channel with no native wallet. | `/messages/commerce/pay-links` | `POST /api/v1/commerce/payment-request` | | **Direct Carrier Billing (DCB)** | You sell digital goods to prepaid mobile customers in markets where carrier billing converts better than cards. | `/messages/commerce/dcb` | `POST /api/v1/commerce/dcb/merchant` | | **Subscriptions** | You run subscribe-and-save or recurring billing and want each cycle to reuse the buyer's existing mandate. | `/messages/commerce/subscriptions` | `POST /api/v1/commerce/subscriptions` | | **AI-shopping storefront** | A third-party shopping agent (ChatGPT Instant Checkout, Perplexity, an AP2 agent) discovers your catalog and checks out without an Orbit credential. | `/messages/commerce/storefront` | `GET/PUT /api/v1/commerce/agentic/storefront` | | **Agent payment mandates** | You want an AI agent to transact on a buyer's behalf under scoped, revocable, spend-capped consent. | `/messages/commerce/agent-mandate` | `POST /api/v1/commerce/agent-mandate` | All six capabilities share the same checkout spine: one cart snapshot, server-side totals, and a reconciliation step that matches the captured payment to the re-derived cart amount. The hub pages are thin forms over the same Commerce API; nothing in the console widens or narrows the API surface. ## Sub-surface map Each page below is a live console. Click through from the hub, or link directly. ### DCB `/messages/commerce/dcb` is the Direct Carrier Billing workbench. Onboard a merchant with a settlement currency, digital-goods category, per-transaction cap, and a tenant-level country+operator coverage map. Once onboarded, initiate operator-billed charges, build the operator request, capture or fail the charge, issue refunds and chargebacks, and reconcile the operator's settlement batch against your captured charges. A charge is only possible on a `live` country+operator pair you have configured; the console lists common EMEA/MENA pairs as hints but accepts any pair you enter. ### Pay-by-link `/messages/commerce/pay-links` mints a tokenized hosted payment URL on your own PSP base URL, renders it for WhatsApp, RCS, SMS, email, Telegram, Viber, or voice-IVR, drives the link lifecycle (`pending` → `viewed` → `paid`, or `expired` / `cancelled`), and reconciles the PSP capture against the request on amount plus currency. The console never handles the card: the buyer pays on your hosted checkout page. ### Storefront `/messages/commerce/storefront` publishes the agent-facing ACP storefront. Set the merchant name and currency, toggle publish, build a bounded product catalog with categories, and list trusted-agent directories (Web Bot Auth or AP2 issuer JWKS URLs) that may complete a checkout. Default-deny: only verified agents can buy unless you explicitly list a directory. A published storefront exposes a public URL that resolves the discovery manifest and product feed. ### Subscriptions `/messages/commerce/subscriptions` runs subscribe-and-save schedules. Start a subscription off a cart, tie it to an existing mandate and a WhatsApp or RCS channel, and set the interval (`weekly`, `biweekly`, `monthly`, or `quarterly`). The list shows status (`active`, `paused`, `canceled`), amount per cycle, completed cycles, and next-renewal date. Renewing a cycle reuses the same mandate — no new consent is collected — and mints the reorder checkout over the chosen channel. ### Agent-mandate `/messages/commerce/agent-mandate` issues scoped, revocable, spend-capped consent for AI-agent purchases. Define the agent, the principal, currency, max-per-transaction, total cap, and optional merchant/category allowlists. The ledger shows spend against the cap, supports dry-run authorization, commit charge, integrity verification, and permanent revoke. You can also mint a Mastercard Agent Pay or Visa Trusted Agent Protocol network token in place of the hosted pay-by-link when the network is provisioned. ## Choose the right checkout path Pick the rail by what the buyer can do in the thread you already have: 1. **Native in-thread checkout first.** If the buyer is on WhatsApp in a market with WhatsApp Pay (India UPI, Brazil Pix, Singapore PayNow/cards), or on Apple Messages for Business with Apple Pay, resolve to native pay. Friction is lowest because the buyer never leaves the conversation. 2. **DCB if the buyer has no card but a live operator pair fits.** For digital goods in markets where prepaid mobile dominates, a `live` country+operator pair under your DCB merchant config can bill the carrier directly. The buyer confirms a code from their operator. 3. **Hosted pay-by-link as the universal fallback.** When there is no native wallet and no live DCB pair, mint a hosted link and render it into SMS, email, Telegram, Viber, a voice-IVR readout with a QR code, or WhatsApp's in-app browser. 4. **Storefront for machine-initiated discovery.** When a third-party shopping agent finds your catalog and starts a checkout on its own, the storefront closes it under the same spine with a mandate. 5. **Subscriptions on top of any of the above.** Once a buyer has consented to a mandate, turn a one-time purchase into a recurring schedule and let renewal reuse that mandate. Concrete examples: * A chai brand sends a WhatsApp catalog card in India: native WhatsApp Pay checkout. * A mobile game sells a season pass in Saudi Arabia: DCB on the `SA`/`stc` pair. * An HVAC company invoices a repair by SMS: hosted pay-by-link. * A supplement shop runs subscribe-and-save: subscription over WhatsApp, renewal reusing the mandate. * An electronics merchant wants ChatGPT Instant Checkout to discover products: publish the agentic storefront and admit the directory. ## Foundations The hub is the operational surface. These pages explain the model underneath: * [Commerce checkout spine](/concepts/commerce-checkout-spine) — how one cart spans WhatsApp, RCS, Apple Messages for Business, and Instagram; how native pay degrades to a hosted link; how server-side reconciliation works; and how mandates and storefronts plug into the same spine. * [Conversational Commerce Checkout](/guides/conversational-commerce-checkout) — an end-to-end walkthrough from a WhatsApp product message to a paid order, including the abandonment hook. * [WhatsApp Catalog and Product Messages](/guides/whatsapp/whatsapp-catalog) — how to send single-product and multi-product catalog messages, and how the inbound order feeds the cart. * [Click-to-chat QR codes](/guides/qr-codes) — generating QR codes for print collateral or voice-IVR readouts that lead to a pay-by-link or WhatsApp chat. ## Limits These limits are defined in the code that ships the sub-surfaces: * **DCB coverage pairs:** configured tenant-by-tenant in the merchant card. Only pairs marked `live` can initiate a charge; `pilot` and `unsupported` pairs are blocked. * **Pay-by-link channels:** rendered for `whatsapp`, `rcs`, `sms`, `email`, `telegram`, `viber`, and `voice`. * **Pay-by-link lifecycle:** transitions are `MARK_VIEWED`, `MARK_PAID`, `EXPIRE`, and `CANCEL`; terminal statuses (`paid`, `expired`, `cancelled`) accept no further transition. * **Storefront catalog cap:** `MAX_STORED_CATALOG_PRODUCTS = 250` products per storefront. * **Storefront trusted-agent directories:** `MAX_TRUSTED_DIRECTORIES = 25` directories per storefront. * **Subscriptions channels:** `whatsapp` and `rcs`. * **Subscriptions intervals:** `weekly`, `biweekly`, `monthly`, `quarterly`. * **Mandate network-token providers:** Mastercard Agent Pay and Visa Trusted Agent Protocol. If the selected network is not provisioned for your deployment, the call returns a 503 and falls back to the standard commit-charge path. For every endpoint, field, and error code, see the [Commerce API reference](/api-reference/commerce). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.