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 above — 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 — 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 and its filters. Every page is walked server-side and folded into people — which is all RFM really is.
04 Where the spec stops, go and look. The MCP documents the byFilter envelope but not the shape of a single transaction row — and says so. So we read a real one. Three things would 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.
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.