Magento gives you more control over orders than most platforms: states and statuses, hold and unhold, order comments, and a full REST API. What it doesn't give you is a step that asks a cash-on-delivery customer, before dispatch, whether they really want the parcel.
This guide covers both editions: Magento Open Source and Adobe Commerce. It walks through the manual confirmation workflow, how COD is identified, the webhook gap in Open Source, and how an automated press-1-to-confirm call writes its answer back.
Running Magento with COD? See COD confirmation calls for Magento, or for Adobe Commerce, for setup and status.
How COD shows up on a Magento order
Cash On Delivery is a built-in offline payment method. You enable it under Stores, Configuration, Sales, Payment Methods, where you can also restrict it by country and order total and choose the status new COD orders get.
On the order:
- The payment method code is
cashondelivery. Filters, extensions and integrations should check this code, not the title shown at checkout. - New orders start in the "new" state with the status you configured, usually Pending.
- Comments are the audit trail. Each order has a comments history, and each comment can carry a status change.
- Hold is the natural pause. Putting an order on hold keeps it out of fulfilment until someone releases it, which is useful while waiting for a confirmation.
The manual workflow (and where it breaks)
A typical process on Magento:
- Filter the Sales, Orders grid to Pending orders with Cash On Delivery.
- Call the customer and read out the order and amount.
- Comment on the order with the result, and change status if you use a custom "Confirmed" status.
- Hold or cancel the ones who refused or couldn't be reached.
- Retry later, and release holds for confirmed orders.
Magento's custom order statuses help here: you can add a status such as "COD Confirmed" and assign it to the processing state. But the phone calls themselves don't scale. Night orders wait, retries rely on memory, and the calling list competes with the courier pickup cut-off.
The extension marketplace has the usual categories: OTP verification at checkout, WhatsApp or SMS confirmation links, order-status and webhook extensions, and call-based services. The question to ask each is the same: where does the answer end up on the order? On Magento, a comment plus a status (or hold) is the clearest place.
The webhook gap in Magento Open Source
Any automated confirmation needs to hear about new orders as they happen. This is where the two editions differ:
- Magento Open Source has no built-in outbound order webhooks. You need a webhook extension (several exist, free and paid) or a small custom observer module that POSTs new orders to a URL.
- Adobe Commerce can publish order events through Adobe I/O Events, signed by Adobe. The event fires on every order save, so the receiving side has to work out which saves are new orders and which are cancellations.
How call-based confirmation works on Magento Open Source
Magento Open Source connects to Edesy's COD confirmation calls today, through the live custom store API and a webhook on your store.
1. Your store sends the order
A webhook extension or small module POSTs each new COD order as JSON to your connection's webhook URL: order id, order number, customer name, phone with country code, payment method, total and COD amount, all signed with an HMAC-SHA256 header using your signing secret. If your extension can't compute that signature, a small bridge (a few lines of PHP, or an automation tool) sits in between. When an order is cancelled before the call, send a cancellation event for the same order and the call is skipped.
The webhook API guide has the exact payload and a signing example.
2. Rules and the call
By default only unconfirmed COD orders are called: send cod as the payment method for
cashondelivery orders. 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 (and, if you set them up, tag or note actions for unreachable orders) to
your action URL, signed the same way. On the Magento side, that endpoint does the store update with
Magento's own REST API:
| Customer outcome | Suggested update in Magento |
|---|---|
| Pressed 1 | Order comment "COD confirmed on call", optional status change, release hold |
| Pressed 2 | Order cancelled, with a comment |
| No answer after all attempts | Comment with your unreachable label, order stays on hold for your team |
| Cancelled before the call | Not called |
Adding a comment and cancelling are both standard Magento order API operations, so the bridge stays small. Make it safe to run twice: a cancel on an already-cancelled order should simply succeed. If you'd rather not build an action URL, leave it out and act on the outcomes in your dashboard.
Edge cases worth deciding up front
Before the bridge goes live, decide which status, comment or hold 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.
Adobe Commerce: what is planned
A dedicated Adobe Commerce integration is planned and not built yet. The design uses Adobe I/O Events for new orders (with Adobe's signature verification), and writes back with an order comment, hold or unhold, and Magento's order cancel, authenticated with an integration token used as a bearer token (which has to be enabled in the store's configuration from 2.4.4 onwards).
Until then, Adobe Commerce stores can connect the same way as Open Source, through a webhook and the live API. Join the pilot list and we'll set up the direct integration with you when it is ready.
Integration status, stated plainly
- Magento Open Source: via webhook. Works today with the live API plus a webhook extension or module on your store. We help you set it up; there is no Edesy Magento extension yet.
- Adobe Commerce: planned. Not built yet. Connect through the webhook route now, or join the pilot list.
Rollout tips
- Put COD orders on hold by default (or give them a "Pending confirmation" status), so nothing ships unconfirmed.
- Start with comments only, then let "pressed 2" cancel once you trust it.
- Keep one manual round for unreachable orders before the courier cut-off.
- Watch webhook health. Extensions can stop sending after an error or upgrade; the event log shows when the last order arrived.
- 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 Magento and get set up through the webhook route.