What a UAE online store has to show, and what that costs in build terms

Most of the compliance work in a Dubai e-commerce build is not legal copy. It is data model decisions wearing the costume of content decisions.

Last reviewed 2026-10-03.

This is the operational companion to the broader piece on website development in Dubai. That one covers the shape of a project. This one covers what an online store has to do, because selling changes the obligations.

The licence decides what the site may say

Selling through a website, an app or a social account is a licensed activity in the UAE, and the activities on the licence are the ceiling on what the store may offer. A site that lists a product category outside the licensed activities is a compliance problem no amount of good engineering fixes, and it is also the usual reason a payment provider pauses an account during onboarding.

Two consequences for the build. First, the catalogue structure should be agreed against the licence before the data model is settled, because discovering a category is out of scope after launch means unpublishing products that already have URLs. Second, the licence produces identifiers and a legal entity name that have to appear on the site, which means they belong in configuration rather than typed into a footer template.

What the site has to tell the customer

Federal Decree-Law No. 14 of 2023 on trading by modern technology based means is the governing instrument, and it replaced the 2006 electronic transactions and commerce law. It is written around disclosure: who the provider is, what the terms of the transaction are, what the stages of the trade are, and what the consumer is entitled to. It also contemplates the invoice being issued without paper, which is the legal basis for the receipt your checkout emails. Consumer rights sit alongside it in Federal Law No. 15 of 2020 on consumer protection, as amended, and the Ministry of Economy legislation index is where to check for newer decisions.

In practice this turns into a list of things the store has to make reachable, and reachable is the operative word. A policy that exists but is three clicks from a product page is a policy a regulator and a customer will both treat as absent.

None of these are design preferences. They are the parts of the interface that exist because the transaction is regulated.

Tax inclusive pricing and the invoice

Article 27 of Cabinet Decision No. 52 of 2017, the executive regulation of the VAT law, requires advertised and published prices to be inclusive of tax. The exceptions are narrow and have to be stated clearly, principally exports and supplies to registered businesses, and reverse charge supplies are priced without tax by their nature. The current text is reachable from the Federal Tax Authority legislation page.

Engineering consequences that are easy to get wrong when the store runs on a platform built for another market:

• The display price has to be the tax inclusive figure everywhere a price appears, including listing pages, search results, structured data, cart lines, emails and any feed sent to a shopping channel.
• The tax amount still has to be shown on the invoice, so the data model needs both the inclusive price and the tax component. Storing one and deriving the other at render time is where rounding errors enter.
• Rounding has to happen in one place. A total computed from rounded lines and a total rounded after summing produce different numbers, and the one on the invoice has to match the one charged.
• If the store sells to businesses as well as consumers, tax exclusive display for those buyers is a conditional behaviour, which means the customer type has to exist in the model before the templates are built.
• Credit notes for refunds are a separate document type, not a negative invoice with the same number.

Personal data at the checkout

Federal Decree-Law No. 45 of 2021 has applied since 2 January 2022, while its executive regulations remain unpublished. That combination is genuinely awkward, and the honest engineering response is to build to the principles in the law rather than to wait, because the obligations in the law are not suspended by the absence of the implementing detail. The federal portal keeps a plain summary on its data protection page.

What that looks like in a checkout, concretely. Collect the fields the order needs and not the ones the marketing team would like. Keep a written reason for each field, because that record is what makes a later review survivable. Separate the consent to process an order from the consent to be marketed to, and store them separately with a timestamp, because a single tick box covering both is the design most likely to fail review. Give the customer a route to see, correct and delete what you hold, and make it a real route rather than an email address that nobody triages. Know where the data physically goes, including every third party script and processor, since cross border transfer is one of the areas the law addresses directly.

Cookie banners and tracking

Tracking is the area where stores in this market most often copy a European banner, change the logo and assume the matter is closed. The banner is not the compliance work. What matters is whether scripts actually wait for the decision, and on most stores they do not, because the analytics and advertising tags are loaded by a tag manager that fires before the banner has rendered.

• If the banner is decorative and the tags fire regardless, you have taken on the obligation without getting the protection.
• Decline has to be as easy as accept, and declining has to actually stop the non essential scripts.
• Keep an inventory of every third party script the site loads and what each one receives. Most teams discover scripts they did not know about the first time they do this.
• Server side analytics of your own requests is a different question from third party tracking, and treating them identically either breaks your reporting or overstates your compliance.

