# paas.build — full content corpus for LLMs # See llms.txt for the structured summary. ====================================================================== # paas.build — Payments live today, not in a week # https://paas.build/ ====================================================================== Payments for AI builders Your payments, live today!Not in a week. Tell your agent to add payments and go live as yourself — no company to form, no week-long review. A real account, sandbox and production, in one prompt. 3.9% flat, not Paddle’s 5% + 50¢. You stay the merchant; your users get paid too. Go live Watch an agent do it — 45s sell to the whole world · for builders based in the UK, EU & US agent — zsh How it works Your agent already knows how. Install the skill claude plugin install unipaas@unipaas — or point any MCP client at our docs. Say what you want “Add subscriptions.” “Let my users take payments.” “Replace Stripe.” It ships Our docs are written for agents first — one API call to the first payment. Your agent does the rest. Works with Claude Code, Cursor, Codex, Gemini CLI — anything that reads docs. Point your agent here → Works with your stack Wherever your agent builds, payments drop in. Lovable Bolt Cursor Claude Code v0 Replit Windsurf Two ways builders use paas.build SELL YOUR APP Charge for your app Free, Pro, Max — plans, subscription checkout, renewals and saved cards. Plus one-off credit top-ups for AI usage. Buyers never leave your app, and the receipt carries your name. Ship your pricing page → RUN A PLATFORM Run payments for your users Marketplaces, communities, booking apps: onboard your users in-app, split every payment in real time, pay everyone out on schedule. Stripe hands you a parts list. Paddle can’t do it at all. This is our home turf. Your users get paid too → Subscriptions Free. Pro. Max.Live by lunch. Every app needs a pricing page. Tell your agent your tiers — it wires the plans, the subscription checkout and the renewals. You argue about the prices. Card and Direct Debit on autopilot. Saved cards, one-click. Selling AI credits? Mix one-off top-up packs with plans — same checkout. How subscriptions work your-app.com/pricing Free $0/mo - 50 credits - Community Start POPULARPro $12/mo - 2,000 credits - Priority runs Subscribe Max $29/mo - Unlimited - API access Subscribe Live nowtake payments before ID upload <12 minto a fully verified account 1 promptyour agent wires the whole integration Worldwideyour buyers pay from anywhere Proof, on camera An AI agent replaced Stripe in 90 minutes. Triibe — a community platform for yoga and pilates studios — pointed an agent at our docs. It wired onboarding, checkout and payouts, fully Triibe-branded, in one session. 3.9% One rate. No monthly fee. No “contact sales.” And the cheaper your product, the more you save vs the 5% + 50¢ crowd. See pricing For platform builders Payments become revenue. On platform volume, you earn a share of every transaction your users process. Payments flip from a cost line to an income line. Explore platforms Go live No forms. Tell us about your business. Type it like you’d say it — or paste your website. Our AI does the paperwork; you just confirm. Go live or in your terminal: go live · prefer a classic form? it’s here ====================================================================== # Subscriptions — Free, Pro, Max, live by lunch | paas.build # https://paas.build/subscriptions ====================================================================== Subscriptions Free. Pro. Max.Live by lunch. The pricing page every app needs — plans, subscription checkout and renewals, wired by your agent in one prompt. Go live Point your agent here card & direct debit recurring · saved cards · one-click your-app.com/pricing Free $0/mo - 50 credits - Community Start POPULARPro $12/mo - 2,000 credits - Priority runs Subscribe Max $29/mo - Unlimited - API access Subscribe How it works Your tiers, in one prompt. Tell your agent your tiers “Free, Pro at $12, Max at $29.” That’s the spec. It wires plans + checkout One API call per plan. The subscription checkout takes the first payment and stores the card — one flow. Renewals run themselves Card or Direct Debit, on schedule. Saved cards and one-click for upgrades and top-ups. One call per plan. Really. copy# create the Pro tier POST /platform/pay-ins/plans { "name": "Pro", "price": 12, "period": 1, "periodUOM": "month", "autoRenewal": true } Your agent already knows the field names — they’re in the skill. The checkout session with plans: [planId] handles first payment, card storage and auto-renew in one go. What’s in the box Subscription checkout First payment + stored card + auto-renew, one embedded flow. Card & Direct Debit recurring Two rails for renewals — fewer failed months. Saved cards & one-click Upgrades and repeat purchases without re-typing. Credit top-ups Selling AI usage? Mix one-off credit packs with plans — same checkout, same 3.9%. Your account page, not our portal Cancel, upgrade and status via API — your agent builds the account page in your brand. No hosted portal that looks like someone else’s product. Webhooks & status API Every renewal, failure and change — pushed to your app. The math Subscription fees compound. Every renewal, every month. Your tier pricePaddle (5% + 50¢)paas.buildYou save $12/mo (Pro)9.2% effective3.9%~57% — on every renewal $29/mo (Max)6.7% effective3.9%~42% — on every renewal Run your own numbers → Your pricing page is one prompt away. Go live Point your agent here ====================================================================== # Platform payments for AI builders — paas.build # https://paas.build/platforms ====================================================================== Builder PayFac Your users get paid too. Onboarding, split payments and payouts for marketplaces, communities and vertical SaaS — the part no merchant-of-record can do, and Stripe makes you assemble. Go live Watch an AI agent build it — 45s A checkout button isn’t a platform. Your app moves money between people — studios and members, sellers and buyers, coaches and clients. That’s not a payment link. It’s onboarding with identity checks, splitting every payment, holding the right balances, and paying the right people on the right day. Paddle can’t touch this: a merchant of record only sells your product. Stripe can — after you assemble Connect, onboarding UX, KYB flows, split logic and payout schedules yourself. Or your agent wires ours. How it works Three moving parts. Zero assembly. Your users onboard in-app Drop-in component, AI-reviewed. Most are approved in seconds — and can take payments before ID upload. Every payment splits in real time Their share, your fee, our 3.9% — computed per transaction, visible immediately. Payouts run themselves Daily, weekly or monthly, per user. Balances, statements and notifications included. What’s in the box Drop-in onboarding KYB inside your product, your brand on every screen. Balance & payout portal Your users see earnings, payouts and statements without leaving your app. Real-time splits Fees and revenue-share allocated the moment a payment lands. Payout schedules Per-user schedules; wires and local rails handled. Receipts in your brand Buyers see your platform’s name — never ours. Recurring memberships Your users charge monthly too — subscriptions per member, renewals on autopilot. The business model flip Their payments. Your revenue. On platform volume you take a share of every transaction. Paddle charges you 5%. Here, payments pay you. Case study An AI agent wired platform payments in one session. A community platform for yoga and pilates studios. An agent wired instructor onboarding, member checkout and payouts — fully Triibe-branded — in 90 minutes. Give your users payments this week. Go live Talk to us about platform terms ====================================================================== # Pricing — 3.9%, one rate | paas.build # https://paas.build/pricing ====================================================================== 3.9% That’s the whole page. Almost. Here’s the rest, in plain language. Included in the 3.9% Embedded checkout & drop-ins Inside your app, in your brand. No redirects. Subscriptions & billing Free / Pro / Max plans, renewals, saved cards, one-click — plus credit top-ups. User onboarding (KYB) AI-reviewed accounts for you — and for your users. Split payments & payouts Real-time splits, scheduled payouts, statements. Every payment method Cards, Apple Pay, Google Pay, Direct Debit, SEPA. No other fees No monthly fee. No setup fee. No hidden anything. The math The cheaper your product, the more Paddle costs you. The 5% + 50¢ model punishes exactly the price points AI builders use. Products under $10 aren’t even on Paddle’s standard pricing. Your price pointPaddle (5% + 50¢)paas.buildYou save $9/mo subscription10.6% effective — “custom pricing” territory3.9%~63% $19/mo subscription7.6% effective3.9%~49% $49 one-off6.0% effective3.9%~35% Your numbers What you’d pay. What you’d keep. Monthly revenue $10,000/mo Average price $30 Paddle modelled at their published 5% + $0.50 per checkout. Paddle$667/mo paas.build (3.9%)$390/mo You keep$3,318/yr Cheaper by41% Platform mode Building a platform? Flip the table. You earn a share of every transaction your users process. Payments pay you. How platform payments work The honest bit Who handles tax? You’re the seller of record: the money is yours — and so is your VAT or sales tax. We ship plain-English guides and tax-engine integrations, and most builders start selling where they live anyway. Global tax-handled-for-you is the one thing merchant-of-record providers genuinely do better — that’s the 5% you’re paying them for. On our roadmap: a merchant-of-record fallback for the markets we don’t cover. Quick answers When do I get paid?Payouts run on a schedule you choose — daily, weekly or monthly. [final timing copy pending] What about chargebacks and refunds?Fraud screening is included. Dispute and refund fee policy: [pending] Very small transactions?3.9% applies to standard tickets. Micro-transaction policy: [pending] Volume discounts?Yes — they apply automatically as you grow. No “contact sales” gate. [thresholds pending] Which countries?Your buyers can pay from anywhere in the world. To open an account, your business needs to be based in the UK, EU or US — more countries via waitlist. Payouts settle through J.P. Morgan · FCA-regulated, Authorised Payment Institution No. 929994 · Funds safeguarded in segregated accounts · Trust & security ====================================================================== # paas.build vs Paddle — an honest comparison # https://paas.build/vs-paddle ====================================================================== An honest comparison Paddle sells your software.We power your software’s payments. Both are real companies solving real problems. Here’s a straight comparison — including where Paddle is the right call. paas.buildPaddle ModelYou’re the merchant — it’s your business, your customerMerchant of record — Paddle is the legal seller Time to liveLive the same day, limits lift as you verify“Days, not weeks” + verification, rejection risk CheckoutEmbedded in your app, your brand on the receiptHosted overlay, Paddle on the statement Platform payments✓ Core capability — onboarding, splits, payouts✗ Not possible under the MoR model Earning on payments✓ Rev-share on platform volume✗ Payments are always a cost Tax handlingYou’re the seller of record — guides + tax-engine integrations; MoR fallback on roadmap✓ Handled in 100+ jurisdictions — their genuine strength Where your buyers can beAnywhere in the worldAnywhere in the world Where your business can beUK, EU or USMost countries — an MoR strength Payment methodsCards, Apple/Google Pay, Direct Debit, SEPA, open bankingCards, PayPal, wallets Pricing3.9% — one rate, no fixed fee5% + 50¢ (custom below $10) Agent-readinessInstallable skill + MCP + 1-call quickstart — agent-proven on cameraAPI + MCP, good docs When Paddle is the right call Your business is based outside the UK, EU and US — or you want VAT and sales tax registered and remitted for you in 100+ jurisdictions, with zero tax operations. That’s what a merchant of record is, and Paddle does it well. If that’s you, pay the 5%. When we’re the right call Your business is based in the UK, EU or US — and sells to the whole world. You want checkout inside your product, with your name on it. Your app moves money between users — Paddle can’t. You want to earn on payments, not just pay for them. You want to be live today. The math The cheaper your product, the more Paddle costs you. Your price pointPaddle (5% + 50¢)paas.buildYou save $9/mo subscription10.6% effective — “custom pricing” territory3.9%~63% $19/mo subscription7.6% effective3.9%~49% $49 one-off6.0% effective3.9%~35% Run your own numbers → Migration Moving is a prompt, not a project. Triibe replaced Stripe in 90 minutes — an agent did the work. Paddle migrations run the same way: point your agent at our docs, keep your customers, keep your prices. Go live Point your agent here ====================================================================== # Docs — point your agent here | paas.build # https://paas.build/agents ====================================================================== Docs · Agents-first Point your agent here. Our docs are written for agents first. Install the skill, say what you want, review the diff. Humans welcome too — the readable reference is below. Install copy# Claude Code claude plugin marketplace add UNIPaaS/agent-skills claude plugin install unipaas@unipaas copy# Any MCP client — live docs server claude mcp add --transport http unipaas-docs https://docs.mcp.unipaas.com copy# Anything else npx skills add docs.unipaas.com Then tell it what you want: “add payments to my app” · “let my users take payments” · “replace Stripe” What your agent gets The integration map Which pieces exist and how they connect — no guessing. One-call quickstart A single API call to the first payment. Drop-in templates Checkout, onboarding, balance and payout components, ready to mount. Exact field names The details that usually cost hours — documented precisely. Test flows Sandbox, test cards, webhooks — end to end. llms.txt Full corpus for any model: /llms-full.txt Prefer to read? The same docs, for humans. Everything your agent reads, readable by you — one reference, no drift. Getting started → One API call to your first payment. Subscriptions → Plans, recurring checkout, renewals. Agents & MCP → Skill installs, MCP server, corpus downloads. llms-full.txt → The whole corpus in one file — paste it anywhere. Proof Built by an agent, on camera. Triibe: onboarding, checkout, payouts — 90 minutes, fully branded. This is what “agents-ready” means when it’s real. Works with Claude Code · Cursor · Codex · Gemini CLI · any MCP client Your agent is ready. Are you? Go live ====================================================================== # Trust & security — paas.build # https://paas.build/trust ====================================================================== Trust & security Boring, in all the right ways. You’re routing revenue through us. Here’s exactly who we are and where the money sits. REGULATED An authorised payment institution paas.build runs on UniPaaS. UNIPaaS Financial Services Ltd is authorised by the UK Financial Conduct Authority as an Authorised Payment Institution — No. 929994 (public register). YOUR MONEY Safeguarded, segregated, settled Funds are safeguarded in segregated accounts under FCA rules — your money is never our working capital. Payouts settle through J.P. Morgan. SECURITY PCI DSS v4, tested by outsiders PCI DSS v4 environment, independent penetration testing, quarterly ASV scans, encryption at rest and in transit. TRACK RECORD Running real volume today 30+ platforms and thousands of small businesses run on this infrastructure. 4,742 payouts executed in the last 7 days. Questions? security@paas.build · Status page coming with launch. Fast where it should be. Slow where it must be. Instant accounts with progressive limits, AI review with humans on the exceptions — speed that’s risk-managed, not reckless. Under the hood: AI review approves 81% of accounts automatically, median decision 36 seconds, fully verified in under 12 minutes — and a human looks at every exception. Go live ====================================================================== # Add payments to your Lovable app — live today | paas.build # https://paas.build/add-payments-to-lovable ====================================================================== paas.build × Lovable Add payments to your Lovable app.Live today. Lovable builds your app from a conversation — payments should work the same way. Paste one message, and your app has a real merchant account behind it. Go live in one prompt Docs for agents 3.9% flat · no company required · UK, EU & US businesses · buyers pay from anywhere The chat prompt lovable — prompt Add payments to my app with paas.build — create my account and mount checkout. The problems Lovable builders actually hit You’ve seen these. So have we. ✗ Stripe doesn’t run in preview The official flow only works after you deploy — so every payment tweak means another deploy just to test. source: Lovable docs → with paas.build: Our sandbox works anywhere: real test account, test cards, no deploy needed. ✗ The webhook-secret maze Payment succeeds but your app never updates — STRIPE_WEBHOOK_SECRET mismatches and edge-function ordering are the #1 support topic. source: Lovable FAQ → with paas.build: First sale with zero webhook plumbing — drop-in checkout or a hosted link. ✗ Setup spread across three tools Keys in chat, Supabase edge functions, success URLs configured in two places — lots of moving parts before £1 moves. source: Lovable docs → with paas.build: Two env vars from your welcome email. That’s the whole setup. Three steps From prompt to first payment 1. Tell Lovable what you sell In the chat, describe your product and paste the prompt below. Lovable's agent reads our docs and wires the checkout component. 2. Go live at paas.build Click Go live here (or let the agent call our API). You get a real account — sandbox + production — the same day, capped until verification completes in the background. 3. Take your first payment Drop your keys into Lovable's env settings. Your buyers pay inside your app — your name on the receipt. FAQ Do I need a company to accept payments in my Lovable app? No. Individuals and sole traders go live the same day with a capped account; verification completes in the background. Companies finish a short identity step. How much does it cost? One flat rate: 3.9% per transaction. No monthly fee, no per-transaction fixed fee, no "contact sales". Can my Lovable app pay my own users too? Yes — paas.build is a payment facilitator, so marketplaces and communities can split payments and pay their users out. A merchant-of-record (like Paddle) structurally cannot. Your payments, live today. Not in a week. One prompt. A real account. 3.9% flat. Go live ====================================================================== # Add payments to your Bolt app — live today | paas.build # https://paas.build/add-payments-to-bolt ====================================================================== paas.build × Bolt Add payments to your Bolt app.Live today. Bolt ships full-stack apps from a prompt. The missing piece is always the same: a merchant account that doesn't take a week. That's the piece we removed. Go live in one prompt Docs for agents 3.9% flat · no company required · UK, EU & US businesses · buyers pay from anywhere The in-editor prompt bolt — prompt Add a checkout to this app using paas.build (docs: paas.build/agents). Then help me go live. The problems Bolt builders actually hit You’ve seen these. So have we. ✗ The payment backend is on you Bolt’s Stripe path runs through Supabase edge functions — the prototype is instant, the payment plumbing isn’t. source: Bolt support → with paas.build: Checkout is one component + one API call — the backend is ours, not yours. ✗ “Took most of a day” Builders report the frontend flies, then backend + database + deploy for payments eats the rest of the day. source: community review → with paas.build: One prompt → account + checkout mounted in the same session. ✗ Test mode isn’t live mode Flipping to live still means account activation and business verification at your PSP — days, not minutes. source: Bolt support → with paas.build: A real capped account the same day; verification completes in the background. Three steps From prompt to first payment 1. Prompt Bolt to wire checkout Paste the prompt below in Bolt. It reads our agent docs and adds the payment flow — component, API call, success page. 2. One prompt to go live At paas.build, click Go live, tell us who you are (or paste your site) — a real account, sandbox + production, is created in the same session. 3. Ship it Set the two env vars from your welcome email. Test with our sandbox cards, flip the toggle to production, and you're selling. FAQ How fast am I actually live? Individuals: the same session — a capped, real account (≈£1,500) until verification finishes in the background. No week-long review. What does paas.build cost? 3.9% flat per transaction. Compare: Paddle is 5% + $0.50 — roughly 41% more expensive on a $30 sale. Does it work with Bolt’s deployed apps? Yes — the checkout is a drop-in component (or a hosted link). Works in any Node/React app Bolt produces. Your payments, live today. Not in a week. One prompt. A real account. 3.9% flat. Go live ====================================================================== # Add payments to your Cursor app — live today | paas.build # https://paas.build/add-payments-to-cursor ====================================================================== paas.build × Cursor Add payments to your Cursor app.Live today. You're in Cursor because you ship fast. Your agent can read our docs, call one API, and your repo has payments — while the "traditional" path is still emailing you onboarding forms. Go live in one prompt Docs for agents 3.9% flat · no company required · UK, EU & US businesses · buyers pay from anywhere The agent task cursor — prompt Install the paas.build flow from paas.build/agents and add a £9/mo Pro subscription to this repo. The problems Cursor builders actually hit You’ve seen these. So have we. ✗ 1–2 hours of “careful steps” — with AI Even the 2026 guides budget 1–2 focused hours for a Stripe integration in an AI editor: keys, endpoints, test flows. source: integration guide → with paas.build: Three lines with @paasbuild/react. Your agent does it in one pass. ✗ Debugging webhook signatures The classic sink: signature verification, replay protection, local tunnels — before a single real sale. source: builder guide → with paas.build: No webhooks needed for your first payment — the checkout confirms in-page. ✗ Scaffold in 20 minutes, then wait Cursor scaffolds your stack in minutes — then payments stall on merchant activation at the PSP. source: SaaS-with-Cursor guide → with paas.build: go-live creates the merchant account itself — same session, capped, real. Three steps From prompt to first payment 1. Give Cursor the task Paste the prompt below into the agent panel. Our docs are written agents-first — one call from zero to checkout. 2. Mint your account The agent calls POST /api/go-live (or you click Go live here). Sandbox + production vendors, real tokens, same session. 3. Subscriptions in one commit Free/Pro/Max plans, recurring on card + Direct Debit, saved cards. The agent wires the webhook and the pricing page. FAQ Is there an SDK? Yes — @paasbuild/react (three lines to a live checkout), plus an MCP server and an installable skill so agents can drive everything headless. Do my tokens expire? No — your credentials are permanent. Keep them secret like any API key. Which countries can go live? Businesses registered in the UK, EU or US. Buyers can pay from anywhere in the world. Your payments, live today. Not in a week. One prompt. A real account. 3.9% flat. Go live ====================================================================== # Add payments to your Claude Code app — live today | paas.build # https://paas.build/add-payments-to-claude-code ====================================================================== paas.build × Claude Code Add payments to your Claude Code app.Live today. Claude Code is where the agent-native story is fully true: install our MCP server, say "take my business live", and watch the account, tokens and checkout appear in your terminal. Go live in one prompt Docs for agents 3.9% flat · no company required · UK, EU & US businesses · buyers pay from anywhere The skill / MCP claude code — prompt claude mcp add paas-build -- npx -y @paasbuild/mcp # then: "take my business live" (official registry: io.github.UNIPaaS/paas-build-mcp) The problems Claude Code builders actually hit You’ve seen these. So have we. ✗ The guides assume you already have an account “Add Stripe in an afternoon” tutorials start AFTER approval — the merchant account itself is the missing step. source: builder guide → with paas.build: Our MCP creates the account: identify_business → go_live → tokens. No prior approval. ✗ Stripe’s MCP manages, it can’t open The Stripe MCP server operates an EXISTING account (customers, refunds, invoices) — it cannot get you approved to sell. source: Composio toolkit docs → with paas.build: paas-build MCP goes one level deeper — it provisions the account itself. ✗ Billing is the fiddliest mile End-to-end SaaS build logs consistently show billing as the slowest, most re-worked part of the project. source: build log → with paas.build: Subscriptions, saved cards and renewals wired by the agent from our docs. Three steps From prompt to first payment 1. Install the MCP / skill One command (below). Claude gets three tools: identify_business, go_live, create_checkout. 2. Say what you want "Take my business live." Claude identifies your business (web search), creates sandbox + production vendors, and hands you scoped tokens — no dashboard. 3. First payment from the terminal Ask for a checkout link, pay with a sandbox card, watch it land in your merchant portal. Then flip to production. FAQ Is this real or a demo? Real. go_live creates an actual merchant account on UniPaaS (FCA-authorised, No. 929994) — capped until verification completes in the background. What about other MCP clients? Any MCP client works — Cursor, Windsurf, Cline, or your own agent. The server speaks plain stdio JSON-RPC and calls our public API. What does it cost? 3.9% flat. Sandbox is free forever. Your payments, live today. Not in a week. One prompt. A real account. 3.9% flat. Go live ====================================================================== # Add payments to your v0 app — live today | paas.build # https://paas.build/add-payments-to-v0 ====================================================================== paas.build × v0 Add payments to your v0 app.Live today. v0 turns a prompt into a shippable UI. But the moment it needs to charge money, you're suddenly building a merchant backend. We made that part one prompt too. Go live in one prompt Docs for agents 3.9% flat · no company required · UK, EU & US businesses · buyers pay from anywhere The v0 prompt v0 — prompt Add a checkout with paas.build (docs: paas.build/agents) — a £9/mo Pro plan and a success page. The problems v0 builders actually hit You’ve seen these. So have we. ✗ 1–2 hours of “careful steps” — with AI Even 2026 integration guides budget 1–2 focused hours for wiring a PSP into an AI-built app: keys, endpoints, signatures, test flows. source: integration guide → with paas.build: Three lines with @paasbuild/react — the agent does it in one pass. ✗ No US entity? The Atlas detour Without a US company, the classic path adds Stripe Atlas ($500) and an IRS EIN wait that stretches to weeks for non-US founders. source: Stripe resources → with paas.build: No company required — go live the same day; verification runs in the background. ✗ Activation is the real blocker Builders scaffold a stack in 20 minutes, then payments stall on merchant activation at the PSP. source: SaaS-building guide → with paas.build: go-live creates the merchant account itself — capped, real, same session. Three steps From prompt to first payment 1. Prompt v0 for the checkout UI Paste the prompt below — v0 generates the pricing section and checkout component against our docs. 2. Go live here Click Go live at paas.build: a real account — sandbox + production — in the same session, capped until verification completes in the background. 3. Paste keys into Vercel env Two env vars from your welcome email. Deploy — your buyers pay inside your app. FAQ Does this work with Next.js on Vercel? Yes — @paasbuild/react drops into any React/Next.js app; server routes can mint checkouts via one API call. What does it cost? 3.9% flat per transaction. No monthly fee, no fixed per-transaction fee. When do I get production keys? Same day — a real capped account; verification completes in the background. Your payments, live today. Not in a week. One prompt. A real account. 3.9% flat. Go live ====================================================================== # Add payments to your Replit app — live today | paas.build # https://paas.build/add-payments-to-replit ====================================================================== paas.build × Replit Add payments to your Replit app.Live today. Replit Agent ships your app from a prompt — and hosts it too. The last mile is always the same: getting *paid*. That's the mile we shortened to one prompt. Go live in one prompt Docs for agents 3.9% flat · no company required · UK, EU & US businesses · buyers pay from anywhere The Agent prompt replit — prompt Use paas.build (docs: paas.build/agents) to add payments to this Repl — then take me live. The problems Replit builders actually hit You’ve seen these. So have we. ✗ Webhook debugging in a hosted IDE Signature verification and replay handling are the classic time sink — before a single real sale. source: builder guide → with paas.build: No webhooks needed for your first payment — checkout confirms in-page. ✗ The Atlas detour for global builders Much of Replit’s audience isn’t in the US — the “form a Delaware company first” path costs $500 and weeks of IRS waiting. source: Stripe resources → with paas.build: UK/EU/US builders go live as themselves — no company, same day. ✗ 1–2 careful hours, every time PSP wiring in AI-built apps still budgets hours of keys/endpoints/test flows in the 2026 guides. source: integration guide → with paas.build: One prompt: account + mounted checkout in the same session. Three steps From prompt to first payment 1. Prompt the Agent Paste the prompt below — the Agent reads our docs and wires checkout + a success route into your Repl. 2. Go live in one prompt At paas.build: real account, sandbox + production, same session. No forms, no queue. 3. Add two secrets Drop the keys into Replit Secrets. Test with sandbox cards, flip to production, get paid. FAQ Does it work on Replit hosting? Yes — the checkout is a component (or a hosted link); the account API is one POST from anywhere. Is sandbox free? Free forever — test cards included. Price? 3.9% flat. That’s the whole page. Your payments, live today. Not in a week. One prompt. A real account. 3.9% flat. Go live ====================================================================== # Add payments to your Windsurf app — live today | paas.build # https://paas.build/add-payments-to-windsurf ====================================================================== paas.build × Windsurf Add payments to your Windsurf app.Live today. Cascade will happily refactor your whole repo — but it can't wait in a merchant-approval queue for you. Now it doesn't have to: it can open the account itself. Go live in one prompt Docs for agents 3.9% flat · no company required · UK, EU & US businesses · buyers pay from anywhere The Cascade task windsurf — prompt Read paas.build/agents and add payments to this project — £1 test checkout first, then a Pro subscription. The problems Windsurf builders actually hit You’ve seen these. So have we. ✗ Hours of PSP wiring — even with an agent Keys, endpoints, signatures, test flows: the 2026 guides still budget 1–2 careful hours. source: integration guide → with paas.build: Three lines with @paasbuild/react; the agent does the rest. ✗ The activation wall Scaffold in minutes, then wait on merchant activation — the queue doesn’t care how fast your agent is. source: SaaS-building guide → with paas.build: The account is created in-session: capped, real, yours. ✗ Webhook plumbing before revenue Signature verification and endpoint juggling before the first sale. source: builder guide → with paas.build: First payment with zero webhook plumbing. Three steps From prompt to first payment 1. Hand Cascade the task Paste the prompt below — our docs are agents-first, one call from zero to checkout. 2. Account in the same session go-live returns sandbox + production vendors with real tokens — capped, live, no review week. 3. First £1, then subscriptions Take a £1 test payment, watch it land in your merchant portal, then let Cascade wire Free/Pro/Max. FAQ Any MCP support? Yes — the paas-build MCP works in any MCP client: identify_business → go_live → create_checkout. Who can go live? Businesses registered in the UK, EU or US; buyers pay from anywhere. Cost? 3.9% flat per transaction. Your payments, live today. Not in a week. One prompt. A real account. 3.9% flat. Go live ====================================================================== # The Paddle alternative for AI builders (2026) | paas.build # https://paas.build/paddle-alternative ====================================================================== Paddle alternative The Paddle alternative for AI builders.Live today, 3.9% flat. Paddle is a Merchant of Record: simple, but it becomes the legal seller — its name on the receipt, your customer on its books, 5% + $0.50 on every sale. paas.build keeps you the merchant at 3.9% flat, goes live the same day, and does the one thing an MoR structurally can't: pay your users too. Go live in one prompt See pricing Side by side Paddle vs paas.build Paddlepaas.build Pricing5% + $0.50 per sale3.9% flat — no fixed fee ModelMerchant of Record — Paddle is the sellerPayFac — you stay the merchant Receipt & brandPaddle’s name on the statementYour name, your brand Your customer dataOn Paddle’s booksYours Your users get paid✗ structurally impossible✓ built-in platform payouts Go-liveVendor review before sellingSame day — capped, verified in background Global sales tax✓ Paddle remits it for youYou remain seller of record (tooling on roadmap) When Paddle is the right choice: if global sales-tax remittance is your #1 problem and you sell pure digital products worldwide, an MoR earns its 5%. Read our full teardown: paas.build vs Paddle → FAQ Is paas.build a Merchant of Record like Paddle? No — paas.build is a payment facilitator (PayFac). You stay the legal seller: your brand on the receipt, your customer relationship, your data. Paddle replaces you as the seller. Who handles VAT/sales tax? You are the seller of record, so your tax stays yours. paas.build ships tax tooling and guides; an MoR fallback is on the roadmap for markets it does not cover. Paddle’s genuine edge is remitting tax for you. How fast can I switch from Paddle? Go live the same day (capped until verification completes in the background), mount the drop-in checkout, and route new sales through paas.build while your Paddle account winds down. Can my users get paid too? Yes — split payments and pay out your app’s users (marketplaces, communities, platforms). A Merchant of Record cannot move money between your users. Your payments, live today. Not in a week. One prompt. A real merchant account. No company required. Go live ====================================================================== # The Stripe alternative for AI builders (2026) | paas.build # https://paas.build/stripe-alternative ====================================================================== Stripe alternative The Stripe alternative for AI builders.Live today, 3.9% flat. Stripe hands you world-class parts — and you assemble them: Connect, onboarding flows, splits, payouts, webhooks. And before any of it, you need an entity Stripe will approve (non-US founders: that's the $500 Atlas + IRS-EIN detour). paas.build is the assembled version: one prompt, a real merchant account the same day, checkout mounted. Go live in one prompt See pricing Side by side Stripe vs paas.build Stripepaas.build Time to first paymentAssemble + activate (entity, review)Same session — capped, live Company requiredSupported-country entity (Atlas: $500 + EIN wait for non-US)None — go live as yourself Platform paymentsStripe Connect — powerful, DIYBuilt-in: onboard users, split, pay out IntegrationSDKs + webhooks + dashboards to wireDrop-in checkout or 3 lines of React Agent-nativeMCP manages an existing accountMCP creates the account (go_live) Pricing2.9% + 30¢ + Connect/Billing add-ons3.9% flat, everything included When Stripe is the right choice: huge scale, custom money flows, or you want raw primitives and have the engineering time. Stripe's ecosystem is unmatched — our edge is being live today without building any of it. FAQ Is paas.build cheaper than Stripe? Different shapes: Stripe starts at 2.9% + 30¢ plus add-ons (Billing, Connect, Radar); paas.build is 3.9% flat with subscriptions and platform payouts included. On small tickets the missing fixed fee often makes paas.build cheaper in practice. Do I need a US company like with Stripe Atlas? No. UK, EU and US businesses — including individuals and sole traders — go live the same day. No incorporation, no EIN wait. Can an AI agent set everything up? Yes — the paas-build MCP creates the account itself (identify_business → go_live → create_checkout). Stripe’s MCP operates an account you already have. What about Stripe Connect features? Platform payments are built-in: onboard your users, split every payment in real time, pay everyone out — without assembling Connect. Your payments, live today. Not in a week. One prompt. A real merchant account. No company required. Go live ====================================================================== # The Lemon Squeezy alternative for AI builders (2026) | paas.build # https://paas.build/lemonsqueezy-alternative ====================================================================== Lemon Squeezy alternative The Lemon Squeezy alternative for AI builders.Live today, 3.9% flat. Lemon Squeezy (now part of Stripe) is a Merchant of Record at 5% + $0.50: friendly for selling digital downloads, but it owns the sale — and it can't run payments between your users. paas.build: 3.9% flat, your brand on the receipt, live the same day, platform payouts included. Go live in one prompt See pricing Side by side Lemon Squeezy vs paas.build Lemon Squeezypaas.build Pricing5% + $0.50 per sale3.9% flat — no fixed fee ModelMerchant of RecordPayFac — you stay the merchant Best atDigital downloads & licensesApps, SaaS, marketplaces, communities Your users get paid✗✓ built-in payouts Go-liveStore reviewSame day, capped, background verification CheckoutHosted, LS-brandedEmbedded in your app, your brand When Lemon Squeezy is the right choice: selling digital files/licenses worldwide and you never want to think about tax — the MoR model fits that. Building an actual app or platform? You'll hit its walls fast. FAQ What’s the core difference? Lemon Squeezy is a Merchant of Record — it is the seller. paas.build is a payment facilitator — you are. That decides whose name is on the receipt, who owns the customer, and whether your users can get paid. Is 3.9% really cheaper than 5% + 50¢? On a $9 subscription: Lemon Squeezy ≈ $0.95, paas.build ≈ $0.35 — about 63% less. The fixed fee is what punishes small tickets. Can I sell subscriptions? Yes — Free/Pro/Max plans, renewals on card and Direct Debit, saved cards, plus one-off credit top-ups for AI usage. Your payments, live today. Not in a week. One prompt. A real merchant account. No company required. Go live ====================================================================== # Payments, live in one prompt — paas.build # https://paas.build/blog/go-live ====================================================================== GO-LIVE · 7 min read 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: - 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. - 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. - 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. 1 promptfrom "I want to charge" to a usable token <12 minto a fully verified account £1,500accept payments before ID upload 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. Individuals vs companies A sole trader can be live in the same session — identity plus an agreement is enough to reach the capped tier. A registered company carries beneficial owners and incorporation documents, so it finishes those steps in a short hosted flow before the cap lifts. Both start building against the sandbox instantly. 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. Try the sentence. Tell your agent to add payments — or do it yourself in one prompt. Live the same day, 3.9%. Go live → Written for builders. paas.build runs on UniPaaS, an FCA-authorised payment institution (No. 929994). Instant-live limits and eligibility apply by geography. PricingFree, Pro, Max: pricing your AI app RecoveryThe revenue leak nobody sees ModelsMoR vs PayFac: who owns your customer? ====================================================================== # Free, Pro, Max: pricing your AI app — paas.build # https://paas.build/blog/saas-pricing ====================================================================== PRICING · 8 min read Free, Pro, Max: pricing your AI app Your pricing page is the second-most-important screen you'll ship. It's where interest becomes revenue — and where most AI builders either leave money on the table or scare buyers off. Here's how to structure tiers, when freemium helps, and why credits changed the game. First, a distinction that saves a lot of arguing. A pricing model is the structure — per-seat, tiered, usage-based. A pricing strategy is the thinking behind the numbers — who you're targeting and why $12 and not $19. You need both, but the model is where you start, because it shapes the page your users actually see. Why three tiers, named the way they are Tiered pricing scales the price against a threshold of some metric — usage, seats, features. Three tiers is the default for a reason: it gives you a floor, an anchor, and a ceiling. Free or cheap on the left, a "most people pick this" middle, and a high tier that makes the middle look reasonable. The middle tier is the one that matters. Mark it Popular and price it where your best-fit customer lands without thinking too hard. The Max tier isn't really there to sell in volume — it's there to make Pro feel like the sensible choice. TierJob on the pageTypical AI-app price FreeAcquire — get them into the funnel$0 · limited credits ProConvert — the anchor most pick$12–$29/mo MaxExpand — make Pro look sensible$49–$99/mo Freemium is acquisition, not monetization The biggest mistake with a free tier is treating it as a revenue line. It isn't. Freemium is a way of acquiring users, not charging them — it puts people into your funnel cheaply so some fraction converts later. That reframes every free-tier decision. The question isn't "how do I make money on free users?" It's "does free reliably produce paid ones?" Free users who convert tend to have higher satisfaction, better retention, and dramatically lower acquisition cost than users you paid to acquire cold. If your free tier doesn't feed conversion, it's just a cost. Free isn't a plan. It's the top of your funnel wearing a price tag of $0. The AI wrinkle: credits Traditional SaaS pricing assumes near-zero marginal cost per user. AI apps break that assumption — every generation costs real money in inference. So the 2026 default for AI products isn't a flat subscription; it's a hybrid: a plan that includes a quota, plus the ability to top up. Credits do two useful things at once. They cap your downside (a heavy user can't run up an unbounded bill on a flat plan), and they feel fair to the buyer (predictable, pay-for-what-you-use, immediate cash flow for you). For most consumer-facing AI tools, prepaid credits beat pure usage-based metering — people like knowing the number before they spend it. The clean structure: tiers for the base relationship, credit packs for the overflow. One checkout, one rate, both handled. Ship the page, not a spreadsheet Tell your agent your tiers — "Free, Pro at $12, Max at $29, plus $5 credit packs" — and it wires the plans, the subscription checkout and the renewals. You argue about the prices; the billing is done. That's the point of building on paas.build subscriptions: the pricing page is a prompt, not a project. Let the data move the numbers Your first prices are guesses. That's fine — good pricing is iterative. Instrument it: track conversion rate by tier, expansion revenue, and churn by price point. If Pro converts but nobody touches Max, your ceiling is too low to anchor. If Free never converts, it's too generous. Move one number at a time and watch what happens. The builders who win at pricing aren't the ones who got it right on day one. They're the ones who made it cheap to change. Your pricing page is one prompt away. Free, Pro, Max — plans, checkout and renewals, wired for you. Live by lunch. See subscriptions → Written for builders. Benchmarks are directional, not prescriptive — price for your market, then iterate. Go-livePayments, live in one prompt RetentionReduce churn: 5 moves, quantified RecoveryThe revenue leak nobody sees ====================================================================== # The revenue leak nobody sees — paas.build # https://paas.build/blog/failed-payments ====================================================================== RECOVERY · 6 min read The revenue leak nobody sees You obsess over the churn you can see — the cancellation, the angry email, the exit survey. Meanwhile a bigger leak runs silently in the background: customers who never meant to leave, whose payment just quietly failed. It's the most recoverable revenue you have, and most builders never look at it. 20–40%of subscription churn is failed payments, not real cancellations ~10%of subscription revenue lost to failed payments before recovery 2.78%of cards expire every single month Involuntary churn is a different animal There are two kinds of churn, and they need opposite responses. Voluntary churn is a decision — someone chose to leave, and your job is to change their mind. Involuntary churn is an accident — the customer is happy, still wants the product, and doesn't even know they've lapsed. Their card expired, hit a limit, got reissued after a fraud flag, or the bank declined a routine renewal. The mistake is lumping them together in one "churn" number. When you do, involuntary churn hides — and it's often the larger, cheaper-to-fix half. The happiest customer you'll lose this month is one whose card expired and nobody retried it. Why payments fail (and it's rarely "no money") Builders assume a decline means an empty account. Usually it doesn't. The common causes: - Expiry — the single biggest bucket. Cards roll over constantly; the subscription doesn't know. - Reissued cards — after fraud or loss, the number changes but the customer is fine. - Bank-side friction — routine declines from risk systems, especially cross-border, that succeed on a retry. - Soft limits — a temporary hold that clears in a day. Almost all of these are recoverable — if something retries intelligently instead of giving up on the first no. The mechanics of recovery "Dunning" is the unglamorous name for chasing failed payments. To dun is, literally, to make persistent demands — and done well, a combination of tactics recovers the large majority of involuntary churn. Three levers do most of the work: - Smart retries. Not "try again tomorrow," but retrying at the moment most likely to succeed — factoring the failure code, card type, day of week, and region. Timing is the whole game. - Local acquiring. Routing a renewal through a local rail in the customer's country lifts acceptance by a few points on its own. A payment in local currency is measurably more likely to clear. - Card updaters. When a card is reissued, the network can quietly hand you the new details — recovering a meaningful slice of the cards due to expire, with zero customer action. Two rails beat one Cards fail; bank debits don't expire. Offering Direct Debit alongside cards for renewals removes an entire category of failure — there's no expiry date to lapse. On paas.build, recurring runs on card and Direct Debit, so fewer months quietly break. Make recovered revenue a metric What gets measured gets fixed. The strongest subscription apps track recovered revenue as a first-class growth number, right next to ARR and LTV. It reframes recovery from a support chore into what it actually is: one of the highest-ROI growth levers you have, because the customer already said yes. You're not acquiring anyone. You're just not dropping them. Start by separating involuntary from voluntary in your reporting. You can't recover a leak you've averaged away. Stop the silent leak. Card + Direct Debit renewals, smart retries, local rails — recovery built into the rails, not bolted on. Subscriptions → Written for builders. Recovery percentages vary by mix, geography and card portfolio — treat the numbers as direction, not promise. RetentionReduce churn: 5 moves, quantified PricingFree, Pro, Max: pricing your AI app Go-livePayments, live in one prompt ====================================================================== # Reduce churn: 5 moves, quantified — paas.build # https://paas.build/blog/churn ====================================================================== RETENTION · 9 min read Reduce churn: 5 moves, quantified Growth gets the attention, but retention is where the compounding lives. A point of churn saved this month keeps saving every month after. Here are five tactics that actually move the number — ranked by how much ARR churn each one removes, so you can start with the biggest lever. First, a mental model. Sort every retention tactic on two axes: is the churn voluntary (a decision) or involuntary (a payment accident), and are you acting before the customer leaves or after? That gives you four quadrants — and a rule of thumb: start with lagging, measurable levers, because you'll see the impact fastest. MoveARR churn cutType Improve payment acceptance~30%Involuntary · pre-churn Upgrade users to annual~25%Voluntary · pre-churn User-activation campaigns~15%Voluntary · pre-churn Dunning campaigns~10%Involuntary · post-churn Cancellation flows & offers~5%Voluntary · post-churn 1. Improve payment acceptance — the biggest, quietest lever The largest number on the list isn't a growth tactic at all — it's making sure the payments you should be collecting actually clear. Local acquiring lifts renewal acceptance by a few points; charging in local currency makes a payment measurably more likely to succeed; card updaters quietly recover a slice of expiring cards. None of it touches your product, and it removes churn the customer never intended. Start here. 2. Move customers to annual An annual plan is twelve months of churn resistance bought in one decision. There's a clean negative correlation between the share of revenue on annual plans and monthly churn — more annual, less churn, reliably. One well-known case moved from 2% to 21% of customers on annual and watched voluntary churn fall with it. A simple "save two months by paying yearly" prompt, shown at the right moment, does real work. Every customer you move to annual is a customer who can't churn for a year. 3. Activate before you retain The customer who never got value is already half gone. Activation campaigns — in-app walkthroughs, nudges toward the "aha" action, reactivation of dormant users — attack churn at its root, before anyone reaches for the cancel button. It's slower to instrument than a retry rule, but it compounds, because an activated user is a retained user by default. 4. Dun the failures you can recover When a payment fails, a good dunning program — smart retries plus clear customer messaging across email and in-app — recovers a large share of that involuntary churn. It's post-churn, so it's cleanup rather than prevention, but the customer already wanted to stay, which makes it some of the cheapest revenue you'll ever save. (We went deep on this in the revenue leak nobody sees.) 5. Give the leaver a reason to stay The last line of defense is the cancellation flow. Done right — an offer to pause, a downgrade, a targeted discount, or just a better-timed annual upsell — it saves a meaningful chunk of at-risk customers who were one friction away from staying. It's the smallest lever on the list, but it's also the easiest to ship, so it's a fair place to prove the loop works before you invest upstream. Why order matters You don't need all five on day one. Ship them biggest-first, one every couple of weeks, and measure each in dollars retained. Payment acceptance and annual upgrades will likely dwarf the rest — which is lucky, because they're also the ones that don't require rebuilding your product. The compounding you're buying Here's why this beats chasing signups. Cutting monthly churn from 3% to 2% isn't a one-percentage-point improvement — over twelve months it's roughly 9% less ARR churned, because retention compounds the same way interest does. New revenue you have to win again every month. Retained revenue keeps paying you. Fix the leak once and it stays fixed. Retention starts at the rails. Better acceptance, annual plans, Direct Debit, recovery — built into paas.build, not bolted on after. See subscriptions → Written for builders. Impact ranges are industry benchmarks and vary by model, price point and mix — use them to prioritise, then measure your own. RecoveryThe revenue leak nobody sees PricingFree, Pro, Max: pricing your AI app ModelsMoR vs PayFac: who owns your customer? ====================================================================== # MoR vs PayFac: who owns your customer? — paas.build # https://paas.build/blog/mor-vs-payfac ====================================================================== MODELS · 7 min read MoR vs PayFac: who owns your customer? Every "add payments" decision is really a decision about ownership. Merchant of Record and Payment Facilitator solve the same surface problem — take money — but they hand you very different businesses underneath. One trades your customer relationship for tax simplicity. The other keeps it. Here's how to tell which you actually want. Three ways money can move Strip away the branding and there are three models a builder chooses between: - Payment processor (PSP) — e.g. Stripe raw. It moves money from the customer's bank to yours and stops there. Tax, liability, compliance: yours. Maximum control, maximum assembly. - Merchant of Record (MoR) — e.g. Paddle. It becomes the legal seller. It owns the order, remits the tax, eats the chargeback risk — and its name, not yours, is on the receipt. - Payment Facilitator (PayFac) — e.g. paas.build. You are the merchant, but the heavy regulated machinery is run for you. Your brand on the checkout; the compliance handled behind it. The real difference is liability — and the customer A PSP takes on none of the responsibility beyond moving the money. An MoR takes on all of it. That's the genuine appeal of merchant-of-record, and it's a real one: sell into a hundred countries, and someone else registers and remits sales tax in every jurisdiction, absorbs the fraud, answers the billing disputes. But that convenience has a price that isn't on the pricing page. Because the MoR is the legal seller, it — not you — owns the transaction. Its descriptor is on the card statement. The terms are its terms. Increasingly, the customer relationship is intermediated by it. You've outsourced the tax headache and, quietly, handed over the customer. An MoR solves your tax problem by becoming your seller. Read that twice — it's the whole trade. The line an MoR cannot cross Here's the part that decides it for a lot of AI builders, and it's structural, not a feature gap. A merchant of record sells your product. It is legally the seller of the thing you make. That means it fundamentally cannot move money between your users. If your app is a platform — a marketplace, a community with creators, a booking tool, a vertical SaaS where members get paid — you don't just need to charge customers. You need to onboard your users, split each payment, and pay everyone out. An MoR has no mechanism for that, because it can only ever be the one seller in the middle. For platform payments, the MoR question answers itself: it's out. Merchant of RecordPayFac (paas.build) Who's the sellerThemYou On the receiptTheir nameYour brand Owns the customerThemYou Global tax remitted for youYes — the real winYou're the merchant (tax tooling + guides) Your users get paidImpossibleCore capability Payments can earn you moneyNo — always a costYes — rev-share on platform volume So which should you pick? Be honest about your shape, and the answer is usually clear: Choose a Merchant of Record if… Your revenue is globally scattered from day one, you have no legal entity, and you never want to think about VAT. That's what MoR is for, and it does it well. Pay the premium and enjoy it. Choose a PayFac if… Your core market is the UK, EU or US. You want your name on the checkout. Your app moves money between users. You'd rather payments earn than just cost. Then you want to stay the merchant — and a PayFac lets you, without making you assemble it yourself. The tax convenience of merchant-of-record is genuine, and we won't pretend otherwise — for the globally-scattered seller it can be worth the trade. But for a builder shipping into the UK, EU or US, and especially for anyone building a platform, "who owns my customer?" is the question that matters more than "who files my tax?" Answer that one first. Stay the merchant. Your brand, your customer, your users paid too — with the regulated part run for you. 3.9%, one rate. See platform payments → Written for builders. paas.build is a PayFac model on UniPaaS (FCA No. 929994). Global tax-handled-for-you is the one thing MoR does better — we ship tax tooling and an MoR fallback rail on the roadmap. Go-livePayments, live in one prompt RetentionReduce churn: 5 moves, quantified PricingFree, Pro, Max: pricing your AI app ====================================================================== # Agentic payments: agents can pay — but can they get paid? # https://paas.build/agentic-payments ====================================================================== 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. Go live in one prompt Read the agent docs 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. ## How to accept payments without a company (https://paas.build/accept-payments-without-a-company) How to accept payments without a company (2026) | paas.build paas .build Subscriptions Platforms Pricing vs Paddle Docs Blog Portal Go live Guide How to accept payments without a company You do not need a registered company to start accepting card payments. As an individual (sole trader), you can go live the same day with a real, capped merchant account — verification completes in the background. Here's how, and the trade-offs versus forming a company first. Go live in one prompt See pricing → The short answer You can accept payments as an individual — no Ltd, LLC or incorporation required to start. On paas.build, you provide basic personal and business details and go live with a real merchant account the same day, capped (around £1,500) until progressive KYB verification completes. No company number is required at signup. Why the "form a company first" advice is usually outdated The classic route — form a US company via Stripe Atlas ($500) and wait for an IRS EIN (weeks for non-US founders), or incorporate locally before you can even apply to a PSP — was designed when shipping software took months. If you built your app in an evening, spending weeks on incorporation just to test whether anyone will pay is backwards. Start as an individual, incorporate later if and when the revenue justifies it. When you should still form a company Incorporation genuinely helps once you have meaningful revenue: limited liability, cleaner tax treatment, easier to raise money, and a more professional footing with larger customers. The point is sequence — validate demand and take real payments first, then incorporate deliberately rather than as a blocker on day one. How to do it on paas.build Tell your AI agent "add payments," or open the go-live prompt on the homepage. Enter your app or business name; we resolve the details and create a real account (sandbox + production). You get scoped keys by email and can take a live £1 payment in minutes. One flat rate: 3.9%. Available to builders based in the UK, EU and US. FAQ Can I really accept card payments as an individual? Yes. A payment facilitator can onboard you as a sub-merchant without an incorporated company. On paas.build you go live the same day with a capped account while verification completes; no company number is required at signup. Is it legal to take payments without a company? Yes — operating as a sole trader/individual is a recognised way to do business in the UK, EU and US. You remain responsible for declaring income and meeting local tax rules. The payment service itself runs on UniPaaS, an FCA-authorised payment institution. What is the limit before I verify? New individual accounts on paas.build can take payments immediately up to a cap (about £1,500) until background verification (progressive KYB) completes and the cap lifts. Do I need a business bank account? You need somewhere to receive payouts. Many individuals start with a personal or sole-trader account and add a business account later when they incorporate. Go live in one prompt Agentic payments → paas.build · powered by UniPaaS — FCA-authorised Payment Institution (No. 929994) · home · Trust & security · Terms · Privacy · Contact ## Accepting payments as a sole trader (https://paas.build/accept-payments-as-a-sole-trader) Accept payments as a sole trader — go live the same day | paas.build paas .build Subscriptions Platforms Pricing vs Paddle Docs Blog Portal Go live Guide Accepting payments as a sole trader As a sole trader you can accept online card payments without incorporating. The blocker is rarely eligibility — it's the multi-day merchant review. With progressive KYB you go live the same day with a real capped account and verify in the background. Go live in one prompt See pricing → Sole traders are eligible Card schemes and payment facilitators onboard individuals as sub-merchants. You don't need a limited company to accept payments — you need identity and basic business details. paas.build creates a real merchant account for individuals in the same session, capped until progressive KYB completes. What you'll provide Your name and email, the business or product name and its website (we can derive it), your country, and — for verification, in the background — the identity details required by anti-money-laundering rules. No passwords or card numbers are collected on our sign-in pages; portal access uses a one-time email code. Fees and payouts One flat rate: 3.9% per transaction, deducted from settled funds. Payouts settle to your bank account. The underlying service runs on UniPaaS (FCA-authorised, No. 929994), with funds safeguarded as required for a regulated payment institution — see Trust & security . Going live Say "add payments" to your AI agent, or use the go-live prompt on the homepage. You'll receive scoped sandbox and production keys by email and can take a real £1 test payment right away. Drop checkout into a React app in three lines with @paasbuild/react . FAQ Do sole traders pay higher fees? On paas.build the rate is the same flat 3.9% whether you are an individual or a company. How fast can a sole trader go live? The same day. You get a real capped account immediately; verification runs in the background and the cap lifts as it clears. Can I upgrade to a company later? Yes. Many builders start as a sole trader to validate demand and incorporate later; you keep selling throughout. Which countries are supported? paas.build currently supports builders based in the UK, EU and US. Go live in one prompt Agentic payments → paas.build · powered by UniPaaS — FCA-authorised Payment Institution (No. 929994) · home · Trust & security · Terms · Privacy · Contact ## Payment gateway for indie developers (https://paas.build/payment-gateway-for-indie-developers) The payment gateway for indie developers & AI builders | paas.build paas .build Subscriptions Platforms Pricing vs Paddle Docs Blog Portal Go live Guide A payment gateway built for indie developers Indie developers and AI builders ship products in days, then lose a week to payment onboarding. paas.build is a payment gateway designed for that reality: one prompt, a real merchant account the same day, agent-native by default. Go live in one prompt See pricing → The indie payments problem You built the product fast. Then payments ask you to form a company, file for an EIN, wait days in a merchant-approval queue, and wire up webhooks. For a solo developer testing an idea, that overhead is bigger than the build itself — and it's the single most common reason indie projects never charge. What "agent-native" means here paas.build ships with an open-source MCP server , so your AI agent can create the account, not just manage one. Machine-readable docs ( llms.txt ), scoped tokens, and progressive KYB mean the whole onboarding fits in one coding session. Read the thesis on agentic payments . Flat, indie-friendly pricing One rate: 3.9% per transaction. No monthly minimums, no per-feature upsells. Individuals go live the same day — no company required to start. Works with your builder Whether you vibe-code in Lovable , Bolt , Cursor , Claude Code or Replit , adding payments is one prompt. Checkout drops into React in three lines with @paasbuild/react . FAQ What is the best payment gateway for indie developers? The best fit is one that lets you start without a company and go live the same day. paas.build is built for that: one prompt, a real capped merchant account immediately, flat 3.9%, and an open MCP server so your AI agent can set it up. Do I need a company to use paas.build? No. Individuals can go live the same day with a capped account; verification completes in the background. How is this different from Stripe? Stripe's tools manage an account you've already set up. paas.build's agent-native flow creates the account for you in one session, with progressive KYB so there's no multi-day review before you can charge. Can my AI agent set up payments end to end? Yes — that is the design. Via the MCP server the agent can identify the business, create the account, and mint checkout links without a human filling forms. Go live in one prompt Agentic payments → paas.build · powered by UniPaaS — FCA-authorised Payment Institution (No. 929994) · home · Trust & security · Terms · Privacy · Contact