Adding real payments to a Base44 app (3 insertion points, tested) Oded, co-founder of UniPaaS, tested three methods for integrating external payment providers into Base44 apps: MCP connections, OpenAPI integrations, and backend functions. The MCP connection provisions accounts and scaffolds flows during development, while OpenAPI integrations and backend functions handle runtime charging. The choice depends on whether developers prefer workspace-administered setup or full control over payment logic. 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. 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: 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. 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. 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. 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. The reason to reach past the built-ins at all: 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 https://paas.build/base44 .