The agentic commerce trust gap: 85% will let an AI agent shop, 10% will let it pay

What Mastercard's Signals report actually found

On August 3, 2026, Mastercard published a Signals report titled Encoding Trust: The Race for Intent, Consent and Control in the Agentic World. It is not a product launch and not a protocol; it is a piece of research about the conditions under which agentic commerce scales, and the numbers in it are more useful than most of the launches this year.

Per coverage of the report, consumer appetite falls off a cliff at exactly one point in the funnel:

Read the rows in order and the shape is unmistakable. People are not rejecting AI in commerce — 85% is an enthusiastic number. They are rejecting unattended spending. The drop from 74% to 10% happens entirely at the moment the human stops being the one who says yes to the money.

The report's own conclusion is blunt about it: growth "will be driven not by autonomy alone, but by useful experiences that make everyday decisions easier while keeping people informed and in control." Coming from the company building Agent Pay, that is a notable thing to put in writing.

One more finding from the same research is worth keeping: of roughly 2,400 products analysed across Shopify stores, only 11% carried structured data good enough for an AI agent to recognise and recommend them correctly. Even where an agent is allowed to act, most of the catalogue is illegible to it. Machine buyers need machine-readable offers, and almost nobody has published one.

The number under the number: B2B at three times consumer

The headline forecast in the report is $3–5 trillion of agent-assisted consumer spending by 2030. The sentence immediately after it is the one worth re-reading: business-to-business spending is projected to be potentially three times higher.

Put those two facts side by side and a strategy falls out of them. The consumer half of agentic commerce is capped, for now, by a permission problem that no amount of engineering fully solves — you cannot ship your way past someone's unwillingness to let software spend their money unsupervised. The larger half is business spending, where the buyer is a company, the approval happens once when a budget is set, and nobody needs emotional reassurance to release $0.04 for a data lookup.

We already have evidence for how each half behaves under load. In March 2026, OpenAI shelved Instant Checkout less than six months after launch, shifting from "buy in the chat" to "discover in the chat, transact on the merchant site." Consumer in-chat purchasing retreated to consumer-controlled purchasing — exactly the 74%/10% split, expressed as a product decision.

Meanwhile the machine-to-machine half kept compounding. The week of August 17, 2026 was x402's busiest of the year: 8.7 million agent payments, average ticket roughly four cents, per Token Terminal. Nobody surveyed anyone about their comfort level. The agents had budgets, the endpoints had prices, and 8.7 million transactions happened in seven days.

Why the trust layer exists — and what it's compensating for

The remedy the report proposes is a "trust layer" that sits between the agent's decision and the execution of the payment: before money moves, it verifies who is acting, what the user authorised and which limits apply, and keeps an auditable record of the agent's activity. Agentic tokens can carry task-specific authority, scoped by agent, merchant, category, spend cap, time window or usage rules.

That is good design, and it is genuinely needed — on the rail it is designed for. It is worth being precise about why it is needed there.

A card payment is a credential being presented, not money being handed over. The credential works because a network of rules decides, after the fact, whether the presentation was legitimate — and reverses it if not. That architecture has one structural requirement: somebody must be able to reconstruct, months later, whether a human authorised the transaction. When the entity presenting the credential is software, every input the dispute process relies on — device fingerprint, IP, navigation path, time on page — is now generated by a program. So the intent has to be captured, signed and stored separately, up front, by a new layer. We wrote about the other end of the same problem when an industry group started drafting an evidence standard for agent transactions, and about Mastercard's own machine-payment track earlier this year.

None of this is criticism. It is the correct amount of work for reversible, credential-based rails. It is also work that has to be adopted by AI platforms, banks, merchants and networks simultaneously before it means anything — which is why it is a multi-year programme and not a switch.

The agentic payments that already work have no consumer in them

Strip the consumer out of the transaction and every item on the trust-layer checklist either disappears or turns into a configuration field.

• Who is acting? A process the buyer's own engineering team deployed, holding a wallet the buyer's own finance team funded. No identity to federate across platforms.
• What did the user authorise? A budget, set before the run started. That is the whole consent event, and it happened once.
• Which limits apply? The balance in the agent's wallet, plus whatever per-call and per-period caps the platform enforces. A ceiling that can't be exceeded beats a permission that has to be proven.
• Is there an auditable record? The settlement itself — timestamped, verifiable, and pointing at the exact endpoint that was paid.

This is why the growth curves diverge. Consumer agentic checkout is waiting on a shared trust framework across four industries. An agent buying a data lookup is waiting on nothing except an endpoint that answers with a price.

And that last clause is the bottleneck. Every buyer-side announcement this year — cloud platforms issuing agent wallets, spend-management platforms issuing agent wallets, model providers documenting how an agent pays — has added funded machines looking for something to buy. None of them added a seller. There are millions of commercial APIs, feeds, archives and tools that still answer a machine with a signup form, and to a budget-bounded agent mid-task, a signup form is a dead end. It will not create an account. It will go somewhere else, or return without the data.

