AI agents for UAE ecommerce
An AI agent for ecommerce in the UAE confirms a cash on delivery order before the parcel is picked, answers "where is my order" on WhatsApp once it is moving, holds a refund until the courier has actually handed over the cash, and matches the remittance file back to the orders it came from. Cash on delivery is the constraint the whole design bends around, and this page is about what it changes.
Why cash on delivery changes the design
The US International Trade Administration's country commercial guide for the UAE names "the prevalence of cash on delivery over other electronic payment methods" as a barrier to ecommerce growth in the country. (Verified July 2026, trade.gov.) We are deliberately not attaching a percentage to that. The figures in circulation come mostly from vendor blogs and they measure three different things: share of orders, share of transaction value, and share of merchants who offer it. Quoting one as if it were the others is how a number ends up wrong.
What matters is the mechanical consequence. A COD order can be placed, picked, shipped and delivered while your payment records still show nothing received. The cash arrives later, from the courier, in a batch, net of fees, and it does not line up one to one with orders. So reconciliation is a matching problem across two systems that were never designed to agree, which is precisely the work that a deterministic rule handles badly and a reviewed agent handles well.
Both halves of that gap are visible in the tooling, which is the useful part. Shopify treats cash on delivery as a manual payment method, listing "cash on delivery (COD), money orders, and bank transfers" as common types, and an order taking one is marked unpaid until somebody marks it paid. (Verified July 2026, help.shopify.com.) On the carrier side, the Aramex Shipping API v2 schema carries a CashOnDeliveryAmount on the shipment itself, a Money value sitting alongside CustomsValueAmount, InsuranceAmount and CollectAmount. (Verified July 2026, ws.aramex.net.) Your order knows it has not been paid. The parcel knows how much to collect. Neither system closes the loop between them, and closing it by hand is the job people are currently doing in a spreadsheet.
It also changes returns. A refund on a card order reverses a payment you already hold. A refund on a COD order may be a payment you have not yet received, and the sequence matters.
And it changes what a failed delivery costs you. A prepaid parcel refused at the door has already been paid for, so the loss is the return leg. A COD parcel refused at the door was never paid for at all, so you have funded the outbound leg, the return leg and the handling on a sale that never happened. That arithmetic is why confirming the order before dispatch earns its place in a UAE build, and why it is the first scenario below.
Illustrative scenarios
These are illustrative, not client accounts. Telora Labs was founded in 2025 and does not publish client names. Each is written as what an agent would do for an operator running this workflow.
"Too many cash on delivery parcels come back because nobody was reachable at the address."
A store running cash on delivery would have the agent contact the customer before the parcel is picked, confirm the delivery address, the contact number and the exact amount the driver will ask for, and hold the order in an unconfirmed queue until it is answered or a cut-off passes. What that confirmation costs to send is the number that decides the design. The WhatsApp Business Platform runs a 24 hour customer service window: while it is open you can send free-form service messages, and once it closes you can only send pre-approved template messages. (Verified July 2026, developers.facebook.com.) A confirmation goes out after the order was placed, usually with no window open, so it is a template, and since 1 July 2025 Meta charges per delivered template message by category. Service messages sent inside an open window are free until 1 October 2026, when Meta begins charging for them on a per-message basis at the utility and authentication rates by market. (Verified July 2026, developers.facebook.com.) So every confirmation carries a price, and the number it has to beat is the cost of a refused parcel. Once the parcel is moving, "where is my order" is answered inside the window the customer just opened, which is the cheap half of the same integration. If someone has costed your store on free service replies, that assumption has an expiry date.
The warehouse picks from the confirmed queue. Everything unconfirmed sits in one list with an age against it.
"We refunded a customer on an order the courier had not remitted to us yet."
Shopify's Admin GraphQL API exposes a Return object and a returnStatus on the order, carrying return reasons and refund details, plus an orderMarkAsPaid mutation that "Marks an order as paid by recording a payment transaction for the outstanding amount", usable only while the order still has a positive outstanding balance and is not already PAID. WooCommerce's REST API v3 exposes refunds at /wc/v3/orders/{order_id}/refunds. (Verified July 2026, shopify.dev and woocommerce.github.io.) On a prepaid order those interfaces are the whole job. On a COD order they are not, because the parcel can be delivered, returned and refunded while the order's financial status still reads unpaid, and there is no card authorisation to reverse: the money leaves as a bank transfer or store credit that finance has to originate.
So the agent checks the return window and item eligibility, creates the return, books the collection, and then asks a question no prepaid workflow ever asks: has the courier actually remitted the cash for this order? Where it has, the refund is prepared against the payout details the customer gave and issued up to a value you set. Where it has not, the return is created and the refund is held with that reason written on it, because paying out against money you have not received is how a COD store quietly funds its own losses.
A customer gets an answer the same day, and finance never pays out twice on one parcel.
"We sold the last one twice, on two different channels."
Amazon's Selling Partner API covers the UAE store, served by the Europe endpoint at sellingpartnerapi-eu.amazon.com. (Verified July 2026, Amazon Selling Partner API documentation.) An operator selling on their own storefront and on a marketplace would have the agent hold a buffer per channel, reconcile counts on a schedule, and escalate when storefront, warehouse and marketplace disagree by more than a threshold. When cover drops below the reorder point it drafts the supplier purchase order with quantities and lead times filled in, and holds it for a human to send.
Cash on delivery adds a fourth number to that reconciliation. A refused COD parcel is in transit back to you: sold in the storefront, absent from the warehouse shelf, and unavailable to promise to anyone until it lands. The agent keeps those in a returning bucket with an expected date, so the same unit is never counted as stock and as a sale in the same week.
Overselling surfaces as an alert naming both channels and the unit count, before a customer finds it for you.
"Finance matches courier remittances to orders in a spreadsheet, weeks after the fact."
The agent takes the courier's remittance file, whether that arrives as a portal export from a larger carrier or a spreadsheet emailed by a regional one, matches each line to an order, and produces three lists: matched, short, and delivered but never remitted, with the age of each. It does not adjust your books. It hands finance a reconciliation they can act on, and it flags a courier whose shortfalls keep coming from the same route.
Unremitted COD stops being something you find at quarter end.
Which systems the agent touches
Your storefront
Shopify through the Admin GraphQL API, or WooCommerce through REST v3 with consumer key and secret over HTTPS.
Marketplaces
Amazon's Selling Partner API for the UAE store. Orders, listings and inventory, on the Europe regional endpoint.
Messaging
The WhatsApp Business Platform. The 24 hour service window, template approval and the per-message price go into the estimate at scoping.
Payments and couriers
Stripe for the prepaid side, which supports UAE accounts (verified July 2026, stripe.com), and on the COD side the amount the driver collects plus the remittance file finance reconciles against. Aramex, for one, carries that amount as a CashOnDeliveryAmount field on the shipment (verified July 2026, ws.aramex.net).
Under the hood: we build on Ruby on Rails and handle authentication, rate limits, retry policy and monitoring for every one of these. An integration that fails silently is worse than one that never shipped, so each alert names the system, the operation, and the record count that failed.
What breaks, and what the agent does about it
The service window closes mid-conversation
A customer asks at 9pm, the answer needs a supplier check, and by the time it lands the window has shut. The agent has to know it can no longer speak freely and switch to an approved template, or queue the message and tell a human. Both are choices you make at build time.
The customer confirms, then refuses at the door anyway
Confirmation lowers the refusal rate. It does not remove it, and a build that assumes otherwise will overstate its own payback. The agent's job is to record the refusal against the customer, so a second COD order from the same number can be held for a person to look at before it ships.
Two channels sell the same unit
Buffers reduce this, they do not remove it. When it happens the agent needs a defined loser: which channel gets cancelled, who is told, and in what order. Deciding that during the incident is how the wrong customer gets cancelled.
A refund exists on one side only
A refund recorded in Shopify with no matching payout, or a payout with no refund behind it, is a reconciliation break, not an error message. Nothing throws. It surfaces only because something compares the two on a schedule, and on COD orders the comparison has a third column: whether the cash ever arrived in the first place.
The remittance is short
Shortfalls are normal in small numbers and a signal in large ones. The agent reports the pattern per courier and per route, because one missing dirham is noise and forty from the same route is a conversation.
What an AI agent costs for a UAE store
An AI agent build is AED 10,000 to 50,000, fixed price, agreed before work starts.
Single-workflow agent: AED 10,000 to 20,000, 2 to 3 weeks
One trigger, one or two systems, a human escalation path. COD order confirmation on WhatsApp, and order status answered from the storefront, sit here.
Multi-system agent: AED 20,000 to 35,000, 3 to 5 weeks
Three or more systems, branching logic, error handling. Returns and refunds sequenced across storefront and courier, or stock reconciled across storefront, warehouse and marketplace, sits here.
Complex agent: AED 35,000 to 50,000, 5 to 8 weeks
Custom logic, compliance constraints, a self-hosted model, or a heavy integration surface. Full COD reconciliation touching finance records belongs in this band.
Ongoing changes and monitoring run on a monthly retainer. How we work covers scoping, fixed pricing and delivery.
Tell us what a refused COD parcel costs you
Send the outbound rate, the return rate, and roughly how many come back in a month. We will do that arithmetic with you before quoting anything, and tell you which parts of the workflow we would leave alone.
hello@telora.dev