Home / Journal / Engineering

WhatsApp Ordering: Technical Tradeoffs

Building an ordering system on WhatsApp Business API ÔÇö what works, what does not, and what we would do differently.

Why WhatsApp for Ordering?

In Pakistan, WhatsApp has ~95% smartphone penetration. Building a dedicated app for food ordering means convincing customers to download something new. Building on WhatsApp means meeting them where they already are.

The Stateless Problem

WhatsApp Business API is stateless. The platform does not maintain conversation state ÔÇö your backend must. We use Redis to store conversation context keyed by phone number with a 30-minute TTL. Each incoming message loads state, processes it, updates state, and sends a reply.

The 24-Hour Window

WhatsApp only allows free-form messages within 24 hours of the last customer message. After that, you must use pre-approved templates. This creates an awkward UX: if a customer abandons an order and comes back the next day, they receive a template message instead of a natural continuation. We handle this with a "restart order" template that re-engages the conversation.

Idempotency is Critical

WhatsApp occasionally delivers the same message twice. Every message handler must be idempotent ÔÇö processing the same message twice must produce the same result as processing it once. We use message IDs as idempotency keys stored in Redis.

What We Would Do Differently

Use a purpose-built conversational commerce platform for complex ordering flows. WhatsApp is excellent for simple, high-volume interactions (order confirmation, delivery updates, support queries). For multi-step ordering with upsells and customisation, the UX constraints are real.

Back to journal
Chat on WhatsApp