How to: Build a WhatsApp E-commerce Flow

How to: Build a WhatsApp E-commerce Flow - zero platform subscription cost Part 2

Overview

If you’re a WhatsApp Solution Partner and can avoid BSP fees, we’ll optimize the design for zero platform subscription cost while calling out where message or payment fees may still apply. I’ll give a compact, implementation‑ready structure: component choices, exact backend responsibilities, message flows, sample API payloads you can copy into Postman, a DB schema sketch, and a prioritized rollout checklist so your engineers can build and ship quickly.

Decision table for a cost‑optimized build

Component	Cost‑free option	When to choose paid option	Tradeoff
Catalog host	Host catalog in your DB + serve images from your CDN	Use WhatsApp Catalog for faster UI if you want WhatsApp‑native product cards	Full control and no WhatsApp catalog limits vs faster integration with WhatsApp product messages
Messaging provider	Direct WhatsApp Cloud API via your Solution Partner access	Use BSP only for managed features or regional compliance help	Lower recurring cost; you must handle templates, rate limits, retries
Payments	Hosted checkout (Stripe/PayPal/local PSP) with one‑time links	In‑chat payments if available in market and you want fully native UX	Hosted links avoid PCI scope and are universally available; in‑chat reduces friction but has limited availability and onboarding
Order management	Your existing OMS or lightweight orders DB	Third‑party OMS for complex fulfillment or multi‑warehouse	Faster control and no extra fees vs advanced features and integrations

Architecture and responsibilities

Components and responsibilities

WhatsApp Cloud API
- Send interactive messages, lists, and templates; receive webhooks for incoming messages and message status.
Backend service (your domain)
- Endpoints: /webhook (WhatsApp), /create-order, /checkout-session, /payment-callback, /catalog-sync.
- Responsibilities: map WhatsApp events → product SKUs; create provisional orders; reserve inventory; generate checkout links; verify payment webhooks; send templates for confirmations.
Database
- Products table, Variants, Orders, Customers, MessageLogs, Reservations (short TTL).
CDN / Media host
- Serve HTTPS images sized for WhatsApp (recommend 800×800 or 1024×1024).
Payment gateway
- Create one‑time checkout sessions; return success/failure webhooks to /payment-callback.
Optional Webview
- Lightweight order form for address capture and variant selection (mobile‑first).

Data model and sync strategy

Minimal schema (columns shown as field: type)

products: id: string; sku: string; title: string; description: text; price_cents: int; currency: string; images: json; active: bool; updated_at: timestamp
variants: id: string; product_id: string; title: string; price_delta_cents: int; stock: int
orders: id: uuid; external_id: string; customer_phone: string; items: json; subtotal_cents: int; shipping_cents: int; tax_cents: int; total_cents: int; payment_status: enum; fulfillment_status: enum; created_at: timestamp
reservations: id: uuid; order_id: uuid; sku: string; qty: int; expires_at: timestamp

Sync approach

One‑way sync from your DB → WhatsApp product IDs (if you use WhatsApp Catalog) or simply serve product cards from your backend when user requests a list. Update stock every 1–5 minutes; use reservations during checkout to avoid oversell.

Message flows and sample API payloads

Core flows

User initiates (clicks link or messages number).
Send product list (interactive product_list or list message).
User selects product → backend creates provisional order + reservation.
Send order summary + checkout link (hosted).
User pays → PSP webhook to /payment-callback → mark order paid → send template confirmation and tracking updates.

Sample: send product list (interactive product_list)

POST https://graph.facebook.com/v18.0/{Phone-Number-ID}/messages
Authorization: Bearer {ACCESS_TOKEN}
{
  "messaging_product":"whatsapp",
  "to":"whatsapp:+60XXXXXXXXX",
  "type":"interactive",
  "interactive":{
    "type":"product_list",
    "header":{"type":"text","text":"Featured products"},
    "body":{"text":"Tap a product to view details"},
    "footer":{"text":"Free shipping over RM100"},
    "action":{
      "catalog_id":"{CATALOG_ID}",
      "sections":[
        {"title":"Featured","product_items":[{"product_retailer_id":"SKU123"},{"product_retailer_id":"SKU456"}]}
      ]
    }
  }
}

Sample: create provisional order (your backend)

POST /create-order
Content-Type: application/json

{
  "customer_phone":"+6012XXXXXXX",
  "items":[{"sku":"SKU123","variant_id":"V1","qty":1}],
  "source":"whatsapp",
  "metadata":{"wa_message_id":"wamid.HBgL..."}
}

Sample: generate hosted checkout link (Stripe example)

Create a Checkout Session server‑side and return session.url to user in WhatsApp message. On success Stripe calls your /payment-callback webhook.

Implementation roadmap and checklist

Phase 1 MVP (2–4 weeks)

[ ] Provision WhatsApp Business assets and confirm Solution Partner access.
[ ] Build backend endpoints: /webhook, /create-order, /checkout-session, /payment-callback, /catalog-sync.
[ ] Implement product list and product detail message handlers.
[ ] Integrate Stripe/PayPal for hosted checkout and webhook verification.
[ ] Implement reservations with TTL to prevent oversell.
[ ] Submit and get approval for order confirmation and shipping update templates.
[ ] Run end‑to‑end tests: selection → order → payment → confirmation.

Phase 2 Production (4–8 weeks)

[ ] Full catalog sync automation; incremental updates.
[ ] Add webview for address capture and optional guest checkout.
[ ] Implement idempotency and retry logic for webhooks.
[ ] Add analytics: conversion rate, message delivery, payment success.

Phase 3 Enhancements

[ ] In‑chat payments where available.
[ ] Personalization, abandoned cart flows, multi‑language templates.
[ ] Integrate with ERP/warehouse for fulfillment automation.

Key risks and mitigations

Message costs and template approvals — even with free Cloud API access, WhatsApp charges per message in many markets and templates must be preapproved. Submit templates early and design flows to minimize template usage. .
Payment availability — in‑chat payments are limited by country; always provide hosted checkout fallback. .
Inventory race conditions — use short TTL reservations and atomic stock decrements.
Compliance and PCI — use PSPs to avoid handling raw card data.

Next deliverables I need to produce

I will generate any of the following (refer to this site How to: Build a WhatsApp E-commerce Flow - Postman Collection Ready for WhatsApp Commerce Part 3 for detailed guide)

Full set of WhatsApp message templates (order confirmation, shipping update, abandoned cart) preformatted for WhatsApp submission.
Complete Postman collection with the exact Cloud API requests for product_list, product message, and webhook verification (copy‑paste ready).
SQL migration script for the minimal schema above.
Detailed webhook handler pseudocode (idempotency, signature verification, retries).

Based on your Solution Partner role, I recommend to generate the Postman collection + webhook handler pseudocode first so your engineers can run end‑to‑end tests immediately.

How to: Build a WhatsApp E-commerce Flow - Part 2