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.
The acceptance gate is the heart of the protocol. It runs on POST /agent/checkout/{id}/settle, and the ordering is the chargeback defense: the
cheap, local checks (verify + policy) always run before any money is captured.
The sequence
Load the session
Must be awaiting_payment and not expired — else 410 (expired), 409 (wrong state /
already settled), or 404 (unknown).
Idempotency
If (agent_id, idempotency_key) already produced a terminal result, return it verbatim
(same status, same body). Agents may retry freely.
Verify the mandate
Local and offline-capable, dispatched by type. Produces a MandateVerification:
{ valid, tier, subject, authorizedAmount, merchantMatch, intentText, reasonCodes }.
Replay protection
A mandate subject is single-use. If it was already consumed, reject with
MANDATE_REPLAY. The reservation is atomic — two concurrent settles of
one mandate cannot both win.
Reputation
A hosted lookup. An unknown or unreachable agent degrades gracefully to
standard / known:false — the gate never blocks on reputation being down.
Acceptance verdict
The pure, local policy engine. Inputs: policy, cart total, mandate verification,
reputation, velocity counts, intent match. Output: an AcceptanceVerdict
{ decision, tier, reasonCodes, signals, capApplied }.
Resolve the decision
reject → 403. hold →
202 + review_url. accept → capture via the rail (the
mandate subject is already reserved from the replay step), set accepted, and issue
the signed receipt. Capture failure → 402, and the reserved subject is released.
Verify + policy always run before capture.
Money is only ever captured for a request the gate has already approved. If capture then fails, the reserved mandate subject is released so a legitimately un-spent mandate isn't burned.
Settle outcomes
| HTTP | status | Meaning |
|---|---|---|
| 200 | accepted | Policy accepted, payment captured, receipt issued. |
| 202 | hold | Needs human review; includes review_url + reason_codes. |
| 402 | payment_invalid | Payment proof bad / capture failed (safe to fix & retry). |
| 403 | rejected | Acceptance policy rejected the request. |
| 404 | — | Unknown session. |
| 409 | — | Already settled / idempotency conflict. |
| 410 | — | Session expired. |
See the settle endpoint reference for the full request/response shapes.
Concepts
The mental model behind Veto Checkout — discovery, the acceptance gate, mandates, trust tiers, policy, rails, and mutual receipts.
Mandates
The optional, polymorphic authorization an agent presents at checkout — veto · ap2 · acp · none. A Veto-governed agent is simply the highest-trust input, never a requirement.