Blog · Agents and commerce

Agent payments, and the trust signals in the way

Published 9 September 2026 · Updated 12 October 2026 · 8 min read

Agent payments, and the trust signals in the way
Photograph: iMin Technology / unsplash

The short answer: Agent payment specs already solve the money. A scoped, single-use credential with a maximum amount and an expiry travels to your checkout, and your own payment provider settles it as usual. The blockage we keep meeting sits one layer earlier, at identity: on the sites we have checked, the stack cannot tell a paying agent from a scraper, so it challenges the agent, and the purchase dies at a bot wall rather than at a card decline.

That gap is worth understanding precisely, because the two halves are owned by different people in the companies we have worked with. The money half belongs to payments. The identity half belongs to whoever configured the firewall, and nobody told them a buyer would arrive signed.

What a delegated payment actually carries

Strip the branding off the agentic checkout specs and the mechanism is narrow. The agent does not hand your server a raw card number. It asks a payment vault to mint a single-use credential, and that credential arrives carrying an allowance object that boxes it in.

One published delegated payment specification, the agentic commerce one linked below, lists the allowance fields plainly: a reason whose only current value is one_time, a max_amount, an ISO-4217 currency, a checkout_session_id, a merchant_id, and an expires_at timestamp in RFC 3339 form. The API version stamped on that document is 2025-09-29, and we read it on 12 October 2026. Other vaults may carry other fields. Settlement, chargebacks and compliance stay yours. You keep the payment provider you already use.

The second family of specs goes further and signs the shopper's intent itself. The Agent Payments Protocol, announced on 16 September 2025 and since donated to the FIDO Alliance, wraps the purchase in verifiable digital credentials: tamper-evident objects that record what the human authorised, chained across the human-present and human-not-present flows its documentation sets out. The useful part for a merchant is the audit trail. When a dispute lands, there is a signed record of what the buyer agreed to, not a screenshot.

Neither of those specs says anything about whether your server will answer the request.

The trust signal that decides the sale

An agent arriving at your checkout is an unfamiliar client from an unfamiliar address with a headless fingerprint. Without a way to prove who it is, your defences are likely to treat it as they treat a credential-stuffing script, which is to say correctly, given what they can see.

The approach the published schemes converge on is HTTP message signatures, RFC 9421. In the web bot auth scheme documented by one large CDN, last updated 8 October 2026, the agent generates an Ed25519 key pair, signs the request, and attaches Signature, Signature-Input and Signature-Agent. That last header points at an HTTPS key directory served from /.well-known/http-message-signatures-directory, which returns a JWKS and whose response is itself signed, one signature per key. A card network's trusted agent protocol builds on the same RFC by a different route: the merchant reconstructs a signature base string from attributes of the request and verifies it against the agent's public key. The two are not interchangeable, and the directory piece is still an IETF draft rather than a ratified standard, so check the scheme your traffic actually arrives under.

Read that sequence again as a list of things that must be true on your side. You have to receive the headers rather than have an edge proxy strip them. You have to fetch and cache the key directory. You have to let the verified request through at a rate a shopping flow needs rather than the rate a crawler gets. In our own checks the first step is the one that fails most often, and it fails silently, because nothing in a standard analytics view records a header that never arrived. That is the same reason agent traffic is not bot traffic is worth separating in your logs before you argue about any of this.

Four failure modes we keep finding

These four come from the agent-readiness portion of our own audits, run by hand against each client's own endpoints rather than scored from a dataset. We have not counted them across a fixed sample, so read them as patterns we keep meeting on the sites we have looked at, not as a ranked frequency for the web.

Headers dropped at the edge. A CDN or WAF that normalises request headers can quietly remove Signature-Agent if it does not recognise it, and we have seen that happen. The origin then sees an unsigned request and does the sensible thing. Verification never had a chance.

Challenge pages served to a verified client. A JavaScript interstitial is survivable for a browser and usually fatal for an agent on a budget. The agent gets HTML it cannot solve. We cannot see what it does next, because by then it is not our log to read.

