A catalogue and product pages.
The page has to answer stock, a VAT-inclusive price and a delivery date before it tries to persuade anyone
a product page a buyer can act on without asking a question
eCommerce website development · UAE
A UAE store is bought at the storefront and decided at the payment step. Webzenia builds the checkout, the delivery promise and the tax invoice that has to come out of every order.
Get a scoped store planWhat an eCommerce build settles
Three things decide whether a UAE store earns anything, and all three sit behind the storefront: what it accepts, what it promises about delivery, and what it issues afterwards.
Cards, instalments and cash at the door are three different settlement paths behind one button. Each one is an account, a fee and a refund route, and adding a fourth later is quick only where the checkout was built to take one.
The delivery date and cost shown before the payment step, read from a courier account rather than written by a copywriter. A promise made per emirate is one you can keep, and a single national one is the one a buyer will hold you to.
A tax invoice, in sequence, carrying your TRN and the 5% VAT as its own line. The store issues it, not a spreadsheet afterwards, because the numbering has to be continuous and nobody can reconstruct that in month nine.
Where the order is completed
Most UAE brands selling online already take orders. The build decides which of these three the money runs through, and what each one leaves behind.
| A payment linkSent after a message or a call | Cash on deliveryAgreed online, collected at the door | Your own checkoutThe order completes in one place | |
|---|---|---|---|
| What the buyer does | Leaves the chat, pays on a hosted page, comes back to say it is done. | Confirms an address and waits to pay a driver. | Chooses, pays and gets a confirmation without leaving the store. |
| What you hold afterwards | A payment reference, and whatever the conversation happens to say. | A name on a courier manifest, and a cash remittance later. | An order record joined to a customer, a product and a price. |
| The tax invoice | Raised by hand afterwards, and easy to raise out of sequence. | Raised at the door or later, usually by the accountant. | Issued with the order, numbered in sequence, carrying your TRN. |
| When the money lands | The moment the link is paid, which is why it feels like the simple option. | On the courier remittance, less the parcels that came back. | On settlement from the acquirer, on a cycle you can forecast against. |
| Where it stops scaling | At the number of conversations one person can hold in a day. | At the refusal rate, which you pay for twice. | At whatever is still done by hand, and that is now visible. |
Build the checkout, and keep the payment link for what it is genuinely good at: a made-to-order piece, a deposit, a repeat buyer who messages you anyway. Cash on delivery stays on the page while your category still expects it, priced as a receivable rather than as a payment method. Two nearby questions are answered elsewhere on purpose: whether a marketplace listing should keep a query is decided on search, and what your licence permits you to sell online is settled before either.
The UAE context
Webzenia has worked with Gulf clients since 2018. These four shape the checkout, the invoice and the delivery promise, and none of them is visible in a theme.
Tabby and Tamara are the two a UAE shopper looks for, with Cashew, Postpay and Comfi behind them. Each carries its own fee, onboarding and refund path, so for an Al Quoz F&B producer on a DET mainland licence it is a margin decision taken at the build, not a campaign added later.
A refused parcel is a delivery paid for, stock in transit, and an order that was never revenue. A Deira trading house on a DET mainland licence that books it as a sale until the money arrives is reporting a forecast, so the order states have to separate orders placed from money collected.
A UAE tax invoice carries the supplier TRN, a sequential number with no gaps and the 5% VAT on its own line, and it is due within 14 days of supply. A simplified invoice is only permitted at AED 10,000 or less, or to an unregistered buyer, and that test belongs in the checkout.
Same-day inside Dubai, next day to Sharjah, and a different cost and window again for Al Ain or Fujairah, priced differently by Aramex, by Quiqup and by whatever account a Sharjah SAIF Zone manufacturer holds. One national promise on the product page is the one a buyer will hold you to.
The scope
Six parts of the build, each carrying a decision the storefront cannot make on its own.
The page has to answer stock, a VAT-inclusive price and a delivery date before it tries to persuade anyone
a product page a buyer can act on without asking a question
Every method the store offers is wired to the account that settles it, with its own refund route and its own line in the reporting
a checkout where adding a method is a decision rather than a plugin
The order writes an invoice with a TRN, a sequence and a VAT line, then hands the same record to accounting and to the courier
one order, one number, three systems agreeing
Category, product and checkout are measured on the connection a buyer is actually on, because a slow step here costs an order rather than a visit
a budget held on the buying path
The same record drives the page, the invoice line, the delivery label and the markup a crawler reads
a price changed once and correct in four places
Tracking is wired before launch so the first month produces a number rather than an argument, with the checkout step reported on its own
a store you can improve on evidence
Our stack
The commerce stack behind a store that takes money cleanly. Select one to see what it settles here, and what it costs you later.
Shopify owns the checkout, which means it also owns the card-data scope that comes with it. That is the one part of a store most owners would rather not be responsible for rebuilding.
We build the theme rather than buy one, and we wire the payment set against the merchant account your bank actually issued, so the checkout matches your rails instead of the platform default.
How the build runs
The sequence is deliberate. Deciding the payment set and the invoice after the storefront is built is what turns a six-week build into a twelve-week one.
We settle what the store has to take and what it has to issue before the catalogue is touched: the activity the licence covers, the merchant and instalment accounts you can realistically onboard, the invoice format your accountant files against, and the delivery windows your courier will commit to per emirate. Those four fix the scope. The design follows them rather than the other way round.
The catalogue, the product pages and the checkout get built, then the gateway, the instalment provider, the courier and the accounting system get wired and tested against each other rather than in isolation. Before launch we place a paid order, a cash-on-delivery order and a return, and read what each one wrote into the invoice sequence and the reporting.
After launch the checkout step is reported separately from the rest of the store, so the conversation is about a measured drop rather than about the design. New payment methods, categories and delivery options are added against that number. The move to structured e-invoicing in 2027 is scheduled into the roadmap rather than discovered in the quarter it lands.
Reported against orders, checkout completion and returns, in the same dashboard your own team opens.
Our commitment
A store is judged on money it either took or did not. These four are the terms, and each one is checkable after launch.
A real order, paid and refunded.
We place a live order through every payment method the store offers, refund it, and show you the invoice, the settlement line and the accounting entry each one produced. A checkout is signed off on a transaction, never on a screenshot.
The invoice format is verified.
The TRN, the sequence, the VAT line and the simplified-invoice threshold are specified in writing and checked on a live order before handover. Where your accountant wants it changed, it changes in the build, not in a monthly workaround.
Cash on delivery reported honestly.
Orders placed, delivered, refused and returned are separated in the reporting from the first day. A growth number on this store will never turn out to be a count of parcels that came back.
We say when not to build.
Where the margin is thin and the orders are already arriving through a channel that works, we will say so and scope the smaller job instead. A store that adds a running cost and no orders is not a result we want on the record.
Common questions
Keep exploring
A design system drawn for both reading directions, not screens.
Builds sequenced around the approvals the launch date waits on.
Flows and states tested with real people before anything is built.
The plan decides more than the theme. We settle that first.
A store you own outright, with the running cost priced first.
Built for the two people who have to publish it, in both scripts.
For content that has to reach more than one surface.
The origin, the scripts and the consent layer, not the network.
Diagnosis first, and a test only where the traffic carries one.
Next step
Send us the store and the payment methods it offers today. We will tell you which orders it loses at the last step, and what it would take to keep them.
Tell us what you need.