paas.build Go live
Agentic payments

Agents can pay.
But can they get paid?

The industry is racing to let AI agents spend money — AP2, x402, agent wallets. Almost nobody is working on the other half: the agent that just built a product and needs to earn money for its human. That half is called merchant onboarding, and it still takes a week.

The half everyone is building

Agentic payments, as the term is used today, means transactions initiated by AI agents: an agent paying an API per call, booking a service, renewing a subscription. Two building blocks dominate the conversation:

AP2 (Agent Payments Protocol) — a protocol pushed by Google and partners for agents to authorise and execute payments with user mandates: who may pay, whom, how much, with what proof.
x402 — a pattern built on the HTTP 402 "Payment Required" status code, popularised by Coinbase: a server quotes a price, the agent pays programmatically, the request retries. Machine-to-machine micropayments, no human in the loop.

Both answer the same question: how does an agent spend money safely? It's the right question — for buyers.

The half everyone forgot

Watch what agents actually do all day in 2026: they build products. A Lovable app in an afternoon, a SaaS in Cursor over a weekend. Every one of those products eventually needs to do something no spending protocol covers — accept money.

And there the agent hits a wall built for a different century: merchant onboarding. Forms designed for humans. A compliance queue measured in business days. An approval email that arrives after the momentum is gone.

Software's bottleneck has moved — from writing code to accepting payments.

The spending side got protocols. The earning side still has paperwork.

What agent-native means on the merchant side

We think agent-native payment infrastructure needs four properties — this is the checklist we built paas.build against:

1. Machine-readable everything. Docs an agent can consume in one pass (llms.txt, agents-first API references) — because the integrating developer is increasingly not a human.

2. Provisioning tools, not just management tools. Stripe's MCP can operate an account you already have. The agent-native question is one level deeper: create the account. Our MCP exposes identify_business → go_live → create_checkout — from nothing to a live merchant in one session.

3. Progressive KYB. Go live instantly with a capped, real account; verification completes in the background; the cap lifts after the first real payments. Risk is managed by limits and monitoring — not by making everyone wait a week.

4. Scoped, safe credentials. An agent should hold a token that can create checkouts — not the platform's master key.

What this looks like in practice

An agent in Claude Code, Cursor or any MCP client says: "take my business live." It identifies the business (web search), opens a real account — sandbox and production — mints scoped tokens, and mounts a checkout. First payment the same day, at 3.9% flat. The human confirms; the paperwork catches up in the background.

That's the missing half of agentic payments: agentic onboarding. When both halves exist, the loop closes — agents building products that pay for the agents' own API calls.

FAQ

What are agentic payments?

Transactions initiated by AI agents rather than humans — paying APIs per call, booking services, renewing subscriptions. AP2 and x402 are the emerging standards for the spending side.

Can an AI agent open a merchant account?

On most infrastructure, no — onboarding assumes human forms and days of review. On paas.build, yes: the go_live tool creates a real capped account in the same session, with verification in the background.

Is this real regulated infrastructure?

Yes — paas.build runs on UniPaaS, an FCA-authorised payment institution (No. 929994). The accounts, caps and verification are the real thing, not a sandbox demo.