Copy-ready message structures that make the order state, next action, timing and support path clear without hiding promotions in service updates.
A good WhatsApp order confirmation tells the customer what happened, which order it concerns, what happens next and how to correct a problem. It does not simply say “Order confirmed” when payment is pending, stock is unallocated or the business still needs a COD verification.
The templates below are starting structures. Replace bracketed fields from the real order system, verify current WhatsApp template requirements when the business initiates a Platform message, and keep service messages distinct from promotional permission. Use GPTWala’s WhatsApp selling guide for the complete operating context.
Start with the exact order state
| State | What it means | Do not call it |
|---|---|---|
| Placed | Order record created | Paid or dispatched |
| Payment pending | Payment not confirmed | Confirmed paid order |
| Paid/accepted | Payment or approved order state recorded | Shipped |
| COD verification required | Business needs customer confirmation | Ready for delivery |
| Dispatched | Shipment handed to carrier with tracking if available | Out for delivery |
| Delivered | Carrier/order record shows delivery | Customer satisfied |
| Cancelled/refund initiated | Order stopped or refund process started | Refund completed |
Required fields for an order message
| Field | Purpose | Safety rule |
|---|---|---|
| Business name | Identifies the sender | Use the customer-facing legal/trading identity |
| Order reference | Links the message to one order | Avoid exposing more personal data than needed |
| Current state | Explains what is true now | Use system state, not assumption |
| Item summary | Lets customer spot mistakes | Use exact SKU/variant/quantity |
| Amount/payment state | Clarifies money due or received | Never request unsafe payment details in chat |
| Next step and timing | Sets expectation | Use honest windows, not false precision |
| Support/correction path | Allows action when wrong | Route to a monitored channel |
Template: order placed, review pending
Order: [reference]
Items: [short item/variant/quantity summary]
Total: [currency and amount]
Current status: We received your order and are checking [payment/stock/details]. This is not a dispatch confirmation.
Next update: [event or honest time window]
Need a correction? Reply with [reference] before [cutoff if real].
Use this when the order record exists but acceptance is not final. If stock is allocated immediately, say so only when the system confirms it. The message should match the order page and staff view.
Templates: paid and payment pending
Payment confirmed
Order: [reference]
Amount received: [currency and amount]
Items: [summary]
Next step: We will prepare the order. Expected dispatch: [honest window].
We will send tracking after carrier handover. For corrections, reply [instruction].
Payment pending or failed
Order attempt: [reference]
We have not recorded a successful payment. Please check your bank/payment app before retrying to avoid a duplicate charge.
Use only this official payment path: [safe link or in-app instruction].
If money was debited, reply with [non-sensitive reference needed]. Do not send card, PIN, OTP or full bank details.
Reconcile payment-provider webhooks and store records. Do not send repeated payment requests when the status is unknown.
Template: COD verification
Order: [reference]
Items: [summary]
Amount due on delivery: [currency and amount]
Delivery area: [non-sensitive city/pincode summary]
Reply CONFIRM [reference] by [real cutoff] to continue, or CANCEL [reference] if you no longer need it.
We will never ask for an OTP or advance payment through an unverified number.
Use a clear verification step only where the business process genuinely needs it. Record the reply against the order and suppress duplicate reminders.
Templates: dispatched, out for delivery and delivered
Dispatched
Order: [reference]
Carrier: [name]
Tracking: [official tracking link/reference]
Estimated delivery: [carrier-provided window]
The carrier may update this estimate. For an issue, reply with the order reference.
Out for delivery
Order: [reference]
Carrier status: Out for delivery on [date]
Amount due: [COD amount or “Nothing due”]
Do not share delivery OTPs until the verified delivery step requires it. Contact [official support path] for concerns.
Delivered check
Order: [reference]
Carrier status: Delivered on [date/time if available].
If you did not receive it or the parcel is damaged, reply ISSUE [reference] within [real policy window] and keep the packaging.
A delivered scan does not prove satisfaction. Request a review separately and at an appropriate time through the customer feedback workflow.
Templates: delay, partial shipment and address issue
| Exception | Message structure | Required owner action |
|---|---|---|
| Dispatch delay | State old expectation, current cause if verified, new window and choices | Offer cancellation/refund where policy requires |
| Carrier delay | State carrier status, last scan, next check time | Open escalation when threshold reached |
| Partial shipment | List dispatched and pending items separately | Explain charges and tracking for each part |
| Address problem | Ask only for the minimum correction through a safe route | Verify before changing the order |
| Out of stock | State exact item, alternatives and refund/cancel choice | Do not substitute without approval |
Order: [reference]
What changed: [verified concise fact]
New expectation: [date/window]
Your choices: [wait / approved alternative / cancel-refund path]
Reply [structured choice] or contact [official support]. We are sorry for the inconvenience.
Templates: cancellation and refund
Cancellation confirmed
Order: [reference]
Cancelled on: [date/time]
Payment status: [not charged / refund required / other accurate state]
If this was not requested, contact [official support] promptly.
Refund initiated
Order: [reference]
Refund amount: [currency and amount]
Refund reference: [safe reference]
Initiated on: [date]
Expected posting: [provider/policy window, not a guarantee]
Contact your payment provider after that window, or reply to us with the order reference.
“Refund initiated” and “refund completed” are different states. Keep the message tied to provider evidence and the published return/refund policy.
Protect customers from payment and delivery fraud
Order messages are attractive material for impersonators. Use a consistent verified business identity, stable official links and clear rules about what staff will never request. Never ask for PINs, passwords, full card numbers or account credentials. Tell customers how to report a suspicious message through a trusted site, invoice or verified profile rather than by replying to the suspicious sender.
- Do not shorten payment or tracking links when the destination becomes unclear.
- Do not send bank-detail changes without a separate verified process.
- Do not request a delivery OTP before the legitimate handover step.
- Train staff to recognise account takeover, SIM-swap and fake refund stories.
- Escalate wrong-recipient messages and avoid repeating personal order details.
Automation and template QA
WhatsApp’s current business policy and product documentation govern initiated messages, template use and user experience. Meta has stated that businesses using the Platform initiate messages using approved templates. Check current category and session rules before implementation.
- Map one system event to one message state.
- Use idempotency so webhook retries do not send duplicates.
- Validate all variables and block empty or mismatched fields.
- Route exceptions to a human queue.
- Keep product, price, amount and tracking data read-only from the source system.
- Test wrong number, duplicate order, cancellation and delayed webhook cases.
- Log send, delivery state, reply and suppression outcome.
Use GPTWala’s marketing automation decision framework and CRM fields. Automation should reduce uncertainty, not multiply incorrect status.
Measure service quality
| Metric | Purpose |
|---|---|
| Correct-state rate | Messages that matched source order state |
| Duplicate-send rate | Detect retry/idempotency failures |
| Customer correction rate | Find item, address or amount errors |
| Exception resolution time | Measure handoff to a human |
| Opt-out/block feedback | Detect unexpected or excessive messaging |
| Delivery/return outcome | Connect communication to operating quality |
Frequently asked questions
What should a WhatsApp order confirmation include?
Include business name, order reference, exact state, item summary, amount/payment state, next step, honest timing and a monitored correction or support path.
Can I send order confirmations through WhatsApp Business?
Yes when the customer journey, permission, current WhatsApp policy and product rules support it. Keep factual service content separate from promotions.
How do I write a COD confirmation message?
State the order, items, amount due, delivery area, real confirmation cutoff and structured CONFIRM or CANCEL reply. Do not request OTPs or unsafe payment data.
Should an order placed message say payment confirmed?
Only when the payment system actually confirms payment. Keep placed, payment-pending, paid, dispatched and delivered states distinct.
Can order confirmation messages be automated?
Yes, but map each message to a verified system event, prevent duplicates, validate variables and route exceptions to a human owner.
What should a refund WhatsApp message say?
State whether the refund is initiated or completed, the order, amount, safe reference, date and evidence-based provider window without guaranteeing bank posting time.
Leave a Reply