The Agent Economy Needs Rails: Agentic Payments and Verify-then-Pay

We’ve traced two layers of the agent stack on this blog. MCP gave agents a universal way to reach tools. A2A gave them a universal way to reach each other. There’s an obvious third layer implied by the first two, and in 2025–26 it arrived fast: once agents can find services and delegate to peers, they need a way to pay. An agent that can’t move value can browse the economy but not participate in it.

The rails showed up almost at once, from the biggest names in payments and AI — and the speed of it tells you the industry sees the same gap. But the interesting part isn’t that money can move. It’s what these protocols had to solve to make it safe, because moving money was never the hard problem.

The rails arrived fast

Within two weeks in September 2025, two open standards landed. Google announced the Agent Payments Protocol (AP2) on September 16, 2025, framing it as “an open protocol for the emerging Agent Economy” — and, tellingly, built it “as an extension for the open-source Agent2Agent (A2A) protocol.” The payment layer was designed to sit directly on top of the agent-interop layer we already wrote about. Then on September 29, 2025, Stripe and OpenAI shipped the Agentic Commerce Protocol (ACP) — “codeveloped by Stripe and OpenAI,” “an open standard” — which immediately powered Instant Checkout in ChatGPT, letting users buy from Etsy merchants inside the chat, with over a million Shopify merchants slated to follow.

Two open, backed-by-giants payment standards, two weeks apart, one built on A2A and one built into the most-used consumer AI product on earth. That’s not experimentation; that’s an industry racing to lay rails before the traffic arrives. And both made the same bet: the standard should be open, not a single company’s walled garden — the same bet that made MCP and A2A spread.

The hard problem isn’t moving money — it’s authorization

Here’s what these protocols reveal about the real challenge. Card networks have moved money reliably for decades; the technical act of a payment is solved. What’s not solved is the question agents introduce: can you trust that this agent is actually authorized to spend, and that it’s spending on what the human truly wanted?

AP2’s own framing names the gaps precisely. How do you “verify that a user gave an agent specific authority for a particular purchase”? How can “a merchant be sure an agent’s request accurately reflects the user’s true intent, without errors or AI hallucinations”? And who’s accountable when a transaction goes wrong? These are not payment-rails questions; they’re trust questions, and they’re new because the spender is now an autonomous, occasionally-hallucinating piece of software.

Think about the failure you’re guarding against. You tell your agent “order more of the coffee I like.” It picks the wrong roast, or the right roast at four times the price, or — worse — a prompt injection on some product page convinces it to buy something else entirely and ship it elsewhere. With your raw card credentials in hand, the agent can act on any of those mistakes without friction. The whole point of the new rails is to make that structurally impossible: the agent should only ever hold permission to do the specific thing you sanctioned, so a hallucinated or hijacked instruction has nothing to spend.

The protocols answer with cryptographic authorization rather than blanket access. AP2 uses mandates — a Checkout Mandate capturing the specific items and terms, a Payment Mandate authorizing a specific instrument — recorded as verifiable digital credentials, so an agent carries a tamper-evident, narrowly-scoped permission slip rather than your card. ACP takes a complementary tack with a Shared Payment Token, described as “a new payment primitive that lets applications like ChatGPT initiate a payment without exposing the buyer’s payment credentials.” Different mechanisms, same principle: the agent gets scoped, provable permission to do one thing, never your raw credentials and never unbounded authority. The engineering effort went into trust, not transfer.

Agent-to-agent commerce needs more: pay on proof, not promise

Consumer checkout — an agent buying a product for its human — is the first and easiest case. The harder, more interesting one is agent-to-agent service commerce: one agent hiring another to perform a task. There, the trust problem mutates, because you’re no longer paying for a product on a shelf; you’re paying for work that may or may not get done correctly, by a counterparty you’ve never met.

This is the gap a 2026 research system, TessPay (arXiv 2602.00213), targets — explicitly for the world where “autonomous agents can discover services, negotiate prices, and transact value.” Its objection to current rails is sharp: funds are “processed before execution, without verifiable proof of work completion.” Pay-upfront works for a known merchant; it’s reckless when the payee is an arbitrary agent. TessPay’s answer is verify-then-pay: funds are “locked in escrow while the agent executes the task and generates cryptographic evidence,” and released only “when the [Proof-of-Task-Execution] satisfies verification predicates,” with a tamper-evident audit trail for disputes. You don’t pay on a promise; you pay on proof that the work actually happened.

Make it concrete. Your research agent needs a dataset cleaned, and discovers a specialist data-wrangling agent run by a company you’ve never heard of. Pay-upfront means trusting a stranger to deliver after they’ve been paid; pay-on-delivery means the stranger trusts you to pay after they’ve worked. Neither party has any reason to extend that trust to an anonymous agent. Verify-then-pay dissolves the standoff: your funds sit in escrow the moment the job starts, the specialist works knowing the money is real and committed, and the release is automatic and conditional on cryptographic evidence that the dataset actually meets the agreed spec. Neither side has to trust the other — they both trust the protocol. That’s the same move that let strangers transact on the early web through escrow and reputation, rebuilt for counterparties that are software and may complete thousands of these deals an hour.

That inversion — escrow plus proof-of-execution — is what turns A2A delegation into A2A commerce. Without it, an open network of agents hiring each other is an open network of ways to get scammed. With it, the delegation we described in the agent internet gets an economic engine that’s safe to run between strangers.

The commerce layer of the agent internet

Step back and the stack is now visible end to end. MCP connects an agent to tools. A2A connects an agent to other agents. And this payment layer connects agents to value — letting them transact, not just communicate. Three open standards, each solving one axis, composing into the substrate of an actual agent economy rather than a demo.

And notice where the defensible work lives. It is not in moving the money — the card networks commoditized that. It’s in the trust layer: scoped cryptographic mandates, credential-free tokens, escrow-and-proof settlement, dispute-ready audit trails. That’s the part every one of these protocols poured its engineering into, because that’s the part that’s genuinely hard and genuinely new. The agent economy’s bottleneck is verification, not transfer — which is the same lesson we keep relearning one layer up.

Why this favors Southeast Asia

Here’s the part that matters for this region, and it follows the pattern we keep finding. These are open standards — ACP, AP2, and the A2A layer beneath them are not a single company’s proprietary network. That means a Cambodian or Vietnamese fintech, payments startup, or commerce platform can plug into the emerging agent economy on the same terms as anyone else, without asking a gatekeeper’s permission — the open-standards leverage we argued is Southeast Asia’s foundation. For a region where financial inclusion is a defining opportunity, open agent-payment rails are a chance to build on the new infrastructure from the start rather than inherit someone else’s closed version of it.

And the valuable work is exactly the capital-light, judgment-heavy kind the region can do. Implementing verify-then-pay for a local marketplace, designing the mandate scopes for a domestic use case, building the escrow-and-proof logic that makes agent-to-agent commerce trustworthy on local terms — none of that requires a frontier model or a GPU cluster. It requires understanding both the trust problem and the local market, and encoding the first in terms of the second. The money will move on rails anyone can use. Who gets trusted to build on them is still up for grabs — and that’s a contest decided by engineering judgment, not capital.