eCommerce Development in the UAE and Saudi Arabia

Platform choice: SaaS, headless or custom

Almost every eCommerce conversation starts in the wrong place — with the platform. The platform is a consequence of your operating model, not the beginning of it. Before choosing, answer three questions honestly: how strange is your catalogue, how strange is your pricing, and what must the store talk to?

A store selling a few hundred standard products at published prices from one warehouse is well served by hosted SaaS. You will be trading in weeks, and the monthly fee will be far cheaper than building the equivalent. The trap is assuming that because SaaS is limiting in principle, it is limiting for you. Most merchants never reach the edges.

Headless — a commerce engine behind a front end you own — earns its keep when the storefront experience is the product, or when you serve web, app and in-store from one catalogue. It buys flexibility and costs you a front end that somebody must own forever: a permanent budget line teams routinely underestimate.

Fully custom is chosen more often than it is warranted, but it has a place: pricing logic no platform can express, regulated workflows, unusual fulfilment, or a business where the commerce layer is genuinely the differentiator. Our eCommerce development team in Dubai works across all three, and the honest advice is usually to start narrow and earn complexity.

Payments: gateways, Mada and Apple Pay

Payments are where Gulf eCommerce stops resembling the templates. In Saudi Arabia, Mada is the domestic debit scheme and most locally issued debit cards run on it. A Saudi store that accepts only international credit cards is asking a large share of its market to find another card. Mada support is a launch requirement, not a phase two item.

Apple Pay has become a normal expectation in both markets, and it does more than look modern: it removes card entry on mobile, where most of your traffic will be. In our experience, friction removed on a phone is worth more than most of the conversion tactics teams try first.

Beyond that, the picture is fragmented. Regional gateways, bank acquirers, wallets and instalment providers each support a different set of methods, currencies and settlement terms, and the combinations differ by market and merchant category. Confirm with your acquirer what you can actually accept, in which currency, with what settlement delay, before anyone designs a checkout around it.

Two things worth deciding early. First, settlement currency and entity: selling into both the UAE and Saudi Arabia often means more than one arrangement, which shapes your reconciliation. Second, whether the store or your ERP is the system of record for orders. Get that wrong and you will spend a year hand-matching payouts to orders — a problem our ERP development team is asked to fix more often than anyone would like.

Cash on delivery is still a real constraint

Card and wallet payments have grown steadily across the Gulf, but cash on delivery has not gone away, and quietly hiding it is a mistake in most consumer categories. Some buyers use it because they distrust unfamiliar sites; others because it is simply the habit.

What matters for the build is that COD is an operating model, not a payment method. It changes courier selection, since your carrier now collects money. It changes reconciliation, because cash arrives days later in a batch that must be matched. It changes refunds, since there is no card to reverse. And it changes your economics, because COD orders are refused at the door more often than prepaid ones.

• Launch with COD enabled and instrument it — order share, refusal rate and return rate by category and city.
• Build cash reconciliation into the design rather than bolting a spreadsheet on later.
• Consider order-value caps or verification for high-value COD, based on your own refusal data.
• Nudge towards prepaid with genuine incentives, but do not remove COD until the numbers say you can.

Arabic storefronts are not a translation task

The most common failure we are called in to fix is an Arabic store built as an English store with translated strings. Arabic needs a real right-to-left layout: navigation mirrors, forms mirror, directional icons mirror, progress indicators mirror, carousels reverse. Get this half-right and the page feels subtly broken in a way visitors cannot articulate but do act on — they leave.

Content is the harder half. Machine-translated product descriptions read as untrustworthy, and trust is the currency of a market where many buyers are still deciding whether your store is real. Arabic search must tolerate spelling and transliteration variants, or your catalogue will appear empty to customers looking straight at it. Numerals, dates and address formats all need thought, and the language choice must persist across sessions and devices — being thrown back to English on every visit is a small insult repeated daily.

None of this is exotic; it is simply work that must be scoped at the start rather than discovered at the end. Our UI/UX design team treats the Arabic layout as a first-class design, not a mirrored afterthought.

Logistics and the last mile

The UAE is logistics-friendly: dense, compact and well served, with same-day or next-day delivery a realistic promise in the major cities. Saudi Arabia is a different geography — larger and more dispersed, with real differences between Riyadh, Jeddah and everywhere else. A single national delivery promise usually means over-promising outside the big cities or under-promising inside them.

The software decisions that matter here are unglamorous. Where does stock truth live, especially if you also sell on marketplaces or in physical stores? How do you handle partial fulfilment when one line ships today and another next week? Can you switch couriers per order without a code change, given that carrier performance varies by route and season? Is address capture designed for how people here actually describe where they live, rather than assuming a postcode does the work?

