Ad Code

How to: Building a WhatsApp E-commerce Flow

 How to Build a Whatsapp E-commerce Flow

Project scope and assumptions

Assumed goal — Build a WhatsApp-first purchase flow that lets any buyer browse your existing e‑commerce catalog inside WhatsApp, select items, complete checkout, and receive order confirmations and tracking — similar to Take App. I will map the full architecture, message flows, data model, API calls, webhook events, payment options, and a rollout checklist so your engineering team can implement it directly.

Platform choice — this plan uses the WhatsApp Cloud API / WhatsApp Business Platform for sending interactive catalog messages and receiving webhooks; it supports product messages and interactive templates required for in‑chat commerce.


Quick decision table: core components to choose now

Component Option A Option B Tradeoff
Catalog host WhatsApp Catalog (Cloud API) External product service (your DB + CDN) WhatsApp Catalog = fastest to show products; external = more control and richer metadata
Messaging provider Direct Cloud API BSP / third party (Infobip, Twilio) Direct = lower cost, more control; BSP = easier onboarding, extra features
Payments In‑chat payments (where available) Hosted checkout (Stripe/PayPal/Local) In‑chat = best UX; hosted = broader payment methods and simpler compliance
Order management Your OMS Third‑party order manager Your OMS integrates with inventory and fulfillment; third‑party speeds launch
Authentication Phone number + OTP Customer account on site OTP is frictionless; accounts enable repeat purchase features

1. End‑to‑end user journey (high level)

  1. Discovery — customer clicks a product link (link‑in‑bio, ad, website) or messages your WhatsApp number.
  2. Catalog presentation — send a catalog message or interactive list showing product cards with image, price, short description.
  3. Product details — user taps a product card to open the product view inside WhatsApp (media, description, variants).
  4. Order form — interactive message or webview collects variant, quantity, shipping address, and contact details.
  5. Payment — user pays via in‑chat payment or a secure hosted checkout link.
  6. Order confirmation — send receipt, order ID, and tracking updates via WhatsApp messages and webhooks.
  7. Post‑purchase — automated follow ups: delivery updates, feedback request, cross‑sell messages.

Why this works — WhatsApp supports catalog and single product interactive messages and webhooks for order lifecycle events; combining interactive messages with a hosted checkout or in‑chat payments closes the loop inside the chat.


2. Data model and mapping from your existing catalog

Core entities

  • Product

    • id (string) — unique SKU
    • title (string)
    • description (string)
    • price (integer cents + currency)
    • images (array of URLs)
    • variants (array: id, title, price delta, stock)
    • weight / dimensions (for shipping)
    • metadata (category, tags)

  • CatalogItem for WhatsApp

    • product_retailer_id (WhatsApp field)
    • image_url
    • currency
    • price
    • short_description
  • Order

    • order_id
    • customer_phone
    • items (product_id, variant_id, qty, unit_price)
    • subtotal, shipping, tax, total
    • payment_status
    • fulfillment_status
    • timestamps

  • Sync strategy

    • One‑way sync from your product DB to WhatsApp Catalog via the Catalog API for initial launch; schedule incremental updates (price, stock) every 5–15 minutes or via event hooks from your inventory system. Use product SKU as the canonical key to map WhatsApp product entries back to your DB.

3. Technical architecture and components

High level components

  • WhatsApp Cloud API — send messages, catalog messages, templates.
  • Backend service — exposes endpoints for: incoming webhook handling, catalog sync, order creation, payment verification, and fulfillment triggers.
  • Database — products, orders, customers, message logs.
  • Media CDN — host product images (HTTPS) for WhatsApp.
  • Payment gateway — Stripe/PayPal/local PSP or WhatsApp in‑chat payments where available.
  • Frontend micro‑webview (optional) — for complex order forms or hosted checkout inside WhatsApp webview.

Message flow diagram (conceptual)

  • User → WhatsApp → Cloud API → your webhook → backend → (create order) → payment gateway → backend → Cloud API → user.

4. WhatsApp API specifics and sample payloads

Send a catalog message

Use the Cloud API POST /{Phone-Number-ID}/messages with interactive payload type and product object for single product messages or product_list for multiple. Example (simplified):

