Developer walkthrough
Website checkout to WhatsApp fulfilment.
One Next.js application owns the customer UI, server-side Whats91 calls, signed webhook receiver and journey confirmation. Whats91 itself remains unchanged.
Open from WhatsApp
A Flow Builder website button opens a journey with ?phone={{contact.phone}}. The app validates the Indian recipient and never exposes the API token.
Create the payment order
The server rebuilds prices from hard-coded fixtures and calls POST /api/v3/orders/send with an idempotency key and explicit sender_id.
Verify payment events
Whats91 Webhooks V2 posts payment events. The receiver verifies the raw-body HMAC and timestamp with Whats91's signing secret before deduplicating eventId.
Fulfil after payment
A paid event schedules post-response fulfilment: metro sends a signed QR image, the kitchen sends an ETA, and the bookshop sends an itemized receipt.
Required Whats91 setup
Account checklist
- Active customer API token scoped to the demo sender
- Orders & Payments add-on and an ACTIVE payment config
- Webhooks V2 access on the same sender
- Public HTTPS app URL and registered payment events
- Optional approved confirmation template for closed windows
Database-free recovery
What survives a restart
Journey metadata is encoded into the Whats91 order note and item retailer ids. An unknown order can be fetched from Whats91 and rebuilt before fulfilment.
In-memory dedupe and sent-state do reset. Whats91 event IDs and the local fulfilment guard prevent duplicates during a running process, but a crash after acceptance and before state recording retains a documented residual duplicate-confirmation risk.