Quick answer: Yes — an AI shopping agent can transact with your storefront on Devotel Orbit, and it does so over a published, unauthenticated Agentic Commerce Protocol surface: a discovery manifest at .well-known/agentic-commerce, a hosted product feed, and checkout-session endpoints that re-price everything server-side. The agentic lane is not a second commerce stack bolted on for machines — it is the same checkout spine your human shoppers use on WhatsApp, RCS, Apple Messages for Business, and Instagram, driven by an agent and gated by a signed, spend-capped payment mandate.
One cart, every channel
The question "can my AI shopping agent transact with my storefront?" only has a clean answer if the storefront is one thing, not four. If each channel held its own cart, an agent browsing your catalog and a human tapping a WhatsApp product message would be shopping from different baskets, and no single checkout could ever close both.
Orbit's commerce checkout spine holds one persistent cart per customer: a serializable snapshot your application round-trips in every call. Contributions arrive from any surface — a WhatsApp catalog message, an RCS carousel, an Apple Messages for Business list picker, an Instagram DM product share — and fold into that one cart, merged by SKU (productRetailerId). Two units of the same SKU added on WhatsApp and one more tapped on an RCS carousel accumulate into a single line, with sourceChannels recording where each contribution came from. The buyer who starts on WhatsApp and finishes on RCS checks out once, on one cart — and the same snapshot a human-driven conversation builds is the one an agentic session prices, because the cart travels in the request body rather than behind the channel.
The funnel a forged payment cannot survive
One cart is only trustworthy if its state machine and its money-matching are strict. Orbit's checkout funnel is an 8-state machine — browsing → cart_active → checkout_initiated → awaiting_payment → paid → fulfilled, plus the recoverable abandoned and the terminal cancelled — and /cart/transition rejects any illegal jump with VALIDATION_ERROR instead of silently corrupting state.
The load-bearing invariant sits at the end: server-side reconciliation. A captured payment comes back from whichever rail won — a PSP webhook, a Meta order, an Apple Pay token, a carrier-billing settlement — and /cart/reconcile-payment matches it against the cart on amount + currency only (channel is an annotation: a checkout begun on WhatsApp can legally be paid by Apple Pay in AMB). That verdict holds because every handler re-derives totals server-side before reading them: each line total is recomputed from unitPrice × quantity and the subtotal from the lines, so a forged subtotal smuggled into the request body cannot pass. The response says matched or names the exact failure — empty_cart, mixed_currency, currency_mismatch, amount_mismatch — with the signed delta.
The ACP surface: what a shopping agent actually drives
The public Agentic Commerce Protocol surface is the inbound edge a third-party shopping agent — yours, or a foreign one such as ChatGPT Instant Checkout or a Google AP2-style agent — speaks to a storefront you have published. Five endpoints, all under /api/v1/public/commerce/acp/{storefrontId}, all rate-limited per IP, with unknown or unpublished storefronts returning 404:
- Discovery manifest —
GET /api/v1/public/commerce/acp/{storefrontId}/.well-known/agentic-commerce. Unauthenticated: the agent reads the storefront's protocol version, capabilities, accepted payment methods, and the endpoint paths it may drive. This is the rendezvous — a shopping agent pointed at your storefront finds the protocol here, not in a docs page. - Hosted product feed —
GET /api/v1/public/commerce/acp/{storefrontId}/feed. Unauthenticated: the catalog the agent browses to discover what you sell, with prices in major currency units. - Open a checkout session —
POST /api/v1/public/commerce/acp/{storefrontId}/checkout. The agent proposes a requested-item set; the session is priced server-side against your stored catalog — no catalog is ever accepted from the caller, so a forged price cannot enter the cart. This is the same forge-proof rule as the human cart, applied at the protocol edge. - Update a checkout session —
POST /api/v1/public/commerce/acp/{storefrontId}/checkout/update. Replace-items semantics: the agent revises the requested set and the session is re-priced server-side, same rule. - Complete under a verified mandate —
POST /api/v1/public/commerce/acp/{storefrontId}/checkout/complete. Money-adjacent, so it is gated: the caller must carry a verified Web Bot Auth agent signature (Orbit's own key or a merchant-trusted foreign agent directory), and an anonymous caller (401) or an unverifiable one (403) is rejected before any charge. Once verified, the session is re-priced against the stored catalog again, and the agent's payment mandate is re-verified before authorizing.
The posture is worth stating plainly because it is unusual for a CPaaS: the read side (manifest, feed) is genuinely public — the protocol is only useful if any compliant shopping agent can discover your storefront without a handshake — while the spend side is closed to anything that cannot prove whose agent it is and what it is allowed to spend.
Native pay first, hosted pay-by-link everywhere else
Opening a checkout is half the problem; how the buyer pays is the other half, and it varies by region and channel. Orbit resolves it as a chain, not a flag: stay on the buyer's current surface if it can take payment, prefer native in-thread pay where it exists — WhatsApp Pay in the regions Meta enables it (India UPI, Brazil Pix, Singapore PayNow/cards), Apple Pay in Apple Messages for Business — and degrade to a hosted pay-by-link when no capable native rail exists. RCS and Instagram have no in-thread wallet by design, so they always resolve to the hosted link, rendered as an open-URL action, deliverable over SMS, email, Telegram, Viber, or a voice-IVR readout with a QR code.
The hosted link is hosted under your PSP, not Orbit's — hostedBaseUrl is your Stripe (or other PSP) checkout origin. Orbit orchestrates the resolution; capture and settlement happen at the provider you contract with, and payment data never lands on Orbit. The agentic lane lands on the same chain: an authorized mandate charge is the green light to invoke one of these rails — the mandate decides may the agent spend this, then the rail actually transacts.
The mandate: signed, spend-capped consent on the same spine
An AI agent never holds an unbounded wallet. A principal issues a payment mandate: an AP2-style authorization that caps the maximum per transaction, the cumulative total, optionally the allowed merchants or categories, and an expiry — carrying a consent digest that is re-verified before every spend. Issue with /commerce/agent-mandate, dry-run a charge with /commerce/agent-mandate/authorize, commit with /commerce/agent-mandate/charge, re-check tamper-evidence with /commerce/agent-mandate/verify, revoke with /commerce/agent-mandate/revoke.
Two properties matter for the buyer evaluating this surface:
- It is the same spine, not a parallel one. Completing an ACP checkout session requires a mandate — the session is re-priced from the stored catalog, the mandate's scope and caps are re-verified, and a charge outside them is rejected with
VALIDATION_ERROR. The agentic lane adds a consent gate to the rails your human shoppers already use; it does not fork them. - The controls are tenant-owned, not platform-imposed. The spend caps, the mandate scopes, the merchant and category allowlists, the PSP the hosted link lives under — these are your settings, per your risk posture. Orbit enforces the mandate you issued deterministically on every spend; it does not own a global commerce gate on your behalf. Treating your own customers' consent as a platform mandate would invert the responsibility; here the mandate is an object you control.
A completed charge can also carry an AP2 CartMandate verifiable credential — a standards-conformant artifact a genuine AP2 participant verifies with off-the-shelf JOSE/VC tooling, so "the agent was allowed exactly this" is demonstrable after the fact, not asserted.
Putting it together
The buyer's question resolves into a short read-back of shipped surface:
- Your human shoppers build one cart across WhatsApp, RCS, AMB, and Instagram, merged by SKU — the conversational commerce checkout guide walks that flow end to end.
- Every checkout resolves native-pay-first with a hosted pay-by-link fallback your PSP hosts, and every capture reconciles against a server-side re-derived total.
- A shopping agent discovers your published storefront through the ACP manifest, browses the feed, and opens a checkout session priced from your stored catalog — never from its own claims.
- The spend closes only under a verified agent signature and a mandate whose caps and consent digest re-verify before authorization.
- All of it is one spine: the commerce API is one surface, and the checkout spine concept explains why one-cart-many-channels is what makes an agentic edge safe to publish.
Frequently asked questions
What is the Agentic Commerce Protocol surface on Orbit?
A public, unauthenticated set of endpoints under /api/v1/public/commerce/acp/{storefrontId}: a discovery manifest at .well-known/agentic-commerce (protocol version, capabilities, accepted payment methods), a hosted product feed, and checkout-session endpoints (open, update, complete). The read side is public so any compliant shopping agent can discover the storefront; the complete step is gated on a verified agent signature and a valid payment mandate.
Can a shopping agent set its own prices when it checks out?
No. Every ACP checkout session is priced server-side against the merchant's stored catalog — the request proposes items, never prices, and the update endpoint re-prices replace-items revisions the same way. A forged price cannot enter the cart, and completion re-prices again before any charge is considered.
What stops an AI agent from overspending a customer's budget?
The payment mandate: an AP2-style consent object the principal issues, capping per-transaction and cumulative spend (with optional merchant and category allowlists and an expiry), carrying a consent digest re-verified before every spend. An ACP checkout completion re-verifies the mandate's scope and caps before authorizing, and a charge outside them is rejected with VALIDATION_ERROR. Revocation takes effect at the next spend decision.
Do I need a separate commerce stack for agentic shoppers?
No — the agentic surface reuses the same checkout spine as the human conversational channels. The one-cart-many-channels model, the 8-state funnel, server-side reconciliation, and the native-pay-first resolution chain are shared; the agentic layer adds the public discovery edge and the mandate gate on top of rails that already exist.