Ecommerce development Dubai: what breaks a ported storefront

Treat ecommerce development dubai-side as a port of an existing store and you hit four walls: payment mix, Arabic product data, VAT-inclusive pricing with invoice output, and delivery addressing. The cheapest of the four to fix is the one most teams start with. The dearest is the one most teams defer until the Arabic launch.

This post ranks the four by what each costs to retrofit against what it costs to design for, and sources every constraint to the rule or the provider that publishes it rather than to a vendor roundup. On two of the four, the roundups and the primary source disagree.

The regulatory reading here comes from the published decisions and the official portals. The Ministerial Decisions, the VAT Executive Regulation and the government's own consumer-protection guidance are linked on the figures so you can check them.

In retrofit order, dearest first:

1. Arabic product data and right-to-left layout — touches the data model, search and every template.
2. Delivery addressing — touches the checkout schema, validation and every fulfilment integration.
3. VAT display and invoice output — touches price fields, invoice templates and, from 2027, structured invoice data.
4. Payment mix — mostly a gateway swap and a configuration change.

Payments look like the hard part and are the configuration change

Apple publishes the list itself. On Apple's own payment platforms page, seventeen providers are listed for the United Arab Emirates, including Checkout.com, Network International, Telr, Stripe, Adyen, noon payments, Tap, Payfort and Worldpay. If your current processor is on that list, Apple Pay in the UAE is an enablement step, not a build.

One correction, because the roundups repeat it: PayTabs is not on Apple's UAE platforms list, although PayTabs itself says it introduced Apple Pay in the UAE and Saudi Arabia, in a post dated 2021 and carrying a 2023 update. Both can be true — Apple's list names platforms it has integrated, not every merchant route — but check the provider's own current claim rather than a comparison blog.

The circulating rates are stale too. Secondary comparisons put Telr at 2.49% to 2.75% for local cards. Telr's own published UAE pricing, read on 8 October 2026, is tiered by monthly volume rather than by card origin: a Startup plan at AED 249 per month and 0% per transaction for volumes under AED 10,000; an Entry plan at AED 199 per month and 2.45% plus AED 1; a Small plan at AED 99 per month and 2.35% plus AED 0.50; and a Medium plan at no monthly fee and 2.25% plus AED 0.50 above AED 50,000 a month. International cards add 0.50% in every tier, and all fees carry 5% VAT. Above AED 500,000 a month Telr quotes individually. Telr also states on that page that it is licensed by the Central Bank of the UAE to provide Retail Payment Services.

Read the structure, not the headline percentage. The local-versus-international split is a surcharge on one rate, not two rates, and the monthly fee inverts as volume rises. A model built on "2.49% for local cards" misprices both ends.

The genuinely new item is domestic scheme acceptance. Al Etihad Payments operates Jaywan, the UAE's national card payment scheme, inaugurated on 20 July 2026 with the official start of nationwide card issuance; a Mastercard co-badged credit card was announced on 21 July 2026 and a UnionPay International MoU for global acceptance of mono-badged Jaywan cards on 11 August 2026. The same operator runs Aani, instant payments of up to AED 50,000, round the clock, with proxy, QR-code and request-to-pay flows.

Co-badged cards route over the international scheme your gateway already supports. Mono-badged Jaywan cards do not. That is the question to put to a gateway before you sign, and no comparison table published in January answers it.

Arabic is a data problem before it is a layout problem

The layout mechanics of right-to-left are a subject of their own, and we cover them separately. What matters for a storefront specifically is that the obligation starts in your database, not your stylesheet.

The UAE government's own consumer protection guidance, summarising Federal Law No. 15 of 2020 as amended by Federal Decree-Law No. 5 of 2023, states that the invoice must be in Arabic and that suppliers may add other languages alongside it, and that e-commerce businesses must provide product information in Arabic.

