A chat can collect intent, show products, answer questions, and report progress. It should not become the database for customers, inventory, orders, payments, shipments, consent, or support ownership. Reliable conversational commerce keeps WhatsApp at the edge and durable systems behind it.
WhatsApp Business Platform is designed to connect messaging with backend and agent systems. That distinction matters. A conversation contains requests, selections, questions, and notifications; the CRM owns customer identity and consent, the product system owns catalog data, the OMS owns the order, the PSP owns payment evidence, and the WMS or carrier owns fulfillment events.
Give every channel action a durable business identifier. A customer may begin in an ad, continue in WhatsApp, pay in a bank app, call support, and receive a shipment event later. The order must survive channel changes, duplicate webhooks, expired sessions, agent transfers, and message delivery failure.
Meta's current policy requires a phone number and opt-in before business-initiated contact. It also requires approved message templates outside the 24-hour customer-service window and clear escalation paths when automation is used. Opt-in is therefore not a checkbox hidden in a CRM note.
Store purpose, category, wording version, source, timestamp, jurisdiction, actor, and revocation. Evaluate that record before every outbound message. Keep order updates, support, recommendations, and promotions as separate preferences so a customer can stop marketing without losing a shipment alert.
Webhook delivery and downstream processing are different concerns. The public endpoint validates the request, stores a minimal immutable event record, applies deduplication, and returns quickly. A worker then resolves schemas, ordering, retries, CRM updates, commands, and outbound messages.
Use the provider event identifier where available plus a content hash and business key. Persist processing state such as received, normalized, routed, applied, ignored, failed, and quarantined. A redelivery must return the prior result rather than create a second cart, order, ticket, or refund.
A WhatsApp number is a channel identifier, not proof of legal identity or account ownership. Maintain explicit links among WABA, business phone, WhatsApp user, CRM contact, customer account, authenticated session, order, and agent conversation. Record how each link was established and its confidence.
Require stronger verification before exposing addresses, invoices, loyalty balances, or making consequential changes. Never ask for full payment-card or bank-account data in chat. Use secure provider journeys and return only masked, purpose-limited status.
Catalog and product messages improve discovery, but a message card is not a binding quote. At selection time, resolve the current SKU, variant, availability, delivery region, price, tax, promotion, and policy. Create a quote snapshot with an expiry and show any change before order confirmation.
Do not let a language model invent product facts, substitute variants, or promise stock. Retrieval should use approved catalog fields, and tool calls should enforce constraints. The model may explain choices; deterministic services calculate and commit them.
A customer message saying “paid,” a screenshot, or a click on a payment link is not settlement evidence. Create a payment intent or Pix charge tied to the order, then consume authenticated provider webhooks or query the provider API. Reconcile provider transaction ID, amount, currency, recipient, status, and timestamps before moving the order.
Model initiated, pending, authorized, paid, failed, expired, canceled, refunded, partially refunded, and disputed separately. Handle webhook duplication and out-of-order transitions. If the customer retries, reuse or explicitly replace the intent under business policy; never create silent double charges.
Keep fulfillment state in the OMS/WMS and project selected events into WhatsApp. Useful events include allocated, picking, packed, handed to carrier, in transit, out for delivery, delivery attempt, delivered, pickup available, return requested, received, and refunded. Preserve event time, source, location precision, and exception reason.
GS1 EPCIS is useful when multiple organizations need a shared vocabulary for what happened, when, where, and why. Even without full EPCIS adoption, keep carrier-specific payloads behind an adapter and publish stable internal events.
Meta policy requires clear escalation options when automation is used. Engineering should go further: handoff is a durable state with reason, priority, owner, queue, SLA, conversation summary, verified identity, consent, cart/order/payment/shipment state, attempted actions, errors, and the next recommended step.
Transfer immediately when the customer asks, identity is insufficient, policy blocks the request, payment or delivery is disputed, vulnerability is detected, confidence is low, or a tool fails repeatedly. Pause competing bot actions while the agent owns the case and define how control returns.
AI can classify intent, translate, summarize, retrieve product and policy text, extract structured fields, suggest replies, and select an approved tool. It should not directly update prices, issue refunds, change addresses, or mark payments complete. Those operations belong to authenticated APIs with schema validation, authorization, limits, and audit.
Guard against prompt injection in customer text, product descriptions, CRM notes, and retrieved documents. Separate instructions from data, allowlist tools, validate arguments, redact sensitive fields, and evaluate the complete trace rather than only the final reply.
| Customer intent | Automation path | Required evidence | Outbound response | Handoff trigger |
|---|---|---|---|---|
| Browse or ask about a product | Catalog retrieval, availability and region checks, bounded recommendation. | Approved catalog version, locale, current stock/price visibility. | Product or interactive message with qualification and expiry where needed. | Ambiguous regulated item, unsupported region, conflicting product data. |
| Create or modify cart | Resolve SKU and variant, price snapshot, cart version, idempotent mutation. | Customer/cart link, quote, promotion rules, inventory policy. | Updated cart summary and explicit confirmation. | Price dispute, unavailable substitution, complex bundle or policy exception. |
| Pay for order | Create provider intent/Pix charge and monitor provider events. | Order totals, recipient, provider transaction, authenticated payment status. | Secure payment journey, pending status, then confirmed receipt. | Amount mismatch, duplicate payment, fraud signal, dispute, provider uncertainty. |
| Track delivery | Read OMS/WMS projection and carrier adapter events. | Authenticated order access, latest event time/source, exception state. | Current milestone, timestamp, next expectation, approved tracking link. | Repeated failure, lost parcel, address problem, stale carrier data. |
| Return or refund | Eligibility engine, return authorization, label/pickup, refund workflow. | Order item, delivery evidence, policy version, reason, payment rail. | Steps, deadlines, authorization and verified refund status. | Policy exception, damaged/high-value item, partial settlement, complaint. |
| Speak to a person | Create/attach case, freeze bot writes, route by skill and priority. | Summary, identity, consent, lifecycle state, actions, error trail. | Ownership confirmation and realistic service expectation. | Immediate by definition; never force another automation loop. |
Correlate message ID, conversation, contact, cart, quote, order, payment intent, shipment, case, agent, and trace. Track webhook acceptance and lag, duplicate rate, template rejection, send/delivery/read status, automation completion, tool failure, handoff delay, payment confirmation latency, inventory release, fulfillment exceptions, and refunds.
Business metrics should include conversion after verified quote, paid-order completion, duplicate-charge prevention, first-contact resolution, repeat contact, unresolved exceptions, opt-out and block rate, delivery promise accuracy, and cost per completed order. A high bot containment rate can still hide failed payments and abandoned customers.
Test duplicate and reordered webhooks, expired templates, revoked consent, changed phone numbers, merged CRM contacts, price changes after selection, stock loss, payment success before response, delayed Pix notification, duplicate charge attempts, carrier outages, stale tracking, partial shipment, return after handoff, and agent/bot races.
Use replayable fixtures with sensitive data removed. Assert final business state and emitted events, not only response text. Reconciliation jobs must detect paid-but-unreleased orders, shipped-but-unnotified orders, refunds without customer confirmation, and conversations without an owner.
I would build a channel adapter around the WhatsApp Cloud API, an immutable webhook inbox, identity and consent service, conversation router, catalog adapter, cart/quote service, OMS, payment orchestration layer, fulfillment event projection, policy-controlled tool gateway, agent workspace, and an outbound notification service aware of templates and customer-service windows.
The central contract would be an order lifecycle API and event stream. WhatsApp, web, mobile, email, and agents would read and act through the same state machine, so adding a new channel would not fork payment or fulfillment logic.
Conversational commerce succeeds when the conversation feels simple because the backend is explicit. Keep identity, consent, prices, inventory, payment, logistics, ownership, and audit in durable systems. Let WhatsApp present the journey, not become the journey's only memory.
Article about WhatsApp commerce automation, including Cloud API webhooks, consent, CRM identity, catalog and quote state, order management, Pix and payment confirmation, logistics events, AI tools, human handoff, testing, security, and observability.