DEV Community

oded-unipaas
oded-unipaas

Posted on

An AI agent opened an FCA-regulated merchant account in one prompt - full log

#ai #agents #mcp #payments

I'm Oded Kovach, co-founder and CTO of UniPaaS, the FCA-authorised Payment Institution (No. 929994) behind paas.build. Affiliation disclosed up front: this is our product, and what follows is a real session log from our public endpoint - tokens redacted, everything else verbatim.

On 2026-07-15 at 15:43 UTC, an AI agent connected to https://paas.build/mcp, identified a business, opened a real sandbox merchant account on regulated rails, and created a checkout link you could pay. Five JSON-RPC calls. 16 seconds between the first timestamp and the last. Here is each step.

Step 1 - initialize (15:42:47, 1.1s) 

-> {"method":"initialize"}
<- {"protocolVersion":"2025-03-26","serverInfo":{"name":"paas.build","version":"0.2.0"}}
Enter fullscreen mode Exit fullscreen mode

Standard MCP handshake. Nothing interesting yet, except that this is the same public endpoint anyone can hit.

Step 2 - tools/list (15:42:48, 0.7s)

The server exposes exactly three tools:

  • identify_business - resolve a name, website or free-text phrase into a business profile (Opus with live web search)
  • go_live - create a real payment vendor via progressive KYB and return scoped access tokens
  • create_checkout - create a hosted checkout session and return a payable shortLink

Three tools, not thirty. An agent choosing between thirty tools misroutes; three is a path.

Step 3 - identify_business (15:42:56, 8.4s)

Input: "a ceramics studio in Brighton". Output, abridged:

{"ok":true,"data":{"business":null,"what":"Ceramics studio and pottery classes",
 "country":"United Kingdom","region":"uk","confidence":"low"}}
Enter fullscreen mode Exit fullscreen mode

The slowest step, because it runs a live web search. Note what it did not do: it did not invent a business name. business is null and confidence is "low", and that gets passed downstream honestly.

Step 4 - go_live (15:43:02, 6.2s)

The call that sounds fake and is not:

-> {"tool":"go_live","arguments":{"business":"Brighton Ceramics Studio","region":"uk","env":"sandbox"}}
<- {"ok":true,"type":"individual","sandbox":{
     "vendorId":"6a57aa812c5dff5462437ec8",
     "onboardingStatus":"ACCEPT_PAYMENTS",
     "acceptPayments":true,
     "tokenScope":"create_checkout_only"}}
Enter fullscreen mode Exit fullscreen mode

6.2 seconds later there is a real vendor in the UniPaaS sandbox: 6a57aa812c5dff5462437ec8. Status ACCEPT_PAYMENTS, opened as an individual - no company number was supplied at any point. The returned access token is scoped to create_checkout_only, deliberately: the agent gets the narrowest capability that finishes the job, not portal credentials.

This is possible because of progressive KYB: verification runs in stages instead of all upfront. Individuals and sole traders go live immediately, capped at £1,500 until verification completes; then the cap lifts. The cap is the mechanism that makes same-day onboarding legal on FCA-supervised rails. It is a regulatory design, not a growth hack.

Step 5 - create_checkout (15:43:03, 0.8s) 

-> {"arguments":{"env":"sandbox","vendorId":"6a57aa812c5dff5462437ec8",
    "amount":18,"currency":"GBP","reference":"workshop ticket"}}
<- {"ok":true,"shortLink":"https://sandbox-checkout.unipaas.com/gMVQo28YW9/"}
Enter fullscreen mode Exit fullscreen mode

That link was payable with test card 4761 3441 3614 1390. End of session: one prompt in, a merchant account and a payable £18 checkout out.

The timing, added up

Summed call latency across the five steps: 17.2 seconds (1.1 + 0.7 + 8.4 + 6.2 + 0.8). The two heavy steps are the live web search and the vendor creation; the checkout itself is sub-second. The structural point: there is no queue anywhere in the path. No review inbox, no human approval step, nothing async between the prompt and the payable link - the risk control is the processing cap, not a waiting period.

Reproduce it yourself

This is not a video you have to trust. The endpoint is public; run the same calls:

claude mcp add paas-build -- npx -y @paasbuild/mcp
# then tell your agent: "open me a merchant account and create a checkout"
Enter fullscreen mode Exit fullscreen mode 
curl -X POST https://paas.build/mcp -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
Enter fullscreen mode Exit fullscreen mode

The interactive replay of this exact session, with the full raw JSON, is at paas.build/demo.

Honest limitations

  • This log is sandbox. Production works the same way (the go_live tool provisions sandbox and production by default; this session requested sandbox only), and a production account is capped at £1,500 until verification completes.
  • UK, EU and US businesses only. Buyers can pay from anywhere.
  • We are a payment facilitator, not a Merchant of Record. You stay the merchant, which means VAT/sales tax stays yours. If you want global tax handled for you, an MoR like Paddle is the better pick.
  • identify_business returned low confidence on a vague one-line input. That is correct behavior, but it means a real agent should confirm business details with its human before passing them to go_live.

The interesting part, to me, is not the 16 seconds. It is that account opening became a tool call. The onboarding funnel - the thing every payments company optimizes with forms, emails and review queues - can now be a single hop in an agent's plan, with the risk control moved into a processing cap instead of a waiting room.

Top comments (0)