Inspiration
Card rails are making it too expensive for small businesses to turn a profit. Interchange fees, monthly minimums, and opaque pricing structures eat into margins that SMBs can't afford to lose. Meanwhile, Europe is actively shifting toward SEPA and CB rails, and the open banking infrastructure underpinning that shift is genuinely mature — it just isn't accessible to the average business owner. VitePay's goal is to bridge that gap: give SMBs a dead-simple pay-by-bank experience without requiring them to understand what "open banking" means.
The WhatsApp angle came from the same place. The average UK/EU SMB already runs their customer relationships inside WhatsApp — orders, questions, follow-ups, all of it. Making them switch channels to collect payment is friction they shouldn't have to deal with. VitePay brings the payment link into the conversation.
What it does
VitePay lets merchants collect bank payments from their customers — directly inside WhatsApp, without leaving the chat.
A merchant connects their WhatsApp Business Account to VitePay. Their customers browse products from the native WhatsApp catalog, send a cart, and immediately receive a branded payment link in the same chat thread. They tap it, authenticate with their own bank (a PSD2-required step no pay-by-bank product can route around), and the payment is confirmed. The merchant gets an alert; the customer gets a receipt — both back in the chat.
On the merchant side, VitePay provides a branded payment experience: merchants upload their logo and description, and every payment link renders as a custom, SEO-optimised page rather than a generic redirect. Bots are filtered at the payment-page level via Cloudflare Turnstile.
How we built it
Frontend: Next.js 15 (App Router), tRPC for type-safe API calls, better-auth for session management with Google and Facebook OAuth.
Backend: tRPC API router + plain Next.js Route Handlers for webhook endpoints (webhooks can't go through tRPC's transport since Meta and TrueLayer speak plain HTTP, not tRPC's RPC contract — this was an important architectural distinction to get right early).
Database: AWS Aurora (PostgreSQL-compatible), accessed via Drizzle ORM. Migrated from Neon during this hackathon — the Drizzle abstraction meant the migration was a connection-string change with zero application-code impact.
Open banking: TrueLayer for payment initiation and webhook confirmation. The payment-link generation, bank redirect, and settlement-confirmation loop are all wired up end-to-end.
WhatsApp: Meta WhatsApp Business Cloud API. We set up a WABA (WhatsApp Business Account), linked a product catalog via the Catalog API, and built a webhook receiver that parses incoming order events, creates an order record in Aurora, generates a TrueLayer payment link, and sends it back into the originating chat thread.
Object storage: S3-compatible bucket for merchant logo uploads, accessed via presigned URLs generated server-side — files go browser-to-bucket directly, never proxied through the Next.js server.
Bot protection: Cloudflare Turnstile on the public payment page.
Hosting: Vercel, with Aurora in AWS and the WhatsApp webhook endpoint exposed as a standard Next.js Route Handler.
Challenges we ran into
Aurora DSQL vs Aurora Serverless v2: We initially explored Aurora DSQL (the new distributed SQL engine) before landing on Aurora Serverless v2 (PostgreSQL-compatible). They are genuinely different products — different API surfaces, different connection models, different compatibility with Drizzle's query layer. Getting clarity on which one actually fit our stack cost real time.
WhatsApp Business API onboarding complexity: The WABA setup process is genuinely non-trivial. Catalog management, phone number registration, webhook subscription, and catalog-to-WABA linking each live in different Meta products (developer console, WhatsApp Manager, Commerce Manager, Business Suite) with no single unified interface.
Accomplishments that we're proud of
- AWS Aurora integration: a clean, zero-application-code-change migration from our previous Postgres provider, validating the Drizzle ORM abstraction strategy.
- WhatsApp checkout flow: a working end-to-end order-webhook → payment-link → bank-redirect → receipt loop, fully integrated with Meta's Cloud API.
- Branded, SEO-optimised payment pages: merchants can upload a logo and description; every payment link renders as a custom page rather than a generic bank redirect.
- Cloudflare Turnstile bot protection: integrated directly on the public payment portal, keeping automated abuse off the payment-initiation endpoint.
- Multi-tenant architecture by design: the schema and webhook-routing logic are built for N merchants from day one — each merchant has their own WABA, their own catalog, and their own isolated order/payment records in Aurora, with the WABA ID as the inbound disambiguation key.
What we learned
- The real differences between AWS database products: Aurora DSQL, Aurora Serverless v2, and Aurora standard instances are not interchangeable — each has a different operational model, different connection handling, and different ORM compatibility surface.
- Vercel's direct AWS integrations: first time using Vercel's native Aurora/RDS integration rather than a third-party Postgres provider.
- The full WhatsApp Business Cloud API integration lifecycle: WABA creation, catalog setup, webhook subscription, signature verification, message templating, and the multi-product Business Manager account model that underlies all of it.
- The architectural distinction between tRPC procedures and plain Route Handlers for webhook endpoints — and why mixing them incorrectly breaks Meta's webhook verification handshake.
What's next for VitePay
- Facebook Embedded Signup: let merchants connect their own WhatsApp Business Account directly from the VitePay dashboard via Meta's OAuth flow, rather than requiring manual WABA provisioning.
- Catalog import from Meta Business profile: sync merchant products automatically from their existing Commerce Manager catalog rather than requiring manual entry.
- Order-event-driven payment link generation: trigger the payment link automatically the moment a customer sends a WhatsApp cart — the webhook receiver and order orchestrator are already in place; this is the next integration step.
- WhatsApp Flows for in-chat bank selection: use Meta's native Flows UI to let customers select their bank without leaving the chat, reducing the payment journey to a single external step (bank authentication) rather than any browser redirect.
- x402 and AI agent payments: position VitePay as a payment rail for AI-native applications — MCP apps, agent-to-agent commerce, and chat-native checkout flows where a human isn't necessarily in the loop at payment time.
- Broader SMB platform integrations: extend beyond WhatsApp to other SMB-facing marketplaces and tooling where pay-by-bank is a natural fit.
Built With
- aurora
- next.js
- nextjs
- postgresql
- trpc
- truelayer
- turnstile
- typescript
- whatsapp-cloud-api

Log in or sign up for Devpost to join the conversation.