The MCP payment void: why the winning agent standard cannot move money

MCP is the settled part of the agent stack. It gives a host application, its client, and a server a common way to talk over JSON-RPC 2.0, so an agent can discover what a business exposes and act on it. That is the integration problem, and it is largely solved.

What MCP is not is a payments rail. The specification names its primitives plainly: resources, prompts, and tools server-side, sampling, roots, and elicitation client-side. No billing primitive. No settlement primitive. No money-movement capability of any kind. The security model rests on user consent and control plus tool safety, not financial authorization. This is not an oversight waiting for a patch. It is a scope decision. MCP connects; it does not clear funds. The current spec has none, and no primary source backs a roadmap claim that it will add one.

Read that as a boundary, not a gap. A protocol that does one layer cleanly beats one that smears integration and settlement together. The cost is real: anyone building agentic commerce has to pick a second protocol for the money, and that pick is not made for them yet.

Where MCP is settled, payment is a live standards war with several serious entrants and no winner. Hold the fault line in your head: connection is one layer, money is another.

Stripe's agentic commerce documentation makes the fragmentation concrete. For selling through agents it lists two protocols, UCP and ACP, and for accepting machine payments it lists MPP and x402. Four named options in one vendor's documentation, and two of them (UCP and MPP) appear only as supported options there, not as independently ratified standards. Google maintains a fifth entrant, the Agent Payments Protocol, currently at v0.2.0 dated 2026-04-28 and explicitly pre-1.0, under its google-agentic-commerce organization, with the tagline "Building a Secure and Interoperable Future for AI-Driven Payments."

Pre-1.0 version numbers and a crowded field are the tell. The money layer has not converged. Anyone who tells you the payment standard for agents is decided is describing a wish, not the specifications.

One payment protocol already rides on MCP, and that fact makes the two-layer structure plain. The Agentic Commerce Protocol was developed jointly by Stripe and OpenAI, is open source under Apache 2.0, and works with a traditional API or with MCP. MCP is a transport ACP can ride on. The payment protocol treats the integration protocol as plumbing beneath it.

That layering is the whole point. ACP does not process payments directly. It passes payment credentials from buyers to agents without exposing the underlying credentials, using a Shared Payment Token, and works with any compatible payment service provider, with Stripe named as the first compatible one. On the model side, OpenAI describes ACP as the connective layer between merchants and ChatGPT, letting ChatGPT ingest structured catalog data, understand merchant inventory, and surface relevant products in context. Notice what carries the weight there: structured catalog data. The agent can only act on a business it can read in structured form. The payment protocol assumes the integration layer is already clean.

Google's AP2 makes the same architectural bet from a different direction. It ships its specification, flows, and FAQ with reference samples in Python, Go, and Android, and does not require Google's Agent Development Kit or Gemini. Different governance model, same separation of concerns: connect first, authorize the money second.

Read ACP and AP2 side by side and one primitive shows up in both. ACP carries a Shared Payment Token, a credential the buyer authorizes that the agent presents without ever seeing the raw payment details. AP2 is built around a mandate model that separates a buyer's general intent from a specific authorized cart, and ties that authorization to the specific transaction. The field-level schemas differ and are still moving, so treat the mandate model qualitatively. But the shape is consistent: before money moves, there must be a verifiable record that a human authorized this specific action.

That is not a payments feature. That is a governance primitive. Proof of authorization is the confirm-step, the human-in-the-loop checkpoint, the access boundary, expressed in the language of money. ACP and AP2 land on the same answer even while they disagree on the wire format.

This reframes the whole problem. The hard part of agentic commerce is not picking a payment vendor. It is being able to prove, on demand, that an action an autonomous agent took was authorized, scoped, and recorded. A business that cannot represent authorization cleanly cannot safely let an agent transact for it, no matter which protocol wins.

Faced with a payment-standards war, the instinct is to wait for a winner or to bet on a vendor. Both miss where the actual work sits. The work is upstream of the money.

Three things have to be true before payment protocol choice even matters. The agent has to read your business in structured, machine-readable form, which is what every connective layer above assumes. The actions it can take have to be bounded, so an agent reading your catalog cannot also drain an account. And every action has to leave an authorization record, the same proof-of-authorization primitive these payment protocols are reaching for. Get those right and the payment protocol becomes a thin, swappable adapter at the edge. Get them wrong and no payment standard saves you, because the agent is acting on an ambiguous record with no governed confirm step.

So the right sequence is integration and governance first, payment rail last. The integration layer is settled, so build to it now. The governance layer, proof of authorization, scoped action, audit trail, is the part you control, and the part that does not depend on which of the five protocols ratifies first. When one does, you plug it in.

Origin Pi builds the agent-ready business layer, the structured and governed record an agent reads before it acts. That record is exactly the surface the payment protocols assume already exists. Our agentic business layer makes the business machine-readable and bounds what an agent may do, with the confirm-step and audit trail that proof-of-authorization rails depend on. Our sales automation work is where this lands first, because selling through agents is where read, authorize, and settle meet. Get the governed integration surface right, and whichever payment protocol wins becomes a thin adapter you swap in, not a foundation you bet the business on.

Does the Model Context Protocol handle payments? No. The MCP specification (revision 2025-11-25) defines six primitives, resources, prompts, and tools on the server side, and sampling, roots, and elicitation on the client side. None of them moves money. MCP covers context and tool execution, not settlement.

If MCP does not move money, what does? A separate and still-contested payment stack. Stripe's agentic commerce documentation lists UCP and ACP for selling through agents and MPP and x402 for accepting machine payments, and Google maintains the Agent Payments Protocol (AP2, v0.2.0, pre-1.0). No single payment standard has been ratified.

Can a payment protocol work with MCP? Yes. The Agentic Commerce Protocol, developed jointly by Stripe and OpenAI and open source under Apache 2.0, works with a traditional API or with MCP, treating MCP as transport beneath it.

What should a business build first, integration or payments? Integration and governance first. The integration layer is settled, so make your business machine-readable, bound what an agent may do, and record every authorized action now. The payment rail is the last, swappable piece once a standard ratifies.

• The MCP specification (revision 2025-11-25) defines resources, prompts, and tools server-side and sampling, roots, and elicitation client-side, with no payment, billing, or settlement primitive.
• Google's Agent Payments Protocol (AP2) is at v0.2.0, dated 2026-04-28, maintained under the google-agentic-commerce organization, pre-1.0, with the tagline about a secure and interoperable future for AI-driven payments.
• The AP2 repository ships specification, flows, and FAQ with reference samples in Python, Go, and Android, and does not require Google's Agent Development Kit or Gemini.
• The Agentic Commerce Protocol was developed jointly by Stripe and OpenAI, is open source under Apache 2.0, and works with a traditional API or with MCP. It passes payment credentials via a Shared Payment Token without exposing underlying credentials, with Stripe named as the first compatible PSP.
• OpenAI describes ACP as the connective layer between merchants and ChatGPT, enabling ChatGPT to ingest structured catalog data and surface relevant products in context.
• Stripe's agentic commerce documentation lists UCP and ACP for selling through agents, and MPP and x402 for accepting machine payments.