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.
Model the State Machines
Order states might be:
DRAFT → CREATED → CONFIRMED → FULFILMENT → COMPLETED
↘ CANCELLED
Payment states might be:
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.
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 dispatch
Never put secret keys, full payment credentials, PINs, OTPs, or card details in a chat message or client-side script.
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
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 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
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 Exercise
- 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.
Done means: no customer can receive duplicate entitlement or a false paid/refunded claim from a retry, redirect, screenshot, or stale timer.
Completion Rubric
- Order and payment states are separate.
- Payment is verified by trusted server-side evidence.
- Event processing is idempotent.
- Amount, currency, reference, and status are validated.
- Reminders re-check current state and permission.
- Messages exclude secrets and explain safe review.
Sources
- WhatsApp Business — Messaging policy
- OWASP — Third Party Payment Gateway Integration
- State Bank of Pakistan — Consumer protection
Key takeaway: automate from verified, idempotent order and payment events; never let a chat message, redirect, or screenshot manufacture financial truth.