Payments
3 apps liveTake money on PayBito's payments rails — as a merchant with a storefront, as a third-party app reading a merchant's data under OAuth, or as the operator of the whole platform.
How it was builtThe PayBito MCP prompts that generated this app — click to view7 steps▶
This storefront wasn't hand-specced — the PayBito MCP drove a short, one-question-at-a-time intake in Claude Code, locked in exactly what to build, then wrote it. Here's that real run:
01 Connect with claude mcp add paybito -- npx -y paybito-mcp, say “use paybito”, and pick Buyer storefront from the top-level menu.
02 Scope: storefront only (PayBito's portal is the admin) — no admin to build.
03 Frontend stack — Next.js (best for SEO/SSR); the key stays on the backend, never the browser.
04 Backend + database — Node (Express/Nest) + MySQL: holds the key, buyer accounts, orders (by PCN), cart, webhook log.
05 Test or Live — account-dependent sandbox; keys kept in separate env vars.
06 Domain — PayBito (service.hashcashconsultants.com / portal.paybito.com) or a custom broker domain (checkout at your-domain/payments). You give the bare domain; the MCP appends the fixed paths.
07 Perfect knowledge locked in — the MCP recaps every answer, pulls the exact PayBito operation specs, and builds the storefront + thin backend gateway, one module at a time.
How it was builtThe PayBito MCP intake that produced this app — click to view5 steps▶
An App-Store app is a different animal from the storefront — it doesn't own a platform, it consumes one on a merchant's behalf. The MCP routes to that answer with a single question, then hands over the exact capability map for the tile you picked.
01 The routing question. Connect with claude mcp add paybito -- npx -y paybito-mcp, say “use paybito”, and answer the one question that decides everything: what are you building? Not a merchant, not a broker — an App-Store developer, consuming a platform's data via OAuth scopes.
02 Which tile? Payments Platform — which routes to the payments-platform-app playbook. That single answer fixes the base host (service.hashcashconsultants.com), the consent screen (portal.paybito.com/payments/authorize), and the auth realm.
03 The capability map. The MCP lays out all 50 read operations grouped by the 8 scopes that unlock them — then insists on the minimum. This app needs payments.product.read for the catalog and payments.report.read for the sales overlay. Nothing else is requested, because installers see and consent to every scope you ask for.
04 The auth realm — and the trap. Every data call on the payments tile needs three headers: Authorization: Bearer, X-CLIENT-ID, and uuid. That third one is unique to payments (launch and exchange send only two), it is returned only by the token call, and without it a perfectly valid, correctly-scoped token is denied with a bare 403. The MCP names it up front.
05 Exact specs, then build. paybito_get_operation returns the real request/response shape for each op — getAllCatalogs, getProductDetails, getMerchantTopProducts — including each report's nested row shape, and the app is written against those, one screen at a time.
How it was builtThe PayBito MCP intake that produced this app — click to view5 steps▶
Same tile, same auth, a completely different app — which is the point of the capability map. The MCP's operation specs are also what kept this one honest: they say what an endpoint returns, and where they stop, the app has to go and look.
01 Role, then tile. App-Store developer → Payments Platform, exactly as above. The plumbing — the OAuth handshake, the two-part state, the Redis-backed session — carries straight over from the previous app, because the auth realm is identical.
02 Two scopes, and one refused. payments.transaction.read is the engine. payments.refund.read flags buyers who keep sending things back. The MCP's own scope table showed that payments.profile.read returns the merchant's buyer-info collection profiles — which checkout fields they ask for — and not actual buyers. So it wasn't requested. Reading the map stopped us asking a merchant to consent to something useless.
03 The engine. paybito_get_operation("post_transactions_byFilter") gives the paginated ledger call, its filters, and the flattened transaction row. Every page is walked server-side and folded into people — which is all RFM really is.
04 The traps, named up front. Three things would otherwise have shipped as plausible, wrong pages: customerIdentity is a KYC status (the literal string "VERIFIED"), not a person; the date is paymentCreatedAt, not createdAt; and paidAmount is 0 on anything that didn't settle. Every one of them is now in the op's own notes — this app is why.
05 Read-only, and provably so. All 50 operations on this surface are reads — the playbook is explicit that if a design needs a write, it is not on this surface and you must not invent one. Buyer Lens cannot move money, refund an order, or edit a customer.
Design your own Payments Platform
Not a store on someone's platform — the platform itself: merchant onboarding, catalogs, checkout, settlement and the admin console behind it, white-labelled to your own domain. The MCP already ships the full merchant-admin playbook (~99 operations across 7 modules) that drives this build; the public demo is still being wired.
Start it yourself — Setup Guide ↗Exchange & Financial Services
1 app liveThe trader surface: spot, futures, options, margin, earn, loans and portfolio. A different host and a different auth realm from Payments — which is the single most common thing to get wrong when carrying code across.
Build Store Front — Exchange
The trader-facing front end on top of PayBito's exchange: markets, order entry, wallets and portfolio, with the keys held server-side. The MCP's exchange feed is live today — six playbooks over the /TraderApi surface, with the base64-vs-bearer auth split documented — so the build is available now even though this demo isn't.
How it was builtThe PayBito MCP intake that produced this app — click to view5 steps▶
Same role as the two payments apps — App-Store developer — but a different tile, and that one answer changes the host, the headers and the identifiers. This is exactly what the MCP exists to stop you guessing at:
01 Role, then tile. App-Store developer → Exchange Platform (trader surface). The base host is fixed at accounts.paybito.com/TraderApi. The /api/… form you'll see in the spec is the white-label deployment — the MCP is explicit that an App-Store app never uses it.
02 A different auth realm — and this one has no uuid header. Realm oauth-appstore: data calls send two headers plus Origin — Authorization: Bearer and X-CLIENT-ID. Carrying the payments habit over here is the mistake; the MCP flags the split.
03 Where the uuid actually lives. It travels in the request body of per-user ops — and it is the principalId from the token response: same value, two names. There is no way to look it up afterwards, so it's persisted at token time. Two more identifiers the balance ops need (userId, customerId) come from GetUserDetails, captured once at connect.
04 The scope map shapes the app. "Everything you own" is the most scope-hungry app on this surface — up to ten trader.*.read scopes. Rather than demand all ten, the map became the architecture: every product is an independent panel, and the net-worth number is always "the sum of what we could actually read," labelled with exactly what that includes.
05 Exact specs, then build. paybito_get_operation per balance op, then Next.js 14 + TypeScript with Redis-backed sessions so tokens never reach the browser. Read-only throughout: Net Tally cannot place an order, transfer, or withdraw.
Design your own Exchange Platform
The white-label build: your own branded exchange and financial-services platform, on your own domain, with PayBito's matching engine, wallets and compliance underneath. The MCP already carries the operation feed and the ICO/contract-owner playbook for it; the public demo is still being wired.
Start it yourself — Setup Guide ↗Launch Platform
no demo yetThe broker surface — 180 operations under the fixed /BrokerApi base. The cleanest of the three App-Store tiles: one realm, no dual-realm complication.
Publish on the Launch (Broker) App Store
Realm oauth-appstore over 180 broker operations, all under the fixed /BrokerApi base. The launch-platform-app playbook is shipped and ready in the MCP; no public demo app has been built on it yet.
BitoCircle
no demo yetBuild your own social commerce experience.
Build your own social commerce experience
Where the feed and the checkout are the same surface: creators, communities and merchants selling inside the conversation rather than beside it. No demo app has been published on BitoCircle yet — this section is here so it has a home the moment one is.
Setup Guide ↗