AI Agent Payment Protocols 2026: x402, MPP, AgentCore
These protocols are not competing for the same job. Authorization, checkout, and settlement are three different layers, and knowing which one you are shopping for settles most of the argument.
Not long ago, giving an agent the ability to pay for something meant putting a Stripe key in an environment variable, setting a max-spend tripwire, and hoping the model would not get stuck in a loop calling a two-cent endpoint fifty thousand times overnight.
That is no longer the state of the art. The category went from one duct-taped pattern to a stack of real protocols in about six months, and the most common mistake now is reading them as competitors when most of them operate at different layers.
Checked on 21 August 2026, and the freshest thing here is three days old.
Three problems humans do not have
Fees. Card payments have a floor, roughly thirty cents plus a few percent, lower at scale and never zero. An agent paying for a $0.001 tool call a million times does not have a payment problem, it has a fee problem, and the infrastructure costs more than the service. That arithmetic kills whole product categories before they ship.
Identity. A merchant needs to tell a legitimate agent acting for a customer from a scraper running a stolen card. The fraud tooling built for humans, device fingerprinting and behavioral signals and step-up challenges, breaks the moment the actor is headless. If every agent looks like fraud, every merchant blocks them.
Mandate. A human pressing buy consents by the act of pressing. An agent does not. Something has to carry “she delegated up to $200 of office supplies, on weekdays, this month” in a form a merchant can verify and she can audit later.
Every protocol below is aimed at one or more of those. Almost none of them aim at all three, which is exactly why they stack.
The stack, not the race
x402: micropayments over HTTP
Coinbase built this around a status code old enough that HTTP/1.0 reserved it and everyone forgot: 402 Payment Required.
An agent calls an API. The server answers 402 with payment requirements. The agent’s wallet signs a stablecoin transaction, attaches it, retries, and gets the data. Settlement takes a fraction of a second and fees are fractions of a cent. It is HTTP-native, so there is no SDK, no webhook dance, no merchant account.
It also stopped being a Coinbase project. The x402 Foundation launched on 2 April 2026 under the Linux Foundation with Coinbase, Cloudflare, Stripe, Google, and Visa among the founding members, and the protocol has cleared well over a hundred million transactions. When Stripe and Visa join the governance of a stablecoin rail, that is not a hedge against their own products, it is an admission that the fee floor is real.
What it is good at: paid APIs and agent-to-agent service marketplaces where the unit is too small for cards. A million calls a month at a tenth of a cent each works here and nowhere else.
What it is bad at: anything regulated or consumer-facing. No built-in identity checks, no chargebacks, no fiat conversion at the merchant end, and your accounting team now has stablecoin on the books.
MPP: abstract over the rail
Stripe’s answer refuses the stablecoin-versus-fiat question. The Machine Payments Protocol settles on fiat rails or on Tempo, and the choice is transparent to the agent. It launched on 18 March 2026 alongside Tempo’s mainnet with over a hundred services integrated, including names like DoorDash, Ramp, and Revolut.
The signatory list is the point. It is not a claim of technical elegance, it is everyone in the room preferring one spec to a network war that fragments the buyer base.
For consumer purchases, an assistant buying a forty-dollar item from a real merchant, this is the path with the broadest acceptance. For business procurement in the thousands, it is also where you want to be, because dispute handling and compliance are not optional at that size.
The trade is that you are paying card economics. MPP will never undercut x402 on a tenth of a cent.
ACP: the checkout layer
Distinct from both of the above and often mistaken for a competitor. ACP is the flow between an assistant and a merchant at the moment of purchase, and it has been live inside ChatGPT Instant Checkout since February. It sits on top of a settlement rail rather than replacing one.
AP2 and the card networks: the mandate layer
Google’s AP2 is an authorization framework: a specification for how a delegation is expressed, signed, and verified. The spec is published and the coalition exists. Its extension for crypto settlement is production-ready; the card-based side is still maturing.
Visa and Mastercard responded the way you would expect, by extending what they already do best, which is issuing tokenized credentials. Visa’s Trusted Agent Protocol and Mastercard’s Agent Pay have the same shape: a network-issued token a merchant can verify, a fraud system can score, and a consumer can revoke.
The thing to notice is that neither network is trying to be the rail your agent calls. They want to sit underneath whichever protocol wins and supply the credential and the fraud signal. Visa designed its piece to be protocol-agnostic on purpose. The networks earn either way as long as the credential underneath is theirs, and the existing acceptance infrastructure, every terminal and gateway and issuing bank, comes along for free. That is an enormous distribution advantage that no new protocol can buy.
AgentCore Payments: the managed surface, now GA
AWS wrapped both rails behind one API inside Bedrock, and it went generally available on 18 August 2026 after a preview that started in May. If you read this post in the spring, that is the line that changed.
What you get: managed wallets, orchestration across x402 and MPP so the choice of rail is a policy decision rather than an integration, configurable spend limits enforced at the infrastructure layer rather than in your prompt, and audit trails through the platform’s own observability.
That last part is the real selling point and it is not about payments at all. A finance team can revoke an agent’s spending authority without anyone touching application code. Anyone who has tried to answer “what exactly is this agent allowed to buy” from a codebase will recognize why that matters.
The obvious caveat is the obvious one: it is a managed AWS surface, and the portability you gain over the two protocols you lose against the platform.
What I would actually pick
If your agent buys machine things, tool calls and API access and compute, at sub-cent unit prices: x402, and increasingly through a managed surface rather than directly.
If your agent buys human things from real merchants: MPP for settlement, ACP for the checkout flow if you live inside an assistant, and a network credential underneath for the identity problem.
If you are writing the position paper rather than the code: the useful sentence is that authorization, checkout, and settlement are three separate decisions, and a vendor pitching you one of them as the answer to all three is selling.
And whichever you pick, put the spend limit somewhere the model cannot reach. Not in the prompt, not in the agent’s own logic. In the platform, on the credential, or on the wallet. The failure mode this whole category exists to prevent is a loop at three in the morning, and no amount of careful instruction has ever stopped one.