> ## 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.

# Agentic commerce authorization and checkout model

> The trust architecture behind agent-driven purchases on Devotel Orbit: a principal-issued payment mandate bound by a SHA-256 consent digest, a channel-agnostic checkout state machine, and the A2A transact skill that joins them at the federation boundary.

# Agentic commerce authorization and checkout model

When a buyer's assistant agent places an order through one of your Orbit
agents, the purchase crosses a trust boundary ordinary dashboard commerce
never crosses: the spender is software acting on someone else's money.
Orbit answers that with a three-plane model in which authorization,
checkout state, and federation each have exactly one owner, and no plane
rests on a platform-wide shared secret. This page is the conceptual
anchor for that model. The endpoint-by-endpoint walkthrough lives in
[Agentic commerce transact](/guides/agentic-commerce-transact); the
protocol surface it rides on lives in [A2A
federation](/agents/a2a-federation).

## The model: three planes joined

Agentic commerce is the join of three planes Orbit ships independently,
joined at the federation boundary by the `transact` skill:

* **The authorization plane** is the payment mandate: an AP2-style,
  scoped, revocable authorization a principal issues once and an agent
  then spends against ([Agent-to-agent OAuth and
  AP2](/agents/authorization-mandates)). It only decides. It never
  moves money.
* **The checkout state plane** is the omni-cart: one channel-agnostic
  cart and one checkout state machine, no matter which surface the
  buyer arrives from ([Commerce checkout
  spine](/concepts/commerce-checkout-spine)).
* **The federation plane** is the `transact` skill an external agent
  discovers on your agent's AgentCard and invokes with a cart, a
  mandate, and the charge it wants to make ([A2A federation
  model](/concepts/a2a-federation-model)).

```text theme={null}
        principal (your customer)
          |  issues one mandate: caps, allowlists, expiry
          |  consent bound by a SHA-256 digest
          v
  +-----------------------+    +------------------------+
  | authorization plane   |    | checkout plane         |
  | payment mandate       |    | omni-cart              |
  | decides only,         |    | lines, totals,         |
  | never moves money     |    | checkout states        |
  +-----------+-----------+    +-----------+------------+
              |  consent digest,             |  cart total,
              |  re-verified per evaluation  |  recomputed from lines
              v                            v
        +----------------------------------+
        | federation boundary              |
        | transact skill (A2A)             |
        | charge == cart total?            |
        | mandate intact and in scope?     |
        +----------------+-----------------+
                         |  authorized / declined
                         v
        seller mints the payment instrument:
        hosted pay-by-link, or a network-issued
        agent token, on an authorized result
```

The join is deliberate. The skill recomputes the cart total from its
lines, cross-checks the requested charge against it, evaluates the
charge against the mandate, advances the checkout funnel, and returns a
structured decision. Only on an `authorized` decision does the seller
side mint the actual payment instrument; the decision layer itself
holds no payment credentials and touches no messaging or voice
provider path.

## Invariants

Five invariants define the model. Every evaluation holds all of them:

1. **The mandate decides; it never pays.** An evaluation returns a
   decision, not a transfer. Even a fully authorized charge moves no
   money until the seller mints a payment instrument (a hosted
   pay-by-link or a network-issued agent payment token) and the buyer
   settles it on the existing payment rails.
2. **Consent is bound per principal, not to a platform secret.** At
   issue, a mandate mints a SHA-256 consent digest over its immutable
   scope: the principal, the agent, the per-transaction ceiling, the
   total cap, the currency, the merchant and category allowlists, and
   the expiry. Every evaluation recomputes that digest before anything
   else; a scope altered after consent fails integrity and is declined.
   The tenant's federation signing secret authenticates the transport;
   it does not authorize spend. Spend authorization is the principal's
   artifact.
3. **The charge must equal the cart.** The skill recomputes the cart
   subtotal from its lines (quantity times unit price per line, rounded
   to two decimals) and declines any charge whose amount or currency
   differs from that total. A forged or drifted total cannot authorize.