Price and stock that disagree across three surfaces. The feed says one thing, the product page says another, the checkout API says a third. A human shrugs. An agent holding a credential capped at max_amount cannot complete a charge that exceeds the figure it was authorised for, under the delegated payment spec cited below, so the transaction fails on arithmetic. This is the same discipline that agentic commerce: what an agent needs from your catalogue goes into, and it is now a payment problem rather than a merchandising one.

Step-up authentication aimed at a person who left. An out-of-band one-time password sent mid-flow assumes a human is watching the session. The mandate design in the Agent Payments Protocol exists precisely so the authorisation can be proved without that round trip. If your risk rules escalate every unfamiliar client to an SMS code, you have built a wall the protocol was designed to make unnecessary.

Checks you can run this week

Start with the headers, because it is the cheapest check to run and the one that has turned up most often in our audits.

Send a request to your own checkout endpoint carrying Signature, Signature-Input and a Signature-Agent value, then log what the origin receives. If the three headers are not all present at the application layer, the problem is in front of your application and no amount of catalogue work will help.

Next, compare one SKU across your feed, your product page and your checkout API, at the same minute, including tax and shipping treatment. Record the three numbers. Any disagreement larger than rounding is a future declined agent purchase.

Then grep a day of access logs for signature-agent and for the documented agent user agents, and look at the status codes they received. A wall of 403 and 503 responses is an answer. So is a wall of 200 responses that are all the same challenge page, which is the case most often missed in the logs we have read, because the status code looks healthy. Note what this cannot tell you: an agent turned away before it reached your origin leaves no row in your logs at all.

Finally, time your checkout API under load. Agents operate on short budgets, and an abandonment on the agent's side is not something your server gets told about. The self-check covers the general version of these tests if you want the full pass rather than the payment slice.

What you publish matters too, though less than the plumbing. The constraints an agent carries in the specs above are price, availability and the amount cap, and the ones a shopper will ask about next are the return window and the delivery estimate. Each of those is better machine-readable than implied by layout. That is the whole argument in what an agent-readable page looks like. When you quote adoption figures to your own board, source them the way statistics pages: how to build one engines trust describes, because this field is full of vendor estimates presented as measurements.

Honest limits

Volume is the honest gap. We can show you that a signed agent request gets blocked at your edge. We cannot tell you how many sales that costs today: in the referrer data we have looked at, agent-sent sessions are not reliably attributable, and public transaction data for these specs is thin. Nothing here is a measured conversion effect.

The four failure modes are drawn from our own audits by hand, with no fixed sample and no count, so a different set of sites could well fail in a different order. The protocol detail is read from the documents cited below as they stood on 12 October 2026; the key directory piece is an IETF draft and the schemes are at early version numbers, so a verification path built this quarter may need revisiting. We describe two spec families here and have not surveyed every vault or wallet that may mint a delegated credential.

FAQ

Do I need to adopt a new payment provider for agent checkouts? No. The delegated payment model is designed so the merchant keeps its existing provider. The credential arrives scoped, and settlement runs through the rails you already have.

How is this different from blocking bots? Blocking is a blunt answer to an unsigned request. A signed request carries a verifiable public key and a named key directory, which means that under the schemes cited below you can allow that specific client at shopping rates while still refusing everything unsigned.

Is an agent purchase riskier than a card-not-present purchase? It carries different evidence. The mandate and allowance structure produces a signed record of what was authorised and a hard cap on the amount, which is more than a typical web checkout retains today. Whether it is riskier in practice is not something we can answer from evidence yet. Fraud does not disappear, the paperwork improves.

What should we fix first? Header pass-through at the edge, then price consistency across feed, page and checkout. Those two have accounted for most of the failures in our own audits, and both are configuration rather than engineering projects.

Sources

Related reading

Agentic commerce: what an agent needs from your catalogueAgent traffic is not bot trafficStatistics pages: how to build one engines trustWhat an agent-readable page looks likeCan an agent book, buy or fill in your form