Key Takeaways
- Cash-on-delivery confirmations are a trust text. Abandoned-cart recovery is marketing. They do not share a webhook consumer or a SIM.
- Do not fire “rider assigned” until the warehouse actually staged the parcel — label-print webhooks lie.
- Free is 1 device, 300 SMS lifetime, and 300 contacts. Platform price is devices plus send volume; COD retries still spend carrier credit.
- OTP for account login stays off the COD reminder queue.
- Idempotency is the order-line plus attempt number, not the store order id alone — partial shipments replay.
Summary
Scenario 61 is the cash-on-delivery and warehouse-exception cut of ecommerce webhooks — not the checkout-OTP and tracking-HMAC story. The store emits paid, unpaid, packed, and returned events. Only some of those should wake a SIM. Service pricing is devices plus SMS send volume. You bring the phone and operator credit. Free is 1 device, 300 SMS lifetime, and 300 contacts.
Professional allows 5 devices: COD ops, login OTP, promo recovery, spare, and a second site. That still is not unlimited carrier SMS. Confirm event names in Developer Center.
COD confirm · packed · exception
label printed ≠ rider assigned
COD confirm is not an abandoned-cart blast
A buyer who chose cash on delivery already has an order. The first SMS should restate amount, window, and a cancel path — not a coupon. Abandoned checkout is a different consumer with STOP, quiet hours, and a promo device. Mixing them is how COD customers get “complete your purchase” after they already did.
Related: transactional SMS, consent-minded bulk, webhooks.
If the warehouse marks packed, then unpacks, then packs again, a naive webhook will send three “rider on the way” texts. Key the send on fulfillment attempt, not the parent order id.
COD and warehouse webhook matrix
| Event | SMS? | Failure if you fire anyway |
|---|---|---|
| Checkout started, unpaid | Only if promo consent | COD customer thinks the order failed |
| COD order created | Yes — confirm amount and window | Unsigned webhook; scammer-triggered confirms |
| Label printed | No | Customer waits at the door for a parcel still on the shelf |
| First mile scan / packed-staged | Yes — rider assigned | Retry without attempt id; triple text |
| Return / refuse | Yes — ops template, two-way inbox | Auto-reply offers a coupon on a dispute |
Hold the radio until cash intent is real
Verify signatures. Drop events without a COD flag when the consumer is the COD worker. Cap confirm SMS to one per order-line per calendar day unless the buyer asked for a reschedule. Login OTP never uses this worker. Live JSON is not this article — copy fields from Developer Center.
Warehouse exceptions after pickup
Damaged box, wrong SKU, rider cancellation: these need an owned inbox, not a blast. Persist exception ids. DLR tells you the radio finished. A human tells you the cash was collected.
Devices, volume, and airtime
COD days spike volume and retries. We meter devices and platform sends. The SIM’s operator meters the rest. Free (1/300/300) is a single-city dry run. Cart-recovery campaigns are a separate volume budget with STOP.
Cash-on-delivery operations
Daily: pairing, charge, COD vs promo isolation, airtime, staff canary on a real COD template (not login OTP). After OEM updates, re-walk packed-staged → SMS. Setup, Downloads, pricing.
Decision guide
Ship when COD and cart-recovery are separate consumers, fulfillment-attempt keys exist, and OTP is isolated. Delay if label-print is your “shipped” signal. If you will not run phones, use an aggregator for that city and pay per message plus rented numbers.
COD checklist
- COD consumer ignores unpaid checkout events.
- Cart recovery has STOP and a different device.
- Packed-staged, not label-print, triggers rider SMS.
- Idempotency = order-line + attempt.
- Signatures verified; OTP pool isolated.
- Exception inbox owned.
- Developer Center fields confirmed.
Next steps
Android SMS gateway, scenario 1 checkout webhooks, Google Ads SMS/MMS policy for the recovery lane.
Related product pages
Jump to the live product docs for this topic—not another long-form article.
- SMS webhook integrationInbound and status events
- transactional SMS for orders and alertsEvent-driven messages
- SMS API documentationLive endpoint reference
- device and SMS volume pricingPlans and allowances
