WhatsApp Business Automation
0/15 complete

Module 04 · Sales Automation

Order Confirmation and Payment Reminder Automations

An order confirmation states what the order system accepted. A payment confirmation states what a trusted payment system settled. A screenshot, customer message, or chatbot variable is neither. Safe automation keeps created, pending, paid, failed, cancelled, dispatched, and refunded states separate.

After this lesson, you can map order/payment events, make reminders idempotent, and prevent duplicate or misleading messages.

// concept

Model the State Machines

Order states might be:

// prompt — copy me2 lines
DRAFT → CREATED → CONFIRMED → FULFILMENT → COMPLETED
             ↘ CANCELLED

Payment states might be:

// prompt — copy me4 lines
NOT_REQUIRED | PENDING → PAID
                       ↘ FAILED
                       ↘ EXPIRED
PAID → REFUND_PENDING → REFUNDED

Do not collapse them. A confirmed COD order can remain unpaid. A paid order can be cancelled and need a refund. Every transition needs event ID, source, timestamp, amount, currency, and order reference.

// concept

Verify Server to Server

Use the payment provider’s signed callback and server-side inquiry as specified by that provider. Validate signatures, amount, currency, order reference, and status. Store the provider event ID under a uniqueness constraint so retries do not issue duplicate receipts or entitlements.

Before sending a reminder, fetch current state:

// prompt — copy me3 lines
if order_closed or payment_paid or reminder_already_sent_for_version: skip
if reminder_not_permitted_by_window_template_consent: skip
else create send record atomically, then dispatch

Never put secret keys, full payment credentials, PINs, OTPs, or card details in a chat message or client-side script.

// concept

Write the Messages

Confirmation:

// prompt — copy me6 lines
Order PK-1048 was created.
Items: 2 × SKU A14
Total: PKR 6,250 including listed delivery
Payment: Cash on delivery
Delivery estimate: 2–4 business days, subject to carrier update
Reply EDIT or CANCEL before dispatch, or HUMAN for help.

Payment reminder:

// prompt — copy me4 lines
Payment for order PK-1049 remains pending in our system.
Amount: PKR 6,250. Use only the official payment link tied to this order.
If you already paid, do not pay again; reply REVIEW with the transaction reference.
Never share your PIN, OTP, or banking password.

// worked_example

Worked Example

A Lahore course provider creates enrollment EN-8821 for PKR 2,490. The hosted checkout returns the learner to a result page, but the system does not grant access from URL parameters. It verifies the transaction server-side and processes event TX-771 once. Only then does payment move to PAID and enrollment to ACTIVE.

The gateway retries the callback three times. The unique event constraint turns the second and third into no-ops. A scheduled reminder re-reads payment state and cancels because PAID is already recorded. The learner receives one receipt and one access message.

// failure_cases

Failure Cases to Diagnose

7 cases to diagnose

  • Success redirect grants access

    verify server-side first.

  • Callback retry creates duplicate orders

    enforce unique provider event IDs and idempotent transitions.

  • Amount/currency not checked

    reject mismatched events for review.

  • Reminder uses yesterday’s state

    re-read immediately before send.

  • Payment screenshot accepted

    use transaction reference and provider inquiry.

  • Refund described as completed when pending

    expose the real state.

  • Official link domain unclear

    publish expected domain and report suspicious links.

// pakistan_angle

Pakistan Angle

Pakistani businesses may use COD, bank transfer, wallets, cards, or hosted gateway links. Document a verification method for each. Manual bank transfer needs an authorized reconciliation queue; it still should not rely on an edited screenshot. State expected processing time and never ask for an OTP or banking password.

For COD, confirm item, amount, delivery address summary, and cancellation path before dispatch. A confirmation call or message is an operational control, not permission for future promotions. Keep tax invoices and refund rules aligned with the business’s actual legal and accounting obligations.

// hands_on

Hands-On Exercise

5 steps

  1. Draw separate order and payment state machines.

  2. Define trusted transition sources and required event fields.

  3. Write idempotency and pre-send reminder rules.

  4. Draft confirmation, pending, failed, and refund-pending messages.

  5. Test duplicate callback, mismatched amount, stale reminder, and forged success URL.

// completion_rubric

Completion Rubric

6 checks — tick as you verify

0/6

// sources

Sources

// check_yourself

Check yourself

4 questions · answers and options are taken word-for-word from this course

0/4
  1. 1 / 4 · diagnose

    Your work shows this failure mode: “Success redirect grants access.” What does the lesson tell you to do about it?