# How to Confirm COD Orders Automatically on PrestaShop and OpenCart (2026)

> Confirm PrestaShop and OpenCart cash-on-delivery orders before shipping: the manual order-state workflow, how COD is identified on each, and how keypad confirmation calls connect through a webhook.

Source: https://edesy.in/blog/prestashop-opencart-cod-confirmation-guide-2026

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](https://edesy.in/cod-order-confirmation/prestashop) or [for OpenCart](https://edesy.in/cod-order-confirmation/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)

1. **Filter** orders in the COD starting state (Awaiting cash on delivery validation, or Pending).
2. **Call** each customer and read out the order and amount.
3. **Change the state** with a comment: confirmed moves to Processing (or your own "COD confirmed"),
   refused moves to Cancelled.
4. **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](https://edesy.in/cod-order-confirmation) **today** through the live
[custom store API](https://edesy.in/cod-order-confirmation/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](https://edesy.in/blog/cod-confirmation-webhook-api-guide-2026).

### 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](https://edesy.in/services/cod-order-confirmation-automation) 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

1. **Use the COD starting state as your queue.** Nothing in "Awaiting cash on delivery validation" (or
   Pending) should be packed.
2. **Add custom states** for "COD confirmed" and "Unreachable", and turn off customer emails for them.
3. **Start with notes only,** then let "pressed 2" cancel once you trust it.
4. **Watch the webhook.** Module updates can break sending; the event log shows the last order received.
5. **Cost it out** with the [COD RTO calculator](https://edesy.in/tools/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](https://edesy.in/cod-order-confirmation/prestashop) (or [OpenCart](https://edesy.in/cod-order-confirmation/opencart)) and get set up through the webhook route.

## Related reading

- [COD confirmation webhook and API guide](https://edesy.in/blog/cod-confirmation-webhook-api-guide-2026)
- [Magento and Adobe Commerce COD confirmation guide](https://edesy.in/blog/magento-cod-order-confirmation-guide-2026)
- [When to call a COD customer: timing and retries](https://edesy.in/blog/best-time-to-call-cod-customers-india-2026)

## Frequently Asked Questions

### Do PrestaShop or OpenCart confirm COD orders on their own?

No. Both include a cash-on-delivery payment module and let you change order status with a comment, but neither contacts the customer to confirm. Confirmation is done by your team or an external tool.

### How is a COD order identified on each platform?

By the payment module on the order. On PrestaShop the cash-on-delivery module is ps_cashondelivery; on OpenCart the payment code is cod. Integrations should check these codes rather than the label shown at checkout.

### Can PrestaShop and OpenCart send order webhooks?

Not out of the box. Both need a webhook module or extension, or a small custom hook, to send new orders to an external URL. That is how they connect to COD confirmation calls today.

### Is there a ready Edesy integration for PrestaShop or OpenCart?

Both connect today through our live webhook API plus a webhook module or extension on your store, and we help you set it up. There is no dedicated Edesy module for either platform yet.

### How is the customer's answer saved back?

We POST confirm or cancel to an action URL. Your module or a small script on your store then changes the order state (PrestaShop) or adds an order history entry (OpenCart). Without an action URL, your team acts on the outcomes in the dashboard.

### Which languages are the calls in?

Hindi or English. The call reads out the store name, the order number and the cash-on-delivery amount, and asks the customer to press 1 to confirm or 2 to cancel.