AI agent payment security: what merchants must verify before accepting an autonomous purchase

The problem in plain English

A customer may tell an AI agent, “Buy a refundable ticket for no more than $150.” Between that instruction and payment, search results, merchant pages, tools and other agents can influence the model. A valid payment credential alone does not prove that the final $1,500 purchase at a different merchant reflects the customer's instruction.

Merchants therefore need a deterministic check immediately before payment execution. The check should use signed or trusted facts, not another natural-language judgment from the same agent.

Seven controls to enforce at execution time

1. Amount: compare the final total with the authorized maximum, including fees and taxes.
2. Currency: reject a currency that was not explicitly allowed.
3. Merchant: bind authorization to the intended seller or a narrow allowlist.
4. Expiry: use short-lived authority and evaluate it when payment executes.
5. Consent: require evidence that the person approved the relevant mandate.
6. Intent binding: connect checkout facts to the authorized intent with a stable hash or signature.
7. Consume once: persist idempotency and reject sequential or concurrent replay.

Where AP2, UCP, TAP and x402 fit

These protocols solve different layers: discovery, checkout, identity, authorization and settlement. A merchant can support more than one at the same time. The operational policy should stay stable even when the wire format changes—that is the purpose of a protocol-neutral pre-flight layer.

Minimum safe implementation

Normalize the incoming purchase envelope, validate every hard boundary, reject ambiguous evidence, store one decision per idempotency key and keep a hash of the evaluated result. Run this before the payment processor call, not after an order is created.