VAT and ZATCA invoicing for Saudi sellers

Both markets operate VAT, and your store must produce compliant tax invoices — so VAT is a design input, not an accounting afterthought. Rounding, display, invoice numbering and credit notes all need to be right before launch.

Saudi Arabia adds ZATCA's Fatoora e-invoicing programme. Phase 1, "Generation", has applied since 4 December 2021: invoices issued and stored electronically in a structured format, with mandatory VAT fields and a QR code on simplified invoices. Phase 2, "Integration", began on 1 January 2023 and rolls out in waves by revenue threshold. It requires integration with the Fatoora platform, invoices as UBL 2.1 XML (or PDF/A-3 with embedded XML), a cryptographic stamp, a CSID obtained by onboarding your EGS (e-invoicing generation solution), plus a UUID, an invoice hash and PIH chaining linking each invoice to the one before it.

The distinction that catches online sellers out is clearance versus reporting. Standard tax invoices (B2B and B2G) must be cleared by ZATCA before you share them with the buyer. Simplified tax invoices (B2C) go to the buyer immediately and are reported within 24 hours. A consumer store lives mostly in the second case, but the moment you sell to businesses you are in both — and clearance sits in the customer's path, making its latency and failure modes a checkout concern.

Waves and thresholds have advanced repeatedly since Phase 2 began, so we will not tell you which is current — anyone who does is guessing. We confirm obligations against ZATCA's published guidance per engagement. Inovsion has delivered an ERP-integrated ZATCA e-invoice solution covering EGS onboarding and integration with automated compliance and validation, built for broad ERP compatibility precisely because sellers rarely want to change their back office to satisfy a tax rule.

Marketplace, own store, or both

Marketplaces give you demand you did not have to buy and logistics you did not have to build. You pay in commission, in competing against your own listings, and in never owning the customer relationship. Your own store inverts that: better margin, first-party data, control of the brand — and every visit generated by you.

For most merchants the answer is both, each doing a different job: marketplaces for discovery and volume on standard products, your own store for margin, bundles, subscriptions and repeat buyers. The technical implication is the one people skip — you need a single source of truth for stock and pricing, or the two channels will oversell each other and you will find out through cancellations. If you sell in Saudi Arabia, invoicing obligations follow the sale, so both channels must land in a compliant flow.

What a well-built store actually buys you

It is worth being concrete about the return, because "digital transformation" is not a benefit.

• Margin you keep. Every order through your own store carries no marketplace commission — and the difference compounds on repeat purchases.
• Data you own. First-party purchase behaviour drives merchandising, retention and forecasting. On a marketplace, that data is the marketplace's.
• Fewer hands in the loop. Orders flowing into fulfilment and accounting without re-keying remove a whole class of error and real staff time.
• A checkout that fits the market. Right payment methods, credible delivery promise, Arabic that reads properly — each removes a reason to abandon.
• Compliance that is not a monthly panic. Correct VAT and, in Saudi Arabia, correct ZATCA handling as a property of the system rather than someone's task.
• Room to move. Adding a channel, market or language becomes a change, not a rebuild.

How Inovsion helps

We build eCommerce for the UAE, Saudi Arabia and India, and we have delivered HiCare, an e-commerce portal for mosquito atomizer products — a real store with a catalogue, checkout and fulfilment path behind it. That is where the regional details stop being abstract.

We also delivered an ERP-integrated ZATCA e-invoice solution, handling EGS onboarding and integration with automated compliance and validation across a broad range of ERPs. If you sell in Saudi Arabia, this matters: your store's invoicing is not a plugin decision, and we have solved the hard part in production rather than read about it. We work with clients in Saudi Arabia — RiyadhPharma among them — and our Saudi practice is where that work is grounded.

An engagement usually looks like this. We start with your operating model — catalogue, pricing, fulfilment, back office — and only then recommend SaaS, headless or custom, including recommending you stay put if the case for moving is weak. We design the Arabic and English storefronts together rather than mirroring one into the other, confirm payment method availability with your acquirer before designing checkout, treat COD as an operating model with reconciliation built in, and integrate to your ERP or accounting system so orders, stock and invoices agree without anyone typing them twice.

Related work sits nearby: custom application development when the commerce logic is genuinely yours, data analytics once you have first-party data worth reading, and Android or iOS apps when repeat buyers justify a native experience. For a straight answer on which you actually need, tell us what you are selling and to whom — the first conversation is a diagnosis, not a pitch.