Most agent-payment designs still start with a shared secret: give the agent an API key or a card number and hope the prompt holds. On 20 October 2026, Mastercard opened early access to a different shape — one where the agent signs a bounded payment voucher, and the seller checks that voucher before it delivers anything.
What happened
At Cloudflare Connect, Mastercard demonstrated Agent Pay for Machines (AP4M) and opened developer early access: buyer-side and seller-side APIs, a toolkit, a sandbox and documentation, following end-to-end pilots with Cloudflare, Ant International, AIsa, Base, BVNK, Coinbase and Hype.
The mechanics, as Mastercard describes them:
- A principal sets a task and a spending limit. The business gives the agent a job and a ceiling; the agent is not given unlimited spending authority.
- The seller asks for payment in-band. When the agent reaches a paid service, the service answers with HTTP 402 Payment Required — the web’s original “pay to continue” status code, now used by the x402 protocol that AP4M builds on.
- The agent signs a voucher, not a blank cheque. It creates a digitally signed payment voucher: a promise to pay, bounded by the approved limit.
- The seller verifies before delivering. The provider validates the voucher, returns the service, and the agent continues working.
- Vouchers batch and settle later. Interactions happen off-chain at machine speed; providers can combine vouchers and redeem them afterwards, while Mastercard supplies the network guarantee in between.
In the demo, a marketing agency called Hype funded an agent running on Amazon Bedrock AgentCore to plan a protein-bar campaign. The agent discovered registered AP4M providers, bought social research from AIsa, then bought eight campaign images through Cloudflare’s gateway: nine payments, two independent merchants, one approved budget, with wallet infrastructure from Coinbase, settlement on Base, and BVNK acting as the agent wallet through Mastercard’s Global Money Platform.
Mastercard’s own framing is the part worth keeping: “Payments aren’t the hard part. Authority is.”
Why it matters for KYA
A signed voucher is an authorization artefact, and authorization artefacts are exactly what a KYA check consumes. Three things follow.
First, the agent never holds the money. It holds a bounded, signed claim about what its principal authorized it to spend. That is a materially better failure mode than an agent holding a long-lived credential: revoking the budget, or the funding relationship behind it, does not require hunting down every copy of a key.
Second, the seller gets a verification step at the trust boundary. The merchant does not have to believe the agent’s self-description or trust the buyer’s software in the abstract; it verifies a voucher before doing work. That is the same structural move as verifying an agent’s credential at a portal — a relying party making a decision on evidence rather than on assertion.
Third, the voucher is an audit record. Nine payments against one budget, each traceable to a task the principal approved, is the kind of trail that answers “who authorized this, for what, and up to how much?” — the question KYA exists to make answerable.
The gaps are equally clear, and practitioners should not paper over them:
- A voucher proves spending authority, not agent identity. It says the principal authorized up to a limit. It does not, on Mastercard’s published description, tell the seller which agent is presenting it, who operates that agent, or whether the agent is the same one that was authorized five minutes ago. Identity and authority are related but not interchangeable — conflating them is a classic KYA mistake.
- “Registered providers” is a Mastercard-side registry. Agents discover AP4M providers through Mastercard’s layer. That is a directory, and directories concentrate trust: whoever writes to the registry shapes who can be paid.
- It is early access with pilot evidence. No volumes, no dispute rates, no failure data, and no independent evaluation have been published. The multi-rail settlement path (fiat in, stablecoin or fiat out) is described by the vendor, not demonstrated publicly at scale.
The constructive read is that agent payments are converging on the right primitive: delegated, bounded, signed authority that a counterparty can check. The open question is whether the identity half of that check becomes interoperable — a credential any seller can verify — or stays proprietary to whichever network is settling the transaction.
Sources
- Mastercard, “What happens when AI agents start paying each other? Watch Mastercard Agent Pay for Machines in action”, 20 October 2026 — mastercard.com.
- Mastercard, Agent Pay for Machines product page — mastercard.com.
- x402, the open payment-request protocol AP4M builds on — x402.org.
Note: the flow, pilot participants and early-access scope are as stated by Mastercard in its 20 October release. No transaction volumes or independent verification have been published.
Know Your Agent (KYA) explains agent identity, verification and accountability. This is an explainer, not legal or compliance advice — see our Sources & methodology. New to KYA? Start with What is Know Your Agent? and the glossary.