How Payzum fits: middleware in front of your API, not the facilitator

Precision matters here, because the roles in x402 get conflated constantly. Payzum is the middleware/proxy that sits in front of your existing API. Payzum is not the facilitator. On-chain settlement is handled by an external facilitator — Coinbase's today. What Payzum removes is the engineering that would otherwise land on your roadmap: implementing the 402 handshake, verifying payment, guarding against replay, and forwarding the paid request to your real service.

You configure the endpoint you already run, the API key or bearer token it already expects, and a price. Payzum publishes an x402 URL, answers agents with the 402 and the terms, waits for settlement, then proxies the paid call to your real endpoint with your own key and returns the response. x402 itself is an open HTTP standard, now under Linux Foundation governance — you are not adopting a vendor protocol.

Funds are non-custodial: USDC on Base lands directly in a wallet you control, with roughly two-second confirmations. Payzum never holds, pools or routes your money — the settlement is the payment, which also means the payment is final when the call is served: no chargebacks, no reversal window, nothing sitting in a processor balance for one to three days. Pricing is usage-shaped: around 1,000 transactions per month free, then roughly $0.001 per transaction plus gas. Your service keeps its current authentication, rate limits and deploy pipeline. If you want the settlement mechanics in detail, we've written up why USDC on Base fits per-request pricing, and what the x402 handshake actually looks like.

How it works, step by step

1. Connect the endpoint you already have. In the Payzum dashboard, paste your existing API URL and the key or bearer token it expects. No SDK, no protocol implementation, no redeploy of your service.
2. Set a price and a destination wallet. Choose what one call costs in USDC and the Base wallet where funds should land. Because settlement is non-custodial, that wallet is yours from the very first payment.
3. Payzum publishes the x402 URL. An agent that hits it receives an HTTP 402 with the price and payment terms — a machine-readable offer, the thing 89% of that Shopify sample didn't have — and pays in USDC. Settlement is verified through an external facilitator.
4. The paid call is proxied to you. Payzum forwards the request to your real endpoint with your key and returns the response inside the same request cycle. Signed webhooks, a full audit log, 2FA and encrypted secrets cover every call, and you can watch the first one land with the integration playground and REST API.

Where this already happens today

Three concrete shapes, all of them B2B, all of them outside the 10% ceiling:

• A data provider with a long tail it can't sell. A firm sells enterprise licences for its price feed but turns away everyone below the contract minimum. It publishes the same lookup at three cents a call over x402. Research agents, pricing bots and one-off scripts pay per query; nobody negotiates, nobody signs, and the segment that was uneconomic to invoice becomes the segment that pays instantly.
• An MCP tool that agents discover mid-task. A geocoding, enrichment or document-parsing tool is exposed to agent runtimes. When an agent needs it, it gets a price instead of a signup page, pays from its budget and gets the answer in the same request cycle. First revenue from a buyer the vendor has never heard of, with no onboarding at all.
• A regional API provider with no international collection account. A team in LATAM or Southeast Asia bills in dollars but can't easily open a US merchant account. Agents anywhere pay USDC on Base directly into the team's own wallet — no acquirer, no cross-border card fees, no rolling reserve, and no payout that can be frozen because there is no balance held anywhere to freeze.

Consumer agentic checkout vs machine-to-machine payments

Objections worth taking seriously

"So you're saying consumer agentic commerce is a dead end?"

No — and that would be the wrong lesson. The 85% number says consumers want agents in the buying process; the 10% says they want to keep the payment decision. Both can be true, and the trust-layer work being done by the networks is how the second number eventually moves. The argument here is narrower and about sequencing: if you sell something a machine can consume, you can capture agent revenue now, without waiting for a four-industry standards programme to finish. If you sell sneakers to people, you will still need that programme, and you should follow it closely.

"Our API already has API keys and invoicing. Why change?"

Keep them. x402 is additive, not a migration — your existing customers keep their keys, their contracts and their invoices. What an x402 URL adds is a second door for buyers who cannot walk through the first one: an autonomous process, mid-task, with a budget and no ability to complete a signup flow, fill in a card form or wait for a procurement cycle. Today that buyer sees a login page and leaves. The change is not to your billing model; it's to your addressable market.

"Isn't final settlement risky if something goes wrong?"

Finality cuts both ways, and it is worth stating honestly. You cannot claw a payment back, and neither can the buyer — which is why per-call pricing matters: the unit at risk on either side is cents, not a monthly contract. If you need to make a buyer whole, you refund as a payment you initiate, on your terms. What finality removes is the months-long reversal window that makes conventional processors hold reserves against your revenue in the first place.