Payments, live in one prompt

For a decade, "add payments" meant a signup form, a compliance queue, and a wait measured in business days. If you're building with an AI agent, that whole sequence is now a single sentence — and, done right, it's not a shortcut around the rules. It's a better path through them.

Every builder hits the same wall. The product works, the first users show up, and then you need to charge them. What follows is rarely the fun part: pick a processor, fill in a business profile, upload documents, wait for a review, discover you're missing a field, wait again. By the time money can move, the momentum is gone.

The reason it's slow isn't the code. It's that taking payments is a regulated act — someone has to verify who you are before real money flows through you. The industry's answer has mostly been to front-load all of that verification, which is why "instant" from most providers means instant test mode and "a few business days" for the real thing.

The slow part was never the integration. It was the identity check standing in front of it.

What "one prompt" actually does

When you tell your agent "add payments to my app", three things happen in sequence — none of them magic, all of them real:

1. Your business gets identified. The agent already knows a lot — your app, your domain, your git identity. It fills in what it can and asks only for what it can't infer.
2. A payment account is created. Not a placeholder — a real merchant vendor, in both a sandbox and a production environment, each with its own access token.
3. You go live, capped. As a sole trader you can accept payments immediately, up to a limit, before any document upload.

The output isn't a dashboard link to go finish later. It's a token your app can use to take a payment in the next minute.

Why capped-and-live is the honest version of "instant"

Here's the part most "instant onboarding" pitches skip: you cannot legally skip identity verification for payments. Regulators don't publish a magic threshold below which know-your-business disappears. What they do allow is a risk-based approach — tiering, not skipping.

So the right design isn't "no checks." It's progressive checks with a cap. You provide the minimum to establish who you are, you start accepting money up to a limited amount, and the fuller verification happens as you grow into it. If something looks off, a human reviews the exception. Speed that's risk-managed, not reckless.

This is exactly how the mature platform providers already operate under UK and EU rules — it's just usually buried behind a sales call. paas.build puts it behind a prompt.

The agent does it without a UI

The point isn't a prettier onboarding screen. It's that there doesn't need to be one. Because the whole flow is an API, your agent drives it directly — identify the business, create the vendor, take the token, wire it into your code, run a test charge. Onboarding becomes a diff in your repo, not a tab you switch to.

That's the difference between "we have an API" and "we're built for agents." Anyone can hand you docs. The question is whether an agent can go from intent to a live, capped payment account without a human clicking through anything. Here, it can.

What you keep

Speed is the hook, but it's not the whole trade. Because this is a payment-facilitator model rather than a merchant-of-record one, going live this way means you're the merchant. Your brand is on the checkout and the statement. You own the customer relationship and the data. And if your app is a platform — if your users need to get paid — that works too, which a merchant-of-record simply can't do.

You trade a five-day form for a one-line prompt, and you don't give up ownership to get it.