DEV Community: oded-unipaas

I scanned 53 platforms to see if an AI agent can actually pay on them. The AI companies scored worst.

oded-unipaas — Sun, 26 Jul 2026 15:31:53 +0000

Disclosure first, because it matters for how you read this: I'm the CTO of UniPaaS, an FCA-authorised payment institution, and we build paas.build. We also built the index this post is about, and yes, our own site sits at the top of it. So read everything below with that in mind. To make it fair I'm publishing the full rubric and every site's evidence, so you can check the math or disagree with it. I'll also point out where our own scoring is weak.

The question

AI agents are starting to buy things. Not "soon", now: people are wiring up assistants that book, subscribe and pay. So I got curious about a boring but important question. If an agent lands on a website, can it actually figure out what the site does, find the thing to buy, and pay? Or does it hit a wall of JavaScript and marketing copy?

There's already solid work on the retail side of this. Digital Commerce 360 and ReFiBuy rank the top 1000 stores for AI shopping readiness, and a few others score individual ecommerce sites. I wanted to look one layer down, at the infrastructure: the app builders, the payment providers, and the AI companies themselves. If the tools and the rails aren't agent-ready, the stores sitting on top of them can only get so far.

So I scanned 53 of them: AI app builders, payment providers, and the big AI companies. Then I turned it into a public leaderboard, the Agentic Checkout Index.

How the scan works

Every site gets the same objective checks, no opinions, grouped into five buckets worth 100 points:

Discoverability (25): robots.txt, sitemap.xml, and especially llms.txt / llms-full.txt, the plain-text summary files agents read.
Structured data (20): JSON-LD, typed schema (Organization, Product, FAQ), OpenGraph.
Agent endpoints (25): an OpenAPI spec, a .well-known/ai-plugin.json, and an MCP server. This is how an agent actually calls you instead of guessing.
Content clarity (15): a real h1, semantic HTML, and whether the page is readable without running JavaScript.
Payments signals (15): is a payment provider detectable, is there a pricing page, is there a visible checkout path.

Each check shows its evidence, the exact URL requested and what came back, so nothing is hand-wavy. It's HTTP GETs, no JS execution, which is roughly how a lot of agents read the web today.

What came back

The average score across 53 sites was 52 out of 100. Twenty-one of them, nearly 40 percent, scored an F.

The part I did not expect: the AI companies were at the very bottom.

perplexity.ai: 10
openai.com: 33
anthropic.com: 37

The companies building the agents have almost nothing an agent can mechanically read on their marketing domains. No llms.txt, no structured data an agent can parse, content that only appears after JavaScript runs. Now, a fair caveat: these are heavy single-page apps, and my scan reads the served HTML, not the JS-rendered version. But that's also kind of the point. If your value only exists after a full browser renders it, a lightweight agent fetch sees a near-empty page.

The AI app builders landed in the middle: Lovable, Base44 and Cursor at 62, Adalo at 67, while Bolt (49) and Bubble (37) trailed. So the tools people use to build apps are only partly ready for agents to transact inside those apps.

Payments was a mixed bag. Among payment companies, Dodo Payments (67) came out ahead of Stripe's marketing site (57) and Paddle (52). Interestingly, docs.stripe.com scored lower (40) than Stripe's homepage, and for a developer product the docs are the surface an agent actually hits.

Two sites got an A: render.com (82) and paas.build (89). Render earns it with clean structure and real endpoints. Ours scores high because we deliberately built for this: llms.txt, JSON-LD, an OpenAPI spec, a live MCP server, server-rendered pages. That's not a coincidence and I'm not going to pretend it is. It's the whole thesis of the product.

Where my own scoring is weak (so you can judge it)

