Agentic payments: your AI agent can pay - but can it get paid?

Everyone is building rails for AI agents to spend money. Google's AP2 gives agents payment mandates. Coinbase's x402 pattern turns HTTP 402 into machine-to-machine micropayments. Agent wallets are everywhere.

But watch what agents actually do all day in 2026: they build products. A Lovable app in an evening. A SaaS in Cursor over a weekend. And every one of those products eventually needs the thing no spending protocol covers —

accepting money.

The wall every agent hits

Here's a session I've watched a hundred times:

➜ ~ claude "finish my app"
✓ scaffold   — Next.js + Tailwind
✓ UI         — components & design system
✓ UX         — onboarding flow polished
✓ auth       — Google sign-in wired
✓ database   — schema + migrations
✓ deploy     — production live
▸ application is almost ready…
✗ missing: payments

And then the agent — which just shipped a full product in one session — tells you:

"To accept payments you need a merchant account. Traditional PSP onboarding requires a compliance review — expect to wait at least a week for approval."

An app built in an evening, waiting 7 days for permission to charge £1. That's not risk management. That's a workflow designed when software took months to ship, and nobody went back to fix it.

Your other options aren't better: no company? The classic path detours through Stripe Atlas ($500) and an IRS EIN wait that stretches to weeks for non-US founders — before you can even apply.

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

What "agent-native" means on the merchant side

The spending side got protocols. The earning side needs four properties:

1. Machine-readable everything. Docs an agent consumes in one pass — llms.txt, agents-first API references. The integrating developer is increasingly not a human.

2. Provisioning tools, not just management tools. Stripe's MCP server can operate an account you already have — customers, refunds, invoices. The agent-native question is one level deeper: create the account.

3. Progressive KYB. Go live instantly with a real but capped account; verification completes in the background; the cap lifts as checks clear. Risk managed by limits and monitoring — not by making everyone wait in a queue.

4. Scoped credentials. The agent holds a token that can create checkouts — never the platform's master key.

What that looks like in practice

We built paas.build against that checklist (it runs on UniPaaS, an FCA-authorised payment institution). The MCP server is open source:

git clone https://github.com/UNIPaaS/paas-build-mcp
claude mcp add paas-build -- node paas-build-mcp/paas-build-mcp.mjs

Then, in your agent:

"take my business live"

The agent calls three tools — identify_business (web-search resolution), go_live (creates a real merchant account, sandbox and production, same session), create_checkout (payable link). Or skip MCP and hit the API directly:

curl -sX POST https://api.paas.build/api/go-live \
  -H 'content-type: application/json' \
  -d '{"business":"My App","website":"myapp.com","region":"uk"}'
# → { sandbox:{vendorId, accessToken}, production:{vendorId, accessToken} }

Individuals go live the same day, capped (~£1,500) until verification completes. No company formation. Checkout drops into React in three lines (@paasbuild/react). One rate: 3.9%.

The loop this closes

When both halves exist — agents that can pay and agents that can get paid — something interesting happens: an agent builds a product, takes it live, and the product's revenue funds the agent's own API calls. The full economic loop, no human in the critical path, humans firmly in control of the mandate.

That's agentic payments. Not just spending — earning.

I'm the co-founder & CTO of UniPaaS. We're launching paas.build this week — payments for AI builders, live the same day. If you're building with Lovable, Bolt, Cursor or Claude Code, I'd genuinely love to hear where payments hurt: the guides for each platform are here.