Module 04 · Sales Automation
Order Confirmation and Payment Reminder Automations
Open lesson + course map
On this lesson
Course outline
Module 1 · WhatsApp Business Foundations
Module 2 · Chatbot Design
Module 3 · Lead Handling
Module 4 · Sales Automation
Module 5 · Scaling Your WhatsApp Channel
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:
DRAFT → CREATED → CONFIRMED → FULFILMENT → COMPLETED
↘ CANCELLEDPayment states might be:
NOT_REQUIRED | PENDING → PAID
↘ FAILED
↘ EXPIRED
PAID → REFUND_PENDING → REFUNDEDDo 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:
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 dispatchNever put secret keys, full payment credentials, PINs, OTPs, or card details in a chat message or client-side script.
// concept
Write the Messages
Confirmation:
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:
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
Draw separate order and payment state machines.
Define trusted transition sources and required event fields.
Write idempotency and pre-send reminder rules.
Draft confirmation, pending, failed, and refund-pending messages.
Test duplicate callback, mismatched amount, stale reminder, and forged success URL.
// completion_rubric
Completion Rubric
6 checks — tick as you verify
// sources
Sources
3 official sources — check every claim yourself
// check_yourself
Check yourself
4 questions · answers and options are taken word-for-word from this course
1 / 4 · diagnose
Your work shows this failure mode: “Success redirect grants access.” What does the lesson tell you to do about it?