Concepts
The mental model behind Veto Checkout – discovery, the acceptance gate, mandates, trust tiers, policy, rails, and mutual receipts.
Veto Checkout is built on one design law: the protocol is self-describing. Agents
can't read docs at runtime, so every response carries machine-actionable reason_codes,
every error carries an error_human line, and every "you must do something next" response
carries the literal next call.
The pieces fit together like this:
The acceptance gate
The ordered sequence that runs on every settle – verify, replay-check, reputation, policy – all before money moves.
Mandates
The optional, polymorphic authorization an agent presents: veto · ap2 · acp · none.
Trust tiers
How a verified mandate plus reputation resolve to premium · trusted · standard · cautious.
Policy
The local acceptance rules: caps, rate limits, reputation floor, intent, review.
Rails
The pluggable settlement interface – x402, mock, and the card stub.
Receipts
The merchant-signed, offline-verifiable receipt that links back to the buyer mandate.
Test mode
Test vs live on the hosted platform – a veto_test_ key (Test mode) is a full sandbox where nothing real moves, a veto_live_ key (Live mode) settles real USDC on Base. Flip the dashboard toggle and rehearse the whole flow safely.
The acceptance gate
The ordered sequence that runs on every settle – load, idempotency, verify, replay, reputation, policy – all before any money is captured. The order is the chargeback defense.