POST https://graph.facebook.com/v18.0/{Phone-Number-ID}/messages
Authorization: Bearer {ACCESS_TOKEN}
{
  "messaging_product": "whatsapp",
  "to": "whatsapp:+6012XXXXXXX",
  "type": "interactive",
  "interactive": {
    "type": "product_list",
    "header": {"type": "text", "text": "Our bestsellers"},
    "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"}]
        }
      ]
    }
  }
}

Webhook events to handle

  • messages — incoming user messages and interactive replies.
  • message_status — delivery/read receipts.
  • payments — payment confirmation events (if using in‑chat payments).
  • product_update — catalog changes (if using WhatsApp catalog webhooks).

Order creation flow

  1. Receive product selection event (interactive reply).
  2. Create provisional order in DB with payment_status: pending.
  3. Send order summary and payment link or trigger in‑chat payment.
  4. On payment webhook, mark payment_status: paid and send confirmation.

5. Payments and checkout options

Option 1 In‑chat payments

  • Best UX: user pays without leaving WhatsApp. Availability depends on country and WhatsApp Pay rollout. Requires additional onboarding and compliance.

Option 2 Hosted checkout

  • Generate a secure one‑time checkout link (Stripe Checkout, PayPal, local PSP). Send link in WhatsApp message or open in webview. On success, PSP calls your webhook to confirm payment.

Recommendation — support both: prefer in‑chat payments where available; fallback to hosted checkout for markets not supported.


6. Automation, templates, and UX details

Templates and interactive elements

  • Message templates for order confirmation, shipping updates, abandoned cart reminders (must be pre‑approved by WhatsApp).
  • Interactive buttons for quick actions: View Cart, Checkout, Contact Support.
  • List messages for category selection; product list for catalog browsing.

UX rules

  • Keep product cards concise: image, price, short title.
  • Use quick replies for common choices (size, color).
  • Limit friction: prefill phone and address where possible; use WhatsApp profile phone as default.

7. Inventory, fulfillment, and reliability

Inventory sync

  • Push stock changes to WhatsApp Catalog or mark items as unavailable in your backend and prevent checkout. Sync frequency depends on sales velocity; high‑volume SKUs should be updated in near real time.

Fulfillment

  • After payment, trigger fulfillment workflow: pick, pack, ship. Send tracking number via WhatsApp template message.

Resilience

  • Implement idempotency keys for order creation and payment processing. Log all incoming webhooks and message IDs for reconciliation.

8. Security, compliance, and WhatsApp policies

  • Data privacy — store only necessary PII; encrypt sensitive fields at rest.
  • WhatsApp commerce policy — follow WhatsApp commerce policies for prohibited items and message templates.
  • PCI compliance — if you handle card data, use a PCI‑compliant PSP and avoid storing raw card data.

9. Testing, rollout, and monitoring

Testing checklist

  • Sandbox messages and template approvals.
  • End‑to‑end test: product selection → order creation → payment → webhook confirmation → fulfillment message.
  • Edge cases: duplicate payments, failed payments, out‑of‑stock during checkout.

Monitoring

  • Track message delivery rates, template rejections, payment success rate, conversion rate from message to paid order, and average time to fulfill.

Rollout plan

  1. MVP: 50 SKUs, hosted checkout, manual fulfillment.
  2. Phase 2: full catalog sync, automated fulfillment, payment gateway integration.
  3. Phase 3: in‑chat payments, advanced personalization, multi‑language templates.

10. Implementation checklist for engineers

  • [ ] Create Meta Business assets: Business Manager, WhatsApp Business Account, Phone Number.
  • [ ] Implement backend endpoints: /webhook, /create-order, /payment-callback, /catalog-sync.
  • [ ] Build catalog sync job: map SKU → product_retailer_id.
  • [ ] Host product images on HTTPS CDN.
  • [ ] Integrate payment gateway and implement webhook verification.
  • [ ] Register and submit message templates for approval.
  • [ ] Implement logging, monitoring, and retry logic for webhooks.
  • [ ] Run full QA and pilot with a small customer segment.

Key risks and mitigations

  • Payment availability varies by country — implement hosted checkout fallback.
  • Template approval delays — submit templates early and keep fallbacks for unapproved templates.
  • Inventory race conditions — use reservations with short TTL during checkout to avoid overselling.

Next is to generate the exact API request examples for your backend (webhook verification, catalog sync payloads, order creation JSON), a DB schema migration script, and a message template list preformatted for WhatsApp template submission so your engineers can copy‑paste them into Postman and your codebase.

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

Post a Comment

0 Comments