Merchant-side AI agent verification at checkout
Merchants need a checkout trust layer for automation: identify the agent behind the basket, verify permission in-scope, enforce policy, and return a stateless YES/NO decision with proof—before order creation.
See the decision flow.
Run the demo, then map it into checkout and order pipelines.
Why checkout is the critical control point
- Value release: once you create the order and ship/release access, reversals are costly.
- Automation scale: agents can create baskets at machine speed.
- Policy drift: what was allowed last week may not be allowed now.
Merchant verification flow (recommended)
- Bind agent identity to the session/token (signed, short-lived).
- Attach permission object (consent receipt or delegation reference).
- Verify against basket + constraints + policy + replay rules.
- Return YES/NO + proof; log with order record.
{
"agent_id": "agt_123",
"consent_ref": "cr_456",
"basket": { "value": 4200, "currency": "GBP", "categories": ["retail"] },
"policy_version": "pv_2026_03"
}
→
{ "eligible": true, "proof": "sha256:…", "reason": "in_scope" }
What to enforce (merchant policy)
Basket constraints
Max value, allowed categories/SKUs, restricted items, quantity caps, channel restrictions.
Agent constraints
Velocity per agent, account mapping, delegation scope, receipt expiry/revocation, replay safety.
Internal links
- Verify AI agent transactions (end-to-end flow)
- AI agent payment verification demo (demo explainer)
- Consent receipts and definition
- Stateless verification (YES/NO model)
- Issuer authorization controls (issuer-side counterpart)
FAQ
How do we identify “agent traffic” reliably?
Issue per-agent identifiers/credentials and bind them to signed session tokens. Don’t rely on IP/user-agent.
What do we do when verification returns NO?
Block order creation or route to step-up approval. The key is you have a verifiable reason, not a guess.