AI agent payment protocols answer a narrow but difficult question: how does software buy a resource without pretending to be a person at a checkout page? The answer is not one standard. x402 and MPP focus on a paid HTTP resource. ACP focuses on structured agent checkout. AP2 focuses on proving that a person authorised an agent to buy. Visa’s Trusted Agent Protocol focuses on merchants recognising a trusted agent and handling credentials. MCP and A2A sit below that payment layer: one connects an agent to tools and data; the other lets agents coordinate.
The economic context is straightforward. A model call can be a metered service, just like a search request or an API lookup. The hard part is turning a price, an authorisation, a payment proof and a result into a transaction a machine can retry safely. These protocols split that job differently. That makes the choice less about declaring one winner and more about matching the protocol to the point of failure.
AI agent payment protocols compared
| Protocol | Builder | Job | What it settles or carries | Current maturity |
|---|---|---|---|---|
| x402 | Coinbase, now stewarded through the x402 Foundation | Turns HTTP 402 Payment Required into a machine payment challenge and retry. | Payment proof; designed to be blockchain-agnostic, with stablecoins such as USDC prominent in early flows. | Open standard with public implementation material and ecosystem activity. |
| MPP | Stripe and Tempo | Lets clients pay for HTTP resources, including APIs, in the request flow. | A Credential and Receipt; the protocol can support stablecoins, cards and bank transfers. | Open IETF-oriented specification with SDKs and documented payment flow. |
| ACP | Stripe and OpenAI | Provides a deterministic agent-to-merchant checkout interface. | Buyer choices and securely relayed payment credentials while the merchant retains its processor. | Public specification and implementation documentation for merchant endpoints. |
| AP2 | Establishes evidence that a user authorised an agentic purchase. | Cryptographically signed verifiable digital credentials and mandates; initial scope covers common pull methods such as cards. | Open protocol documentation, including an A2A extension and a published v0.2 release. | |
| TAP | Visa | Lets a merchant verify a trusted agent and receive transaction-specific credentials. | Merchant- and purpose-specific, time-bound signatures plus payment information suited to the merchant flow. | In development and deployment; Visa says availability can vary by market. |
The rows do not describe substitutes at the same layer. x402 and MPP are closest when an agent needs to pay for a single API result. ACP is the more natural fit for shopping carts, shipping choices and merchant checkout. AP2 addresses the authority question that remains even after an agent can technically move money. TAP addresses merchant-side trust: is this automated client one that the merchant should accept, and can it present verifiable credentials?
MCP and A2A are underneath, not payment rails
MCP gives an AI application a standard way to connect to tools, data sources and workflows. A2A gives independently built agents a way to communicate and delegate work without exposing their internal systems. Neither standard settles a charge. In a practical stack, an MCP tool might expose a paid model endpoint; an A2A worker might request a result from another agent; a payment protocol then supplies the challenge, proof, authority or merchant-recognition mechanism needed to complete the paid part.
That distinction matters in design reviews. Adding MCP does not answer who can spend, what limit applies, or what evidence survives a dispute. Adding A2A does not make a receiving service willing to accept an automated purchaser. Payment policy still needs an owner. Set a per-request ceiling, a merchant allowlist, an idempotency key and an audit record before granting an agent access to a chargeable tool.
A paid Wiro model request, step by step
Here is a concrete resource: one 1K output from Google Nano Banana Pro on Wiro. The two fresh runs made for this guide completed in 20 and 21 seconds, respectively, and each recorded a billed cost of $0.14. Those are observed billed costs from the completed Wiro tasks, not a quoted x402 price and not a claim that Wiro currently exposes x402.
The protocol trace below shows how a provider could sell that same kind of model output per request through a 402-style flow. The number is deliberately concrete: the server advertises $0.14 for one 1K image request, matching the measurement taken here. A production server would still need to define the supported method, currency, expiry and replay protection.
- Request. The agent sends a POST to an image-generation endpoint with its prompt, resolution and idempotency key. The request contains no result yet.
- 402 with price. The endpoint responds
402 Payment Required. Its challenge says that one 1K result costs $0.14 and names the accepted payment method and deadline. This is the pattern x402 and MPP make programmatic rather than a browser checkout. - Payment. The agent checks its delegated policy: this request is within its $0.20 ceiling and the model provider is allowed. It fulfils the challenge through the selected method.
- Retry with proof. The agent resends the exact request with payment proof. A server verifies the proof and binds it to the idempotency key, so a network retry does not create a second charge.
- Result. The endpoint returns
200 OK, a result location and a receipt or equivalent delivery evidence. The agent records the task ID, billed amount, elapsed time and output reference for reconciliation.
The measurement shows why receipts and idempotency are not paperwork. A 20- to 21-second model job spans enough time for a client timeout, a worker retry or a duplicate delivery attempt. The payment layer must let the client distinguish “not paid”, “paid but no result yet” and “result delivered”. MPP explicitly describes a Challenge, a Credential and a Receipt for that sequence. That maps cleanly to a metered inference service.
Choosing an implementation path
For a paid API call, begin with the HTTP-native protocols. x402 frames the interaction around HTTP 402 and payment proof. MPP’s overview specifies a similar request-and-retry shape while making its Credential and Receipt explicit and remaining neutral about underlying payment methods. Both fit an API where price discovery and a retry are the main concern.
For a purchase that looks like commerce rather than a single API response, ACP, AP2 and TAP solve different constraints. ACP standardises the agent-to-seller checkout exchange while leaving the merchant’s existing payment stack in place. AP2 adds cryptographic mandates that document user intent and authorisation. TAP gives merchants a way to recognise and verify an agent’s purpose-specific messages. AP2’s protocol documentation is a useful reference for the mandate model; Visa’s TAP documentation should be checked for programme and market availability before an implementation decision.
The practical architecture is modest: keep tool access through MCP, delegate work through A2A where it helps, and place a payment protocol at the paid boundary. Do not ask a single protocol to solve pricing, authorisation, settlement, merchant trust and inter-agent coordination by itself. Measure the real request cost and elapsed time, then set policy around those observed numbers. Run and scale metered model workloads on Wiro.
