An online store is the one build where the decisions made in week one are the hardest to reverse in year two. Not the design — the plumbing. Payment, delivery, tax and language are all cheap to choose and expensive to change once you have orders in the system.
These are the ones that actually bite in this market.
1. The payment gateway, and who is on the merchant account
This is the decision with the longest tail. A UAE store typically needs a merchant account tied to a UAE bank and a gateway on top of it, and the approval process is slower than most timelines assume — it involves your trade licence, your bank, and sometimes a wait that nobody has budgeted for.
What to settle before you build:
- Whose account is it? If the agency's account processes your payments, the payouts and the dispute history belong to them. It should be yours.
- Does it support AED and the currencies you actually sell in? Multi-currency display is a front-end job; multi-currency settlement is a bank arrangement.
- What happens on a refund? Whether refunds can be issued from your admin or require a support ticket sounds trivial until the first one.
- What are the fees, per transaction and monthly? Get them in writing before the integration is quoted, because they change which gateway you should be on.
2. Cash on delivery is a system, not a checkbox
COD remains a real payment method across the Gulf, and every store owner underestimates what supporting it means. It is not a button. It is:
- an order that exists before any money does, with its own status flow
- reconciliation between what the courier collected and what your books say
- a failed-delivery path — what happens to the stock, the order and the refund
- a fraud surface, because there is no payment authorisation to lean on
Decide early. Adding COD to a store designed around prepaid orders means revisiting the order state machine, and that is a rebuild of the part nobody can see.
3. Arabic checkout is not the same job as an Arabic site
You can translate a product page badly and lose a little. Translate a checkout badly and you lose the order.
The checkout is where right-to-left layout gets hardest: form fields, validation messages, address formats, phone number entry with a country code, and price strings where the currency symbol sits on the other side. Everything we covered in what breaks in Arabic RTL builds applies here with money attached.
Two specifics for this market. Addresses do not fit Western forms — many UAE addresses are landmark-based rather than street-and-number, so a form that demands a postcode and a street number in a fixed format produces either abandoned carts or unusable delivery data. And phone numbers need a country selector, not a free-text field with a digit-count check, because a significant share of your customers are on non-UAE numbers.
4. VAT invoices are a build requirement
VAT applies in the UAE, and if you are registered your customers expect a compliant tax invoice — with your TRN on it — generated automatically, not typed by someone in accounts.
Thresholds and requirements change, so check the current position with the Federal Tax Authority rather than trusting any figure quoted in an article, including this one. What matters for the build is the shape: your store has to be able to produce a proper tax invoice, store it, and email it. Retrofitting that after launch means reissuing documents for every order you already took.
5. Delivery zones and the free-shipping threshold
Two questions decide more of your margin than the product page design:
Where do you deliver, and at what price? Within the emirate, across the UAE, and to the wider GCC are three different cost structures. A flat rate across all of them means one of them is losing money.
What is the free-shipping threshold? If you plan to have one, the cart has to compute it, display progress toward it, and handle the edge where a partial refund drops the order below it.
6. Where WordPress and WooCommerce stop being the obvious answer
For most UAE stores, WooCommerce is the right call: mature, well-understood, and every gateway has an integration. We build it, and it is usually what we recommend.
It stops being obvious when the catalogue has genuine complexity — thousands of variants, per-customer pricing, or B2B accounts with credit terms. At that point you are running a system that happens to sell, and the trade-offs shift toward a custom build for the reasons in the WordPress-versus-custom piece.
The cheap things that get skipped
These cost almost nothing during the build and are painful to add later:
- Abandoned-cart recovery. Needs the email plumbing in place from the start.
- Proper product data. Real descriptions and specs — the difference between being in an AI answer about your product category and being invisible in it.
- Order-status emails that look like you. The default templates are the most-opened emails you will ever send.
- Stock behaviour at zero. Hide, show as sold out, or take backorders — decide, because the default probably is not what you want.
- A returns policy page. Customers look for it before buying, not after.
Before you brief anyone
Have answers to these five, and any quote you receive will be worth reading: how many products and variants; prepaid, COD or both; which emirates and countries you ship to; whether checkout must be bilingual; and whether you are VAT-registered.
Without them, you will get a number that changes. With them, you can compare quotes on the same basis — and see what each engagement level includes before anyone calls you.
Send the brief and we will tell you which of the five is going to cost you most.