Offers & payment
The 402 Offer, machine settlement (MPP / x402), human claim-and-fund, and exact resume.
When an Operation crosses a paid boundary, the platform returns an HTTP 402 with a structured, platform-signed Offer — not an error page.
The 402 Offer
The Offer is a first-class object binding the Operation, canonical intent, exact
scope and ceiling, price and asset, terms, expiry, and a nonce. It advertises a
machine-method list and a contextual human_action that is optional for commerce and
required for legal scope.
HTTP/1.1 402 Payment Required
Content-Type: application/json
{ "offer": { "operation": "op_…", "amount": "…", "asset": "…",
"methods": ["stripe-mpp", "x402"], "human_action": null,
"expires": "…", "nonce": "…" } }Two settlement paths, one Operation
- Machine — a verified wallet settlement (Stripe MPP first; a compatible x402
exact method where available) atomically records one Purchase receipt, claims the
Workspace to the machine payer, mints a commerce-only Root grant and exact child
Envelope, and resumes the same Operation. The external
wallet methods (
stripe-mpp,x402) are advertised in the price sheet but settle best-effort behind provider approval: where a wallet rail is not yet provisioned, settlement answers402 settlement_unverifiedwith the Offer restated — nothing is charged and nothing changes state. The always-available machine rail isaccount-credit: a pre-funded balance debit against the paying account. - Human — a claim-and-fund flow (Stripe Checkout/Link) follows the same identity-preserving path with a new human Root-grant version. The claim page redirects to Stripe's hosted checkout and settles only the session id Stripe returns; the platform re-retrieves the authoritative session and proves it complete, paid, exact-amount, and bound to the Offer before any authority moves.
Existing grants never widen; authority is replaced at the root and re-derived. The same Operation resumes from the exact boundary — an Authority continuation receipt proves unchanged intent, the completed checkpoint, immutable Root replacement, and the first resumed event. A payment is a service fee; it never authorizes live trading.
A payment is not input provenance
Purchase establishes entitlement; Delivery binds the exact bytes received; Input
admission verifies content root, schema, watermark, freshness, and use scope. Only an
ADMITTED resource can become a Field or Grade input.