It reads homepages and well-known paths, not the full site. A great checkout buried three clicks deep won't be seen.
No JavaScript execution penalizes SPAs, which is partly fair (agents often don't render) and partly harsh.
"Payment provider detectable" only looks at script and link tags on the homepage, so a site that loads its checkout later looks empty.

I'd rather state those plainly than pretend the number is gospel. If your site scored low and you think it's wrong, the evidence is right there on your page and you can ask for a rescan.

The actual takeaway

If you want an agent to be able to buy from you in 2026, the boring checklist is: publish an llms.txt, put real JSON-LD on the page, expose an OpenAPI spec and ideally an MCP endpoint, make sure the page says what it is without JavaScript, and keep a clear pricing and checkout path. None of that is exotic. Most sites just haven't done it yet, which is why the average is 52.

The full leaderboard and every site's evidence is here, updated as sites get rescanned:

https://paas.build/score/

If you work at one of the sites near the bottom, this is a genuinely fixable afternoon of work, and I'd love to watch the score move.

Stripe Connect is overkill for most marketplaces. The lighter path (2026)

oded-unipaas — Sun, 26 Jul 2026 09:36:49 +0000

Disclosure up front: I'm Oded, co-founder of UniPaaS, the FCA-authorised Payment Institution (No. 929994) behind paas.build. So I have a horse in this race. The framework below holds whoever you pick - I've tried to be fair about when Stripe Connect is the right answer, because often it is.

The setup

You're building a marketplace, a community with paid creators, a booking app that pays venues - anything where money flows from your users to your other users. You reach for Stripe Connect, because that's the default answer. And Connect is genuinely excellent infrastructure.

But "we need Connect" is one of those decisions people make on autopilot, and for a lot of platforms it's more than they need - with real cost.

What Connect actually asks of you

Full Connect - the model where you own the platform experience - means you're on the hook for:

Onboarding every seller through KYC yourself. Each connected account needs identity and banking verification before it can be paid. You build and maintain that flow.
Platform liability. With the common separate-charges-and-transfers setups, chargebacks and negative balances can land on your platform account.
The build. Connect onboarding, payout scheduling, the dashboard your sellers expect - that's weeks of engineering, and it isn't your product.
Time to first payout. Your sellers can't get paid until they clear Stripe's verification, and newer platforms get held for review.

If your team is happy owning all of that, Connect is a great choice - use it. The rest of this is for platforms that reached for Connect and then realised they'd signed up to build a payments company on the side.

What most platforms actually need

Strip it back and the requirement is usually just two things:

Take a payment from a buyer.
Split it and pay out to one or more of your own users, on a schedule, minus your cut.

That's it. You don't necessarily need to become the payments platform to do that.

The lighter path: sub-merchant payouts on a PayFac

A payment facilitator (PayFac) can onboard your users as sub-merchants and split each payment to them directly, with the regulated liability sitting on the institution rather than on you. In practice:

Progressive KYB onboards your sellers in-app and lets them go live the same session with a cap, verification completing in the background - instead of a hard gate before anyone can transact.
Real-time splits to unlimited sub-merchants, so a booking or sale pays the venue or creator and takes your fee in one move.
The liability sits with the licensed institution, not your platform balance.
You don't build Connect. Onboarding, splits and payouts are the provider's surface, not your roadmap.

	Stripe Connect (full)	PayFac sub-merchant (e.g. paas.build)
Seller onboarding	You build the KYC flow; hard gate before payout	Progressive KYB in-app; live the same session with a cap
Who holds liability	Can land on your platform account	Sits with the licensed institution
Time to first payout	After each seller clears verification	Same session, capped until verified
What you build	Onboarding, splits, payout dashboard	Little - it's the provider's surface
Best for	Deep marketplace customisation, at scale	Platforms that just need to pay out their own users

Honest limitations

Region. paas.build serves builders in the UK, EU and US. Buyers can pay from anywhere, but if your platform entity is elsewhere, this doesn't unblock you.
Tax. You and your sellers stay the merchants of record, so tax is yours (with tooling). If you want tax fully outsourced, that's a Merchant of Record - a different category, and not built for paying third parties anyway.
Scale. If you're at Uber scale with bespoke flows, full Connect's flexibility earns its complexity.

When Stripe Connect is still the right call

Be honest with yourself: if you need deep marketplace customisation, you're already deep in the Stripe ecosystem, or you want to own the payments platform as a differentiator - use Connect. It's the most flexible tool in the category.

But if you reached for Connect just to pay out to your own users, and you'd rather ship your actual product, a PayFac with sub-merchant payouts is the lighter path. I wrote up the specifics for our version here: https://paas.build/stripe-connect-alternative

Can you accept payments without a company in the UK? (2026, practical answer)

oded-unipaas — Thu, 16 Jul 2026 01:27:29 +0000

Disclosure up front: I'm Oded Kovach, co-founder and CTO of UniPaaS, an FCA-authorised Payment Institution (No. 929994). We operate a payment product in exactly this space; it is mentioned once below and marked clearly. Everything else is plain mechanics.

Q: Can I legally accept payments in the UK without a limited company?

Yes. A sole trader is a normal, legal way to run a business in the UK; you can trade under your own name without forming a company. The blocker was never the law. The blocker is merchant onboarding: most providers' underwriting assumes a company number, a trading history and a review queue, so "no company" reads as "decline" even when the business is real.

Q: So what are the actual options in 2026?

Three, in practice:

A Merchant of Record (Paddle, Lemon Squeezy and similar)
A payment facilitator (PayFac) with progressive KYB - the newer path for individuals
Form a company first and go the classic route - fine, but it front-loads cost and admin before you know whether anyone will pay

Q: What does a Merchant of Record actually do?

An MoR becomes the legal seller of your product. Your customer buys from Paddle; Paddle pays you. Two big consequences. First, they handle global VAT/GST for you - genuinely valuable if you sell worldwide. Second, their risk team owns your approval: your product has to fit their catalogue, and individuals with thin history get rejected regularly. Typical price: 5% + $0.50 per transaction.

Q: And a PayFac?

You stay the merchant. Your name on the checkout, your customer relationship, your own merchant account - and your tax obligations. The PayFac sits underneath, aggregating many small merchants onto regulated rails so you do not need your own acquiring relationship.

Q: What is progressive KYB, and what is the £1,500 cap about?

Traditional KYB (Know Your Business) verifies everything upfront, which is why onboarding takes days. Progressive KYB verifies in stages: you get a live account the same day, capped at £1,500 of processing until verification completes, then the cap lifts. The cap is the point, not the catch - bounded exposure is what makes same-day onboarding legal and safe under FCA supervision. If someone offers you an instant merchant account with no cap and no staged checks, that should worry you.

Q: What does it cost on a real ticket, say a $9 subscription?

PayFac at 3.9% flat, no fixed fee: 35c
Stripe-style card pricing: about 56c
MoR at 5% + $0.50: 95c, which is 10.6% effective

The fixed fee is what hurts at small tickets. A hundred $9 subscribers for a year is roughly $421 in fees at 3.9% flat versus $1,140 at MoR pricing. At a $50 ticket the gap narrows a lot; do the math at your own price point.

Q: When is Paddle genuinely the better answer?

When tax-handled-for-you matters more than fees and brand ownership. If you sell into many countries and the thought of VAT/GST registrations is what stops you shipping, an MoR earns its 5% + $0.50. That is real work they do; no point pretending otherwise.

Q: Who does the progressive-KYB PayFac thing for individuals?

The one I work on is paas.build (ours - see the disclosure above): individuals and sole traders in the UK, EU and US go live the same day, £1,500 cap until verified, 3.9% flat, and there is an MCP server so a coding agent can open the account. I will not pitch beyond that; the mechanics above are the useful part, whoever you pick.

Q: What about tax if I go the PayFac route?

It stays yours. You are the seller of record, so VAT rules and income tax on sole-trader earnings are your responsibility, the same as any sole trader invoicing clients. A PayFac moves the money; it does not do your taxes. Budget for that honestly before choosing this path over an MoR.

Q: Bottom line?

Yes - you can accept payments in the UK without a company, as a sole trader, through a progressive-KYB PayFac, live the same day and capped until you verify. Pick an MoR instead if global VAT is the real fear. And always do the fee math at your actual ticket size, not on the headline percentage.

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

oded-unipaas — Thu, 16 Jul 2026 01:27:21 +0000

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"}}

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"}}

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"}}

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/"}

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"

curl -X POST https://paas.build/mcp -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

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.

Why UniPaaS built paas.build

oded-unipaas — Thu, 16 Jul 2026 01:26:58 +0000

I'm Oded Kovach, co-founder and CTO of UniPaaS, an FCA-authorised Payment Institution (No. 929994). paas.build is our product, so read everything below with that bias declared. This is the story of why we built it.

The company behind it

UniPaaS is not new. UNIPaaS Financial Services Ltd has been a registered UK company since 2019 (Companies House no. 12314440), is authorised by the FCA as a Payment Institution, and has processed embedded payments and payouts for UK software platforms since 2020. Settlement runs on J.P. Morgan banking rails. Client funds sit in safeguarded accounts, segregated from company money, as the Payment Services Regulations 2017 require. The founding team came out of SafeCharge, the payments company acquired for roughly $900M.

I put all of that first because the rest of this post describes something that sounds too fast to be legitimate, and the only honest way to open is to be checkable. Look us up yourself: register.fca.org.uk, search 929994.

What we kept watching

For years our customers were software platforms: established companies embedding payments for their users. Then who builds software changed. People started shipping working apps with Lovable, Bolt, Cursor or Claude Code in a weekend - real apps, real users - and then hit a wall that has nothing to do with code.

The pattern repeats:

A Merchant of Record rejects them. It is not personal. An MoR becomes the legal seller of your product, so its risk team owns your risk, and a thin trading history in an AI-adjacent category is an easy decline.
Stripe-style onboarding assumes an established company. No company, no account.
Forming a company just to find out whether anyone will pay £9/month is backwards.

We call this the KYB wall. Know Your Business checks were designed to run all upfront: company number, documents, directors, trading history, then a review queue measured in days. That model fits businesses that already exist on paper. The new builders exist in a repo.

Progressive KYB

The fix was not new rails - ours have run since 2020. It was re-sequencing verification.

Progressive KYB verifies in stages instead of all upfront. An individual or sole trader in the UK, EU or US gets a live merchant account the same day, capped at £1,500 until verification completes. Then the cap lifts. The cap is not fine print we bury; it is the regulated mechanism that makes same-day onboarding legal and safe: bounded exposure while the checks run, full verification before the account scales.

We state the cap proudly for a reason. On a payments product, "instant, no checks" should scare you. "Instant, capped, checks staged" is a different sentence.

The agent part

The second thing we noticed: the new builders often are not filling in forms at all. Their coding agent does the work. So we exposed onboarding the way agents consume things - as tools, not screens.

paas.build runs an MCP server with three tools: identify_business, go_live, create_checkout. An agent connects, identifies the business, opens a real account and returns a payable checkout link. One prompt end to end. We recorded an unedited, timestamped session of exactly this happening and published the raw log at paas.build/demo - the vendorId in it is real. Judge it yourself.

To try it: claude mcp add paas-build -- npx -y @paasbuild/mcp, or POST to https://paas.build/mcp directly.

The honest boundaries

We are a payment facilitator, not a Merchant of Record. You stay the merchant: your brand on the checkout, your customer - and your tax. If you want global VAT/GST handled for you, Paddle is genuinely the better pick, and we say so on our own pages.
UK, EU and US businesses only for now. Buyers can pay from anywhere.
£1,500 cap until verification clears.
3.9% flat, no fixed fee. On a $9 subscription that is 35c, against 95c at a typical 5% + $0.50 MoR. Fixed fees are what kill small tickets.

Why write this at all

Because a payments domain you have never heard of claiming "live account today" pattern-matches to fraud, and it should. The counter is not louder copy. It is a named human, a regulator's register entry you can search, and a reproducible session log. That is what we have.

Questions - ask me directly at paas.build/contact. I am the CTO, so the answer is real, not a form.

Adding real payments to a Base44 app (3 insertion points, tested)

oded-unipaas — Fri, 10 Jul 2026 06:39:06 +0000

Disclosure up front: I'm Oded, co-founder of UniPaaS, the FCA-authorised Payment Institution (No. 929994) behind paas.build - so this is a vendor writing about his own product. That said, the three Base44 mechanics below are documented Base44 surfaces, and they work with any external payments API, not just ours.

The wall

Tell Base44 "add payments" and it installs Stripe or Base44 Payments (powered by Wix), plus Tranzila/Max for Israel. Both main options are solid if you qualify: Stripe is excellent infrastructure with first-class docs, and the Wix-powered option is native to the platform. The fine print is where builders hit a wall:

Stripe live mode needs verified business and banking information before you can take a real payment.
Base44 Payments requires "a business and bank account based in one of the supported countries" (their docs).
The top payments request on Base44's own feedback board is "a way to setup other payment providers other than Stripe" - precisely because not every country is supported.
Base44 webhooks only fire while someone is actively using your app, so 3am subscription renewals, retries and dunning silently don't run.

If you have a registered company in a supported country and mostly sell one-off purchases, use the built-in Stripe path. It's the smoothest. The rest of this post is for everyone else.

Base44 gives you three documented ways to wire in an external provider. I tested all three with paas.build. Here's each, and when it fits.

Insertion point 1: custom MCP connection (build-time)

In Base44: Settings → Account → MCP connections → Add custom MCP.

Name:       paas.build
Server URL: https://paas.build/sse
Auth:       API key (your paas.build key)

That's the legacy SSE endpoint Base44's form takes; streamable HTTP lives at https://paas.build/mcp for agents that support it.

Base44's AI treats MCP connections as tools it can call when your request needs external data or actions. So in the editor chat you can say "use paas.build to create a live merchant account and a checkout" and it calls identify_business, go_live and create_checkout directly.

When it fits: provisioning the account and scaffolding the flow. One real limit: Base44 runs MCP in the editor chat while you build, not at app runtime. Use it to open the account and generate the code, then one of the two runtime paths below to actually charge customers.

Insertion point 2: custom integration via OpenAPI (runtime)

A workspace admin registers the OpenAPI spec once: https://paas.build/openapi.json. Your API key is stored as an encrypted workspace secret, and your app calls the integration at runtime:

const { shortLink } = await base44.integrations.custom.call(
  "paasbuild", "createCheckout",
  { vendorId, amount: 29, currency: "GBP" }
);

When it fits: you want runtime charging without writing server code, and you're fine with a workspace admin owning the setup. It's the cleanest separation of secrets from app code.

Insertion point 3: backend function (runtime, universal)

Base44 backend functions run on the server, so secrets live in environment variables and you can fetch any external API:

// Base44 backend function
export default async function createCheckout({ amount }) {
  const r = await fetch("https://paas.build/api/checkout", {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({
      vendorId: Deno.env.get("PAAS_VENDOR_ID"),
      amount, currency: "GBP"
    })
  });
  return await r.json(); // { shortLink, sessionToken }
}

When it fits: you want full control - custom logic around the charge, your own error handling, no dependency on a workspace admin. This is the path I'd default to for anything beyond a demo.

Why bother: the no-company, unsupported-country wedge

The reason to reach past the built-ins at all:

No company needed. paas.build uses progressive KYB: a real merchant account (sandbox and production keys) the same session, individuals and sole traders included, live immediately with a cap of roughly £1,500 while verification completes in the background.
Renewals actually run. You're the merchant on rails that run 24/7 server-side, so recurring billing, failed-payment retries and dunning don't depend on someone having your app open.
Pricing at small tickets. 3.9% flat, no fixed fee. On a $9 subscription that's $0.35, versus $0.95 under the 5% + $0.50 pattern you'll see at typical Merchant-of-Record providers - an effective 10.6%.

Honest limitations

UK, EU and US only on the merchant side. Buyers can pay from anywhere, but if you as the builder are registered outside those regions, paas.build does not unblock you, and that Base44 feedback-board request stays open for you.
Tax is yours. You stay the seller of record, so VAT and sales tax are your responsibility. If you want tax handled for you globally, a Merchant of Record is the right category instead.
The cap is real until verification completes. Plan for it if you expect volume on day one.
MCP is build-time only. That's Base44's design, not a provider quirk. Don't plan runtime charging through it.

Pick insertion point 1 to get an account and scaffold, then 2 or 3 to charge. The full recipe with the same endpoints lives at https://paas.build/base44.

Paddle rejected my account. Here's the map of what actually works in 2026

oded-unipaas — Fri, 10 Jul 2026 06:38:56 +0000

Disclosure before anything else: I'm Oded, co-founder of UniPaaS, the FCA-authorised Payment Institution (No. 929994) behind paas.build, and we compete with Paddle. The title above is the sentence builders keep arriving with - right here on dev.to, in Hacker News threads, and in our inbox. This is the map I give them, including the branches where Paddle is still the right call.

Why good products get rejected

Paddle is a Merchant of Record. The moment it approves you, it becomes the legal seller of everything you sell. So its underwriting answers exactly one question: "do we want to legally own this business's sales?" A brand-new solo builder with no history is the riskiest possible answer to that question, regardless of how good the product is.

Builders who have been through it report the same four themes:

No prior processing history. The chicken-and-egg: you need a payments track record to get approved, and you need approval to build a track record.
An incomplete-looking site. Missing terms, no pricing page, no live domain, no visible product. Reviewers open your site.
Identity mismatches. The applying entity, the domain owner and the bank account don't line up.
Category restrictions. Paddle has tightened around some generative-AI products.

Very little of this is documented, which is why the rejection email feels random. It isn't. It's a business model doing exactly what it was built to do.

The decision tree

Two questions decide your next move.

1. Is "global tax handled for me" your top requirement?

If yes, stay in the MoR category. This is Paddle's genuine strength, and it's a real one: as Merchant of Record it remits VAT/GST across 100+ jurisdictions, and that liability sits with them, not you. No PayFac gives you that. Don't switch categories - fix the application and get back in the queue:

Make the site look finished. Live domain, real pricing page, terms of service, privacy policy, a working demo.
Explain the business plainly. What you sell, to whom, expected volume, refund policy. Vague reads as risky.
Match identities. Applicant, domain owner and bank account should line up cleanly.
Budget for the queue. Initial review typically takes days; domain reviews and appeals can stretch longer with no committed timeline.

If Paddle says no a second time, Lemon Squeezy and the other MoRs run the same model with different risk appetites. Same category, different reviewer.

2. Do you need to be selling this week, under your own brand?

Then the fix is structural, not cosmetic. A payment facilitator (PayFac) inverts the model: you stay the merchant, your name is on the checkout and the statement, you own the customer relationship, and risk is managed with limits and monitoring instead of upfront gatekeeping.

That's what progressive KYB means at paas.build in practice: a real merchant account, sandbox and production, in the same session - individuals and sole traders included. You're live immediately with a cap of roughly £1,500 while verification completes in the background. No processing history required, because the cap is the underwriting. Paddle asks "prove you're established." Progressive KYB says "start small, we'll verify as you grow." If you were rejected for being new, that's the difference that matters.

On price: paas.build charges 3.9% flat. Paddle charges 5% + $0.50, which on a $9 subscription is $0.95 - an effective 10.6%. The fixed fee is what stings at small ticket sizes.

Where the PayFac path does not work

I promised honesty, so here it is:

Geography. paas.build onboards builders registered in the UK, EU or US. Your customers can pay from anywhere in the world, but if you're based outside those regions, this branch of the tree is closed to you.
Tax is yours. You are the seller of record, so VAT and sales tax filing are your responsibility. We ship guides and tax-engine integrations, but the liability does not move. If that sentence made your stomach drop, go back to question 1.
The cap is real. Roughly £1,500 until verification completes. Fine for a launch; if you're already at volume, plan for the verification step.

The map, folded up

Rejected, and you need tax handled globally: harden the application and reapply to Paddle, or try another MoR. The review queue is the price of the tax shield.
Rejected, and you need to launch now under your own brand, from the UK, EU or US: a progressive-KYB PayFac gets you a live, capped account the same day.
Based outside the UK, EU and US: the MoR category is probably your only route. Make the application airtight before you resubmit.

The rejection wasn't a verdict on your product. It was a filter built for a different business model. Pick the model that matches what you actually need, and stop paying the queue tax for a shield you may not even want.

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

oded-unipaas — Mon, 06 Jul 2026 09:55:37 +0000

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.