Merchants verify AI agent identity during checkout by validating a signed payment mandate before the order is authorized. The merchant confirms the mandate carries a valid signature from a trusted issuer, the purchase falls inside the scope the user approved, the amount and merchant match the mandate's constraints, and the mandate has not expired or been replayed. Checkout completes only when all four conditions hold.
Short answer: check the signature, check the scope, check the constraints, check for replay, then accept or decline with a recorded reason.
In this guide: what merchants verify, why it matters, the core problem, the step-by-step flow, failure modes, the standards landscape, worked scenarios, FAQ.
Key takeaways
- AI agent verification in agentic commerce combines four checks: identity binding, a user-signed mandate, scope and constraint matching, and replay protection. No single check is sufficient on its own.
- Agent verification supplements existing fraud scoring and 3-D Secure rather than replacing them. It adds a trust signal that legacy rails were never built to read.
- A merchant can only verify what the agent presents. Without a signed, scoped authorization, nothing cryptographic exists to check.
- Every accepted or declined agent order should emit a binary decision plus an evidence record, because that record is what resolves a dispute or chargeback later.
What merchants need to verify at checkout
When an autonomous agent reaches the payment step, the useful question is no longer whether a human is present. The real question is narrower: should this specific automation be allowed to commit this specific basket at this moment? Answering it means checking six things, ordered so the cheapest rejections happen first.
- Signature validity. The mandate attached to the order must carry a cryptographic signature from an issuer the merchant already trusts. A failed signature ends the check immediately.
- Scope match. The action being attempted, a purchase, must be one the user actually authorized. A mandate for "browse and add to cart" does not authorize capture.
- Constraint match. Amount, currency, merchant ID, and product category must all fall inside the mandate's limits. A $40 grocery authorization does not cover a $900 electronics order.
- Replay protection. The mandate's nonce must not have been seen before. Reuse signals a replayed or duplicated authorization and is rejected outright.
- Freshness. The validity window must still be open. A weeks-old one-time authorization is stale even if it otherwise verifies cleanly.
- Evidence output. The check emits a binary decision and a record of the reason, so the same data can defend a chargeback later.
Signature and replay checks are computationally cheap, so they catch forgery and duplication before the merchant spends effort on scope and policy. Stripe made the same architectural point when it built the Shared Payment Token for agentic commerce, scoping each token to one merchant and one cart total so the constraint boundary travels with the credential.
Why merchant-side agent verification matters
Liability becomes real at checkout. Before the order is placed a bad decision costs nothing, but once goods ship, reversing it costs money, support time, and trust. Agents change this in two ways. They operate at machine scale, so a compromised agent can place hundreds of bad orders before anyone notices, and the buyer is no longer the entity holding the credential, which breaks the old assumption that possession implies authorization.
Downstream parties inherit the ambiguity too. Issuers and acquirers see a transaction that looks human-shaped but was not, and when the consumer later disputes it, no clean record shows who actually approved it. Clear agent identity lets a merchant treat automated demand differently on purpose: tighter limits on high-value items, review for restricted categories, and a frictionless path for routine in-scope orders. It also gives payment service providers a traceable authorization chain, which is the single biggest lever for cutting agent-driven disputes before they become chargebacks. This move from session-based identity to credential-based authorization is the same shift covered in why agent payments need a new risk control framework.
The core verification problem
The merchant's problem comes down to one decision: trust this automation with this basket, or not. That decision breaks into a few separate problems that do not solve each other.
Identity at the edge is the first.
Most agents call merchant APIs from shared cloud infrastructure, so IP address and device fingerprint tell you almost nothing about which agent is behind a given request. Two unrelated agents can share the same egress IP, so a merchant that leans on network signals alone cannot tell a trusted reorder bot from a scraper.
Session and token integrity is the second.
A checkout token that does not bind agent identity into its signature can be lifted from one session and replayed in another. If the binding is weak, an attacker does not need to forge anything; reusing what already verified once is enough.
Delegated authority is the third, and it is the one merchants underestimate.
An agent acts for someone: an individual, a department, an external customer. The merchant needs to know who ultimately carries responsibility for the spend, because that party is who a dispute resolves against. Identity without a consent chain answers "which agent" but not "on whose authority," and the second question is the one that matters when something goes wrong. This is where the question of how do AI agents get verified before making payments stops being abstract: verification has to confirm the delegation, not just the caller.
Policy enforcement is the fourth.
Maximum basket value, disallowed categories, daily order counts: these rules have to be encoded somewhere and checked at checkout, not discovered after the goods leave the warehouse.
Step-by-step verification flow
A working merchant-side flow runs in seven steps. The order matters, because each step assumes the previous one passed.
- Agent registration and credentialing. The merchant or platform issues each agent a unique identifier and a credential, recording who the agent represents and which policies apply. Issuing a fresh credential per agent, such as single-use virtual cards for AI agents, keeps one compromised agent from contaminating the rest.
- Session creation and binding. When the agent opens a checkout session, the backend creates a signed token that embeds the agent identifier, a policy reference, and the customer or account mapping.
- Basket assembly with agent context. As the agent adds items, every API call carries the signed token, so the backend can attach each basket line to the same agent context.
- Pre-checkout verification. Before the order is finalized, the merchant validates the credential and mandate: signature first, then scope, then constraints, then replay and freshness.
- Eligibility evaluation. The verification returns a binary result plus proof. Inputs are the mandate, the basket, and any velocity or risk history for that agent and customer.
- Order creation or block. If the result is positive, the merchant creates the order and takes payment. If not, it can request step-up approval, downgrade the order, or block the agent.
- Audit and logging. The decision, the proof, and the agent identifier are logged against the order record, which is what a dispute team reads months later.
Steps 1 through 3 produce the credential. Steps 4 and 5 verify it. Steps 6 and 7 act on the result and preserve the evidence. A flow that skips step 7 will pass audits until the first chargeback, then fail badly. The mechanics of producing a signed, scoped mandate on the agent side are covered in how AI agents make autonomous payments, which is the input this flow assumes already exists.
Failure modes at checkout
Most rejections fall into five categories. Returning a specific reason code instead of a generic decline is what makes the decision auditable and the agent able to correct itself.
| Failure mode | Rejected evidence | Decision reason |
|---|---|---|
| Invalid signature | Mandate signature authenticity | INVALID_SIGNATURE |
| Expired or not-yet-valid mandate | Validity window | EXPIRED_MANDATE |
| Action outside scope | Scope check | SCOPE_NOT_ALLOWED |
| Amount, merchant, or category mismatch | Constraint check | CONSTRAINT_VIOLATION |
| Reused nonce | Replay check | REPLAY_DETECTED |
A signature failure is a hard stop and means the credential is forged or corrupted. A scope or constraint failure usually means the agent is acting outside what the user approved, which is not always malicious: a misconfigured agent trips these too, and routing it to step-up review recovers a legitimate order instead of losing it. A replay failure should never recover automatically, because a reused nonce is never legitimate at the point of capture.
The standards landscape merchants should know
No single specification owns this problem yet, so a merchant verifying agent identity is usually reading credentials produced by one of several systems. Knowing which system issued a credential keeps you from rebuilding the check for every integration.
At the protocol layer, OpenAI and Stripe's Agentic Commerce Protocol issues a Shared Payment Token scoped to one merchant and one cart, while Google's Universal Commerce Protocol standardizes how a checkout is created and an order tracked. Sitting underneath both is Google's Agent Payments Protocol, which uses cryptographically signed mandates as verifiable proof of what the user actually instructed. At the network layer, card schemes like Visa, with its Intelligent Commerce program, and Mastercard, with Agent Pay, are adding their own agent credentials and tokenized authorization so issuers can tell an agent-initiated charge apart from a human one.
The practical takeaway is that these systems converge on the same shape: a signed object stating who authorized what, for how much, and for how long. The verification flow above does not change based on which one produced the credential; only the trusted issuer key and the field names differ. A merchant that builds its check around signature, scope, constraints, and replay, the model behind the open AEP2 payment protocol, stays portable across all of them.
Two scenarios
A consumer reorder agent restocks household items every month and has a mandate capped at $150 across grocery categories. One run, the agent tries to buy a $700 laptop. The signature is valid and the agent is known, but the constraint check fails on both amount and category, so the merchant declines with CONSTRAINT_VIOLATION and routes the order to step-up confirmation instead of shipping it.
A B2B procurement agent restocks office supplies under a department mandate that excludes regulated equipment. Routine paper and toner orders pass cleanly. When the agent submits a bulk order including controlled items, the scope check returns SCOPE_NOT_ALLOWED, and the merchant portal sends the request to a human buyer rather than auto-accepting payment. Both cases work because the merchant treats the mandate as a hard gate. The agent-side mechanics that produce these scoped mandates are covered in securing AI agent payments with intent-based spending controls.
Frequently asked questions
How can merchants verify AI agent identity during checkout?
By validating a signed mandate before authorization. The merchant confirms the issuer signature, checks the action is within the user-approved scope, matches amount and merchant against the constraints, and rejects any replayed nonce. The result is a binary accept or decline with a recorded reason.
How do AI agents get verified before making payments?
The agent presents a credential and a user-signed mandate. The merchant or its provider checks the signature, scope, constraints, and freshness, then returns a binary decision before the payment is captured.
Does agent verification replace customer authentication or 3-D Secure?
No. It runs alongside them. Customer authentication proves who the customer is; agent verification proves the automation acting at checkout is authorized to represent that customer for this order.
What happens if the mandate does not match the transaction?
The merchant declines with a specific reason code: scope mismatch, constraint violation, expiry, or replay. Misconfigured agents can be routed to step-up review; replay failures are rejected outright.
How fast is agent verification at checkout?
Signature and replay checks are cheap and run in parallel with existing fraud and provider calls, so the added latency is typically on the order of tens of milliseconds.
How is agent identity bound to a checkout session?
The backend embeds the agent identifier and policy reference inside a signed session token, so the binding cannot be altered without breaking the signature.