State precisely who that does not bind. The same page says the law covers goods sold through e-commerce platforms registered in the UAE, and that it does not cover transactions between UAE customers and businesses registered outside the UAE. If you sell into the UAE from an offshore entity with no local registration, this obligation is not yours. The moment you register a UAE entity — which you will do anyway, because a local gateway needs a trade licence — it is.

"Product information in Arabic" is a schema requirement. Every attribute a shopper reads needs a parallel Arabic value with its own fallback: titles, descriptions, variant and option labels, size and material vocabularies, category names, facet labels, shipping and returns copy. A single translatable name field with a locale suffix does not survive the first catalogue import, because facet values have to be translated as values rather than display strings — otherwise your Arabic filters stop matching your Arabic products.

Three commerce-specific failures follow, and none of them are styling:

• Mixed-direction strings. Product titles and reviews routinely mix Arabic with Latin SKUs, model numbers, sizes and units. The HTML specification's dir=auto heuristic resolves direction from the first character with strong directionality; the spec calls that heuristic "very crude" and urges authors "to only use this value as a last resort", noting that it "is not a panacea". A review that opens in Arabic and ends in English renders its tail on the wrong side.
• Search. Arabic needs its own analyzer — normalisation of alef and hamza forms, optional diacritics, prefix handling — and the index is a second index, not a second column. Retrofitting that means reindexing a live catalogue.
• Review storage. User-generated text arrives in whichever direction the customer typed. Storing it without a per-record direction marker means you cannot render it correctly later without re-deriving direction from the content, which is the crude heuristic again.

For the engineering pattern, not the market: our salon booking marketplace and quick commerce platform are both Indian deployments, and both separate catalogue values from their display strings for exactly this reason. Multi-script catalogues are the same engineering problem wherever they run; the UAE adds a legal obligation on top of it.

VAT display breaks your price fields before e-invoicing breaks anything

The rule that catches a ported storefront on day one is not e-invoicing. It is price display. Article 27 of the VAT Executive Regulation (Cabinet Decision No. 52 of 2017 and its amendments, as published by the Ministry of Finance) states that in the case of a taxable supply the published prices shall be inclusive of tax. The exceptions are narrow: supplies for export, or where the customer is a registrant — and in those cases the price "should be clearly identified as being exclusive of Tax". The rate is 5%.

Most platforms built for the United States default to tax-exclusive display with tax calculated at checkout. Inverting that is not a setting on a mature store; it is a decision about which number is canonical in the price field, and it propagates into promotions, bundle maths, margin reporting and marketplace price feeds.

Invoice output is the second break. Article 59 of the same regulation requires a tax invoice to express the unit price, the gross amount payable and the tax amount in AED, and — the clause a multi-currency store misses — "together with the rate of exchange applied where the currency is converted from a currency other than the UAE dirham". If you display and charge in USD, you must record and print the AED amounts and the exchange rate you used, which means persisting the rate on the order, not recomputing it at render time.

Two easements are worth knowing. A simplified tax invoice, with a shorter field list, is permitted where the recipient is not a registrant, or is a registrant and the consideration does not exceed AED 10,000 — which covers most retail baskets. Article 61 permits rounding tax calculated to a fraction of a fils to the nearest fils, mathematically.

Now e-invoicing, where most coverage gets the scope wrong. Under Ministerial Decision No. 244 of 2025, as amended by Ministerial Resolution No. 66 of 2026, the phases are:

Who	Appoint an ASP by	Implement by
Revenue at or above AED 50,000,000	30 October 2026	1 January 2027
Revenue below AED 50,000,000	31 March 2027	1 July 2027
Government entities	31 March 2027	1 October 2027

A pilot programme and voluntary implementation both open on 1 July 2026. Two scope details decide whether any of this is your problem.

First, "Revenue" is defined in Article 1 of Decision 244 as the gross income earned during the most recent accounting period based on the financial statements prepared under applicable legislation — not VAT-taxable turnover, and not your taxable supplies figure. A marketplace booking gross merchandise value through its own books can clear AED 50m on gross income while its taxable supplies sit far below it, and land in the first wave.

