x402 Seller Verification: Verify Agents Before Fulfillment

What x402 Verifies and What It Does Not

x402 is an open payment protocol that uses HTTP 402 Payment Required to let software pay for an API or digital resource inside the request flow. The client receives payment requirements, signs a payment payload, retries the request, and the seller or facilitator verifies and settles the payment before returning the resource.

That flow proves payment conditions such as the amount, asset, network, recipient, signature, and settlement status. It does not prove that the AI agent had authority from a principal to make the purchase, that the action matched a mandate, or that the agent's runtime was trustworthy. Payment verification and agent authority verification answer different questions.

Why x402 Sellers Need Agent Authority Verification

An x402 seller can receive a cryptographically valid payment from an unauthorized or compromised agent. The wallet signature proves control of the paying wallet. It does not establish the identity of the agent, the principal behind it, or the scope the principal approved.

This matters before fulfillment. API responses, model inference, data, compute, reservations, and digital inventory may be consumed immediately and cannot always be recovered. When a principal later disputes an agent's action, a settlement receipt explains how the payment moved, but not why the agent was entitled to request the resource.

What Verification Gets You

An agent verification call adds the evidence the payment layer does not carry. It can evaluate Principal Identity, Agent Identity, Wallet Provenance, Authorization Scope, Environment Identity, and Cross-Merchant Reputation before the seller releases value.

The seller receives ALLOW, STEP-UP, REVIEW, or BLOCK plus a signed verification record. The record preserves the request, evaluated authority, reason codes, rules version, and verdict. It complements the x402 payment receipt so the seller can show both that the payment was valid and that the agent's authority was evaluated.

Where Verification Fits in the x402 Flow

Agent verification is a precondition around fulfillment, not a replacement for x402. The seller keeps the standard payment flow and adds an authority decision before releasing the paid resource.

• 1. Define the resource. Bind the route, price, currency, network, recipient, and a unique request ID.
• 2. Collect agent evidence. Read the agent identity, passport when available, principal attestation, mandate, and transaction-bound authorization.
• 3. Verify authority. Call the decision layer with the requested action, amount, counterparty, payment context, and evidence.
• 4. Handle the verdict. ALLOW continues. STEP-UP returns a machine-readable request for more proof. REVIEW pauses for a human. BLOCK refuses fulfillment.
• 5. Verify and settle payment. Run the normal x402 verification and settlement path according to the payment requirements.
• 6. Release and retain. Return the resource only after the required checks pass, then store the signed verification record with the payment receipt.

The exact order of authority verification and payment settlement depends on the resource and cost model. A seller may verify authority before settlement to avoid accepting unauthorized funds, or reserve the resource and settle only after ALLOW. The invariant is simpler: do not irreversibly fulfill before both the required payment and authority checks succeed.

What to Store for Disputes and Audits

Keep the x402 payment requirements, signed payment payload or stable reference, settlement result, resource ID, agent verification record, and final fulfillment outcome under one transaction ID. Do not rely on a wallet address alone as the agent identity.

Outcome data matters after the sale. Link completed service, refund, dispute, abuse report, or delivery failure back to the verification record. That closes the loop between the evidence available before execution and what happened afterward.

Common Questions