BigCommerce handles cash on delivery as an offline payment method: easy to switch on, and then the order sits in your list like any other. There is no built-in step that asks the customer to confirm, so stores selling in India, where COD refusals turn into return-to-origin (RTO) charges, end up confirming by hand.
This guide covers the confirmation workflow you can run with BigCommerce itself, how COD is identified, and how an automated press-1-to-confirm call records its answer in a platform that uses statuses rather than tags.
Running BigCommerce with COD? See COD confirmation calls for BigCommerce for the integration plan and the pilot list.
How COD shows up on a BigCommerce order
You enable it under Settings, Payments, offline payment methods, Cash on Delivery. Orders placed with it:
- Carry the payment method name on the order, which is how filters and integrations recognise COD.
- Arrive in an unpaid status, such as Awaiting Payment or Pending, depending on your setup.
- Have staff notes, visible to your team and not to the customer.
- Have no tags. Workflow state lives in the order status.
BigCommerce has a fixed set of order statuses (Pending, Awaiting Payment, Awaiting Fulfillment, Awaiting Shipment, Shipped, Cancelled and others), and you can rename their labels to fit your process. In the API, each status is a numeric id. For example, Awaiting Fulfillment is 11 and Cancelled is 5.
The manual workflow (and where it breaks)
- Filter orders to the unpaid status your COD orders land in.
- Call each customer and read out the order number and amount.
- Write a staff note with the answer and the time.
- Move the status to Awaiting Fulfillment if confirmed, or Cancelled if refused.
- Retry the ones who didn't pick up, later in the day.
Renaming a status label (for example calling Awaiting Fulfillment "COD Confirmed: Ready to Pack") makes the order list read like your process, without any app.
It falls apart on volume and timing: orders that arrive at night, retries nobody tracks, and a calling list that isn't finished when the courier arrives.
App-based options fall into familiar groups: WhatsApp or SMS confirmation flows, OTP checks at checkout, and call-based confirmation. On BigCommerce, check whether the tool changes the status, writes a staff note, or only shows the answer in its own dashboard, because only the first two are visible to your fulfilment team.
How call-based confirmation works on BigCommerce
This is how Edesy's COD confirmation calls are designed to work with BigCommerce once the integration is built.
1. New orders arrive by webhook
BigCommerce sends a store/order/created webhook for each new order. Its payload is thin: it carries the
order id and little else, so the full order (customer, phone, amount, shipping address) is fetched from the
API before anything is scheduled.
BigCommerce doesn't sign webhooks. Instead, when the webhook is registered, a secret header is added to it, and every delivery is checked for that header.
BigCommerce retries deliveries that fail and eventually deactivates a webhook that keeps failing. So the receiving side acknowledges each event straight away and does the work afterwards, and the dashboard shows when the last event arrived, so a deactivated webhook is noticed quickly instead of silently stopping the calls.
Cancellation arrives as a store/order/statusUpdated event whose new status is Cancelled, which is how an
order cancelled before the call is detected and skipped.
2. Rules and the call
Only unconfirmed COD orders are called by default. Default calling rules, all adjustable: first call 2 minutes after the order, between 9 am and 9 pm IST, up to three attempts (30 minutes, then 2 hours apart), give up after 48 hours. Just before dialling, the order is checked again.
The script reads out your store name, order number and COD amount in Hindi or English: press 1 to confirm, press 2 to cancel.
3. The answer is written back as a status and a staff note
| Customer outcome | What changes in BigCommerce |
|---|---|
| Pressed 1 | Status set to your "confirmed" status (for example Awaiting Fulfillment), plus a staff note |
| Pressed 2 | Status set to Cancelled, plus a staff note |
| No answer after all attempts | Staff note with your unreachable label, for your team to follow up |
| Cancelled before the call | Not called |
Because status ids are used differently from store to store, the "confirmed" status is set per connection. Payment status isn't involved; the order is still paid on delivery.
Edge cases worth deciding up front
A few situations come up in the first week on any BigCommerce store. Decide them, and which status each one should land in, before you switch anything on:
- Two orders from the same customer. Each order gets its own call, because confirmation is per order. If customers often split one purchase into several orders, tell your team to look for duplicates in the unreachable list.
- The customer wants to change the address. A keypad call records yes or no; it can't take a new address. Ask such customers to press 1 only if the address is right, and keep a short manual round for the ones who call back. If address changes are common, a conversational AI voice agent for COD verification is the better fit.
- The number is wrong or switched off. After the last attempt the order is marked unreachable. Decide whether your team calls once more, holds the order, or cancels it after a set time.
- The customer answers but presses nothing. This is recorded separately from unreachable, as "no input", so you can treat it differently, for example with one more manual call.
- Partly prepaid orders. If a customer paid part of the amount online, the call should read out only the cash amount due on delivery, not the order total. Check this during setup with a real order.
Integration status, stated plainly
BigCommerce is planned and not built yet. Nothing is self-serve for BigCommerce today. Join the pilot list on the BigCommerce page and we'll set it up with you when it's ready. The more stores ask, the sooner it moves up the list.
If you have a developer and want to start now, the custom store API is live. A small service listens to BigCommerce's order webhook, sends us a signed order event, and updates the order status when our result arrives on its action URL. The webhook API guide has the payloads.
Rollout tips for BigCommerce stores
- Pick your statuses first. Decide which status means "waiting for confirmation" and which means "confirmed", and rename their labels so the order list is self-explanatory.
- Start with staff notes only, then add status changes once your team trusts the answers.
- Keep a manual round for unreachable orders before pickup.
- Estimate the value with the COD RTO calculator and your courier rates.
Pricing
Calls are paid as you go from a prepaid wallet. Share your monthly COD volume with us for pricing.
Next step: See COD confirmation for BigCommerce and join the pilot list.