PrestaShop and OpenCart are both open-source, self-hosted and popular with stores that want control over their own code. Both ship a cash-on-delivery module. Neither asks the customer, before dispatch, whether they still want the order, and for Indian COD stores that step decides how many parcels come back as return-to-origin (RTO).
The two platforms are covered together because the answer is the same for both: they record progress with order states and history, they need a webhook module to tell anything outside about new orders, and they connect to automated confirmation calls through a webhook API.
Running PrestaShop or OpenCart? See COD confirmation calls for PrestaShop or for OpenCart to get set up.
How COD shows up on PrestaShop
The Cash on delivery (COD) module, ps_cashondelivery, is included with PrestaShop. On an order placed
with it:
- The payment module is
ps_cashondelivery, which is how filters and integrations identify COD. - The order starts in a COD-specific state, "Awaiting cash on delivery validation" by default. That state is already a confirmation queue; most stores just never automate it.
- Order history records every state change, and private messages or notes can be added to the order.
Order states are configurable: you can add your own, such as "COD confirmed", and choose whether each one emails the customer. Each state has a numeric id that differs from store to store, which matters for any automation that sets states.
How COD shows up on OpenCart
OpenCart includes a Cash On Delivery payment extension under Extensions, Payments. On an order placed with it:
- The payment code is
cod. - The order gets the status you configured for the COD extension, Pending by default.
- Order history is where progress is recorded: each entry has a status, an optional comment, and a choice of whether to notify the customer.
Order statuses are an editable list in OpenCart's localisation settings, so you can add "COD confirmed" and "Unreachable" if you want them.
The manual workflow on either platform (and where it breaks)
- Filter orders in the COD starting state (Awaiting cash on delivery validation, or Pending).
- Call each customer and read out the order and amount.
- Change the state with a comment: confirmed moves to Processing (or your own "COD confirmed"), refused moves to Cancelled.
- Retry those who didn't answer.
Both platforms make the result easy to record. The calling is what doesn't scale: night orders wait, retries depend on memory, and the list competes with the courier pickup.
The add-on marketplaces for both have the usual categories: OTP at checkout, WhatsApp or SMS confirmation, webhook modules, and call-based services. For any of them, check whether the answer lands in the order state and history, because that's what your packing team looks at.
The webhook gap
Neither platform sends order webhooks out of the box. To trigger anything automatically on a new order you need either:
- a webhook module or extension from the marketplace that POSTs order data to a URL, or
- a small custom hook: an action hook on PrestaShop order validation, or an event on OpenCart order creation, that sends the order to a URL.
How call-based confirmation works on PrestaShop and OpenCart
Both connect to Edesy's COD confirmation calls today through the live custom store API.
1. Your store sends the order
The webhook module or hook POSTs each new order as JSON to your connection's webhook URL: order id, order
reference, customer name, phone with country code, payment method, total and COD amount. Send cod as the
payment method when the module is ps_cashondelivery or cod. The request is signed with an
HMAC-SHA256 header using your signing secret; if your module can't sign, a small bridge script does it.
If an order is cancelled before the call, send a cancellation event for it and the call is skipped.
The exact payload and a signing example are in the webhook API guide.
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. The script is in Hindi or English: press 1 to confirm, press 2 to cancel.
3. The answer comes back to your store
We POST confirm or cancel to your action URL, signed the same way. On your side, a small endpoint
applies it:
| Customer outcome | Suggested update on PrestaShop | Suggested update on OpenCart |
|---|---|---|
| Pressed 1 | Order state changed to your "confirmed" state | Order history entry with your "confirmed" status and a comment |
| Pressed 2 | Order state changed to Cancelled | Order history entry with status Canceled |
| No answer after all attempts | Private note, or your "unreachable" state | History entry with a comment, no customer notification |
| Cancelled before the call | Not called | Not called |
On PrestaShop, the webservice API can add order history entries (with XML bodies) using a webservice key, and state ids must match your store's. On OpenCart, the simplest route is usually a few lines of code in your own extension that add the history entry directly. Make both safe to run twice.
If you'd rather not build the action URL at all, leave it out and work from the outcomes in your dashboard.
Edge cases worth deciding up front
Before your action URL goes live, decide which order state each of these situations should end in:
- 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
PrestaShop and OpenCart: via webhook. Both work today with the live API plus a webhook module or hook on your store, and we help you set it up. There is no dedicated Edesy module for either platform yet.
Rollout tips
- Use the COD starting state as your queue. Nothing in "Awaiting cash on delivery validation" (or Pending) should be packed.
- Add custom states for "COD confirmed" and "Unreachable", and turn off customer emails for them.
- Start with notes only, then let "pressed 2" cancel once you trust it.
- Watch the webhook. Module updates can break sending; the event log shows the last order received.
- Cost it out with the COD RTO calculator.
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 PrestaShop (or OpenCart) and get set up through the webhook route.