Three acronyms keep getting mashed into one "agent payments" story: Mastercard Agent Pay, Google's AP2 and Coinbase's x402. They are not one thing. The sharpest line in The Defiant's explainer is its framing: AP2 records spending authority, x402 carries payment requests, and a signed voucher is a different step from final settlement. Mastercard's machine-payment pilot is the cleanest place to watch the three steps come apart.
One caveat up front. The Defiant's full article body did not load for us, so we have only its headline, standfirst and meta description. The mechanics below come from the primary and secondary sources linked at the end, and we say which is which.
Three jobs, not one
Think of an agent buying something as three questions.
- ▸Who allowed this spend? That is authority. AP2 is built for it. Its site describes an open protocol for the agent economy aimed at authorization, authenticity and accountability. It uses mandates, which are signed objects that record what the agent may do. A payment mandate sets constraints such as a budget in its open stage, and authorizes a specific amount tied to a finalized checkout in its closed stage. The mandates are chained as tamper-evident, cryptographically signed credentials into an audit trail.
- ▸How does the request for money travel? That is the payment request. x402 describes itself as an open, neutral standard for internet-native payments. If a request arrives without payment, the server answers with HTTP 402, and the client pays and retries. No account setup, no API key.
- ▸When does the money actually move? That is settlement. It can happen later, somewhere else, and in a different currency from the one in the request.
Most "agent payments" demos blur these. A builder who treats them as one step will build the wrong thing.
What the pilot shows
On October 20, Mastercard opened early access to Agent Pay for Machines, per The Block: first buyer-side and seller-side APIs, a developer toolkit and a sandbox. The pilot partners listed are Cloudflare, Ant International, BVNK, AIsa, Base and Coinbase. The product is still a pilot and is not commercially available.
The demo, as The Block reports it: a marketing agency, Hype, gave an agent a campaign task. The agent bought social media research from AIsa and eight campaign images from Cloudflare AI Gateway, inside a budget the agency approved. That came to nine payments to two providers. The agent paid with x402. A merchant that wanted payment answered with an HTTP 402, and it checked the agent's signed payment voucher before delivering the service.
Here is the part worth screenshotting. Mastercard said payment vouchers can be batched and redeemed later rather than settled one at a time. Base was the onchain settlement network, and BVNK, which Mastercard acquired in August, processed payment and settlement in fiat or stablecoins.
So a merchant can deliver on the strength of a signed voucher while money moves afterward. A valid signature tells the merchant "this agent is good for it under its limits." It does not tell anyone the transfer finished. Those are separate facts, with separate failure modes.
Where AP2 fits, and where we can't say
Be careful here. The Block's report does not mention AP2, and AP2's own site names card-style "pull" payments as its initial focus, with push payments and digital currencies on the roadmap. It lists x402 only in a human-not-present sample scenario, not as a supported method in the spec. The Defiant's framing places AP2 and x402 as complements. We could not read its argument in full, so treat "complements" as the outlet's claim, and the pilot's demo as using x402 on its own.
x402's site also says it is production-ready and has had a security review. That is the project's self-description, and the page names no reviewer or report, so we treat it as a claim and nothing more.
What builders should take from it
- ▸Model the three steps separately. Keep authority, request and settlement as distinct states in your agent's code. "Voucher signed" is not "paid."
- ▸Decide what a merchant does between voucher and settlement. If vouchers batch, someone carries redemption risk for a while. Your agent's spend limits are the only thing standing there.
- ▸Check the budget at the wallet, not in the prompt. The demo's approved budget is the right shape: a limit set by a human, enforced outside the model.
- ▸Expect more than one rail. Mastercard's June announcement covered card, bank account and stablecoin payments, and the pilot used both Base and a fiat-capable platform.
The prompt is the cute part. Spend authority, request format and settlement are the stack. If you are building an agent that pays, map those three choices first: satohub.ai/build.
What to watch
- ▸Whether Agent Pay for Machines leaves pilot status, and with what terms for settlement and voucher redemption.
- ▸Whether anyone ships AP2 mandates and x402 requests in the same flow, with evidence you can reproduce rather than a diagram.
- ▸Whether batched-voucher settlement publishes any failure or dispute data. Claimed designs are easy. Shown behavior is rarer.