Authentication, refunds and cash on delivery

Card payments in the region routinely involve a bank challenge, so the checkout has to treat a redirect away from the page and back as an ordinary path. A flow designed on the assumption that the customer stays on one page will fail its first real transaction, and it will fail in the worst way: the money moves and the order does not exist.

That specific case deserves a named owner and a tested procedure. Build the reconciliation the other way around from how most stores do it: start from payments received and confirm each one has an order, rather than starting from orders and checking they were paid. The first catches the failure mode that costs you a customer and a complaint. The second does not.

Refunds are not a phase two feature here. A consumer protection regime with a published returns policy means the refund path will be used, and a refund performed manually in a payment dashboard without a corresponding record in the store leaves the books wrong. Cash on delivery remains common enough in this market that it has to be modelled rather than bolted on, which means an order can be placed, shipped, partly paid, refused at the door and returned, and the state machine has to hold all of that.

Delivery, returns and the status nobody models

Addresses in the UAE do not follow the postcode model most e-commerce platforms assume, so a required postal code field will cost you orders. What couriers actually need is a precise location and a reachable phone number, which means the address form should be designed around those rather than around a form library's defaults. Collect the phone number in a format that survives normalisation, because the courier will call.

The status nobody models is the partial return. One item of four comes back, the customer keeps the rest, the refund is for part of the order, the tax on the refunded part has to be reversed, and the credit note has to reference the original invoice. Stores that did not model this do it by hand in a spreadsheet for years.

What all of this costs in build terms

None of the above is exotic, and all of it is cheaper before launch than after. The pattern is consistent: these requirements are data model decisions wearing the costume of content decisions.

• Licence and entity details in configuration, rendered everywhere.
• Price stored with its tax component, rounded in one place.
• Customer type in the model if business buyers exist.
• Consents stored separately, each with a timestamp and a source.
• Invoices and credit notes as first class documents with their own numbering.
• An order state machine that includes refused, partly paid and partly returned.
• A reconciliation job that starts from money received.
• Arabic as a field level concern in the content model, not a duplicate store, which is the subject of the bilingual build guide.

If the store is being built on a platform rather than from scratch, the question to ask of each item on that list is whether the platform models it or whether someone will model it in a plugin. Both answers are workable. Not knowing which one applies is what hurts. Teams doing this with us usually need WooCommerce, Shopify, Magento or Laravel depth rather than generalists, because the work is in the commerce model.

Frequently asked questions

What does UAE law require an online store to display?

Provider identity and licensing details, the terms of the transaction, the product specification, the total payable including tax and delivery before the customer commits, the return and refund policy, any warranty offered, and a contact route that works. The governing instrument is Federal Decree-Law No. 14 of 2023 on trading by modern technology based means, read with the consumer protection law.

Do UAE product prices have to include VAT on the website?

Advertised and published prices must be tax inclusive under Article 27 of the executive regulation of the VAT law, with narrow stated exceptions such as exports and supplies to registered businesses. The tax amount still has to appear on the invoice, so the store needs to hold both the inclusive price and its tax component.

Does a UAE store need a cookie consent banner?

The question behind the banner is whether non essential scripts wait for a decision. A banner that renders while the tags have already fired gives you the obligation without the protection. Build the script loading around consent first, then add the interface.

Is cash on delivery still worth supporting?

It remains common enough in this market to model properly rather than treat as an edge case. The cost is in the order state machine, because a cash order can be placed, dispatched, refused at the door and returned, and each of those states has accounting consequences.

Can a store ship before the executive regulations to the data protection law are published?

Yes, and waiting is not an option since the law itself has applied since January 2022. Build to the principles in the law: collect only what the order needs, record why each field exists, separate order consent from marketing consent, provide a real access and deletion route, and know which third parties receive what.

Which platform suits a UAE store best?

The platform matters less than whether it models tax inclusive pricing, credit notes, partial returns and a bilingual content model without heavy customisation. Check those four against any candidate. Whatever is missing becomes custom work, which is fine as long as it is planned rather than discovered.