4. **Either party can revoke, and terminal is terminal.** The principal
   revokes the mandate, lets it expire, or exhausts its cap; you revoke
   an agent's agentic-commerce opt-in from the agent's own
   configuration. `revoked`, `expired`, and `exhausted` are terminal:
   no later charge authorizes under any of them.
5. **Every invocation leaves an audit trail.** Each evaluation carries
   the mandate id, a deterministic authorization id, the evaluated
   amount, the spend headroom remaining after it, and the caller's
   reference, so a dry-run decision and the committing charge line up
   one to one in your audit surface.

## Trust model: cross-network without a shared secret

A mandate a buyer agent presents is only as trustworthy as the proof
behind it. Orbit binds that proof to identities, not to bilaterally
shared secrets:

* **Signing identity.** Outbound agent requests that carry a mandate
  sign with the tenant's Ed25519 identity key (the same Web Bot Auth
  keying Orbit verifies inbound), and the public half is published at
  a well-known key directory. A verifier checks a signature against
  published key material; nothing secret crossed the wire.
* **Standards-shaped credentials.** For cross-network counterparts, an
  authorized charge bridges to a W3C Verifiable Credential carrying an
  EdDSA compact-JWS proof. A Mastercard-, PayPal-, or Google-side agent
  verifies it with off-the-shelf JOSE and VC tooling instead of needing
  Orbit-specific code.
* **Standard key resolution.** Counterpart networks resolve the
  issuer's public key through standard mechanisms, a JWKS endpoint or
  a DID document, exactly as they would for any other federated
  issuer. Trust is established per principal and per mandate, so one
  compromised relationship never implies trust anywhere else.

The practical consequence: an external agent can prove it was
authorized to spend, and you can verify a presented mandate, with no
pairwise secret provisioned between the two networks.

## Lifecycle

**Mandate.** A mandate is issued `active`, with its consent digest
minted at issue. While active, each authorized charge advances `spent`
and the authorization counter; reaching the total cap flips it to
`exhausted`. Revocation flips it to `revoked` immediately, and a
mandate past its expiry is `expired` by the clock even if its status
has not been flipped. All three terminal statuses deny every later
charge, and re-revoking an already-revoked mandate is an error rather
than a silent no-op.

**Cart and checkout.** A cart starts `browsing`; the first line moves it
to `cart_active`. From there the funnel runs
`checkout_initiated`, then `awaiting_payment` once a payment is
requested, then `paid` on confirmation, then `fulfilled`. Two exits are
terminal, `fulfilled` and `cancelled`, while `abandoned` is
recoverable: a recovery nudge resumes an abandoned cart back to
`cart_active`, which is the basis for abandoned-cart recovery. Totals
are always re-derived from the lines, never accepted from the caller,
so a presented cart cannot smuggle a forged subtotal past
reconciliation.

## Where the guide and API pages branch off

This page states the model; the operational surfaces branch off it:

* [Agentic commerce transact](/guides/agentic-commerce-transact) walks
  the `transact` skill end to end: opting an agent in, presenting a
  cart and mandate, reading the authorization decision, and minting
  the payment instrument on an authorized result.
* [A2A federation](/agents/a2a-federation) is the protocol reference
  the skill rides on: discovery modes, the task flows, and the inbound
  authentication at the public boundary.
* [Agent identity governance](/compliance/agent-identity-governance)
  covers the identity and disclosure controls that sit alongside
  agentic spending: how agents identify themselves and how your
  compliance posture governs them.

## See also

* [Agent-to-agent OAuth and AP2](/agents/authorization-mandates) —
  issuing, scoping, and revoking the payment mandates this model
  evaluates.
* [Commerce checkout spine](/concepts/commerce-checkout-spine) — the
  omnichannel cart and checkout state machine the transact skill
  advances.
* [A2A federation model](/concepts/a2a-federation-model) — discovery,
  delegation directions, and what federation deliberately does not
  do.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.