Second, and this is the one a retail storefront should read twice: Article 5(2) provides that business-to-consumer transactions shall not be subject to the Electronic Invoicing System, and that any person engaged exclusively in such transactions shall not be subject to it, until a time determined by a decision issued by the Minister. A B2C transaction is defined as one between a person carrying on business and a recipient who is a natural person not carrying on business.

So a pure direct-to-consumer store is outside the e-invoicing system today; a store with a wholesale or corporate-account side is not, for that side. Build the invoice data model so the B2B path can carry structured output later, and do not buy an ASP integration for a B2C-only catalogue on the strength of a 2027 date that does not apply to it. The Ministry of Finance also notes on its e-invoicing portal that unstructured formats — PDF, Word, images, scanned copies and emails — are not e-invoices, which rules out the PDF attachment most storefronts ship with.

Makani, not street numbers: the field a ported checkout does not have

A ported checkout assumes a street number, a street name and a postcode, and validates on that shape. Dubai does not run on it. Dubai Municipality operates Makani, described in its own published app listing as "the official geographic addressing system adopted in the Emirates of Dubai, Ajman, Umm Al Quwain, Fujairah & Ras Al Khaimah".

The mechanics matter for a form field. A Makani number is ten digits written as two groups of five — the listing's example is 30032 95320 — and it identifies a building's entrance rather than a plot or a street. Dubai Municipality's description is that it "doesn't require using names, codes or explaining the location's direction", and that numbers-only addressing "suits multi-nationalities with different languages in the U.A.E." Makani plates carry a QR code the app reads, and the app resolves a land number or a traditional address to its Makani number.

What this costs in a port: a ten-digit field with its own validation, optional in emirates that do not use Makani, a landmark field your 3PL actually reads, and a decision about what the address object is keyed on. If your fulfilment integration serialises a single-line address string, a Makani number arrives as noise. This is not a UI change — the address object and everything consuming it is the change.

One limit on our reading: we verified the format, the operator and the emirates covered from Dubai Municipality's published listing. We found no current official statement on per-unit numbering inside buildings, reported in the press as a plan around the original rollout, so we do not claim it.

The strongest case for shipping none of this

It is a real argument. English is the working language of Dubai commerce. Visa and Mastercard via the processor you already have will authorise. A 3PL will take a free-text address and a phone number and work it out. An offshore entity sits outside the consumer protection law's stated scope, and a B2C catalogue outside the e-invoicing system. So launch in English, measure, localise if the numbers justify it.

For a market test that is correct, and we would not argue a company out of it. It stops being correct when you register a UAE entity, which you will do as soon as you want a local gateway, a trade licence or local marketplace listings. At that point the Arabic obligations attach to a catalogue you have already filled, the tax-exclusive price field is already canonical, and the address object is already serialised into every integration you have built since.

That is the whole argument for sequence. None of these four is hard. Three of them are hard later.

What ecommerce development dubai work should design for, not retrofit

Ranked by the cost of doing it second rather than first:

What breaks	Where it lives	Cost of retrofit
Arabic product data and RTL	Data model, search index, every template	Highest — reindex plus re-translate values, not strings
Delivery addressing	Address object, checkout validation, 3PL contracts	High — every integration that serialises an address
VAT display and invoice output	Price fields, order records, invoice templates	Moderate — canonical price change propagates to reporting
Payment mix	Gateway configuration	Low — enablement, plus one scheme-acceptance question

The practical consequence is a sequencing decision before the first sprint, not a backlog item. Decide now whether the catalogue is bilingual at the schema level, whether the price field is tax-inclusive, and what the address object holds. Those three are near-free on day one. For how we approach e-commerce builds, or what we work on from Dubai, both are a click away — and if you are weighing adaptation against a replatform, the Magento 2.4.6 end-of-support timeline is the other clock for the same page.