Building for the UAE: VAT E-invoicing, Arabic Layouts and Local Payments

Building an ecommerce platform for the UAE market is not a matter of translating a generic store into Arabic and adding a local payment button — several requirements need to be architectural decisions from the start, not late additions. This post covers the four that most affect how a UAE ecommerce build should actually be structured.

What does FTA e-invoicing compliance actually require in the build?

The UAE's Federal Tax Authority e-invoicing programme requires specific invoice data fields and TRN (Tax Registration Number) validation on both the seller and, where applicable, the buyer side. Building this in from the start means your order and invoice data model needs to capture these fields as first-class data, not bolt them onto a generic invoice template after the fact — retrofitting TRN validation and the required field set into a billing system not designed for it is a meaningfully harder and more error-prone job than including it from the schema design stage. VAT itself, currently at 5%, needs to be calculated and displayed correctly throughout the checkout flow, not just totalled at the final invoice step.

What does "genuine RTL support" actually mean, beyond translation?

A properly built right-to-left interface mirrors the entire layout — navigation, form fields, icons with directional meaning, reading flow — not just the text direction of translated labels sitting inside an otherwise left-to-right structure. This is a real design and frontend engineering effort, not a CSS toggle applied at the end of a project. Typography also matters specifically: Arabic script needs fonts genuinely designed for it, since a Latin font with Arabic character support often renders legibly but looks visibly wrong to a native reader, which undermines trust in the platform more than most teams expect going in.

Translation workflow is the other half of this — the CMS needs to support managing Arabic and English content as properly linked, independently editable versions, not a single field machine-translated on page render, which produces inconsistent and sometimes embarrassing results at the exact moments — product descriptions, policy pages — where accuracy matters most.

Which payment gateways actually matter for this market?

Network International, Telr, PayTabs, and Amazon Payment Services are the gateways we integrate most often for UAE ecommerce, alongside Stripe UAE where a business also needs international card processing. Defaulting to a single international gateway without local options measurably underperforms, since UAE customers have specific card scheme and payment method preferences that a generic international-first gateway does not always support cleanly.

Why does cash-on-delivery still need real engineering attention?

COD remains genuinely common in UAE ecommerce, more so than in many Western markets, and treating it as a minor edge case rather than a core payment method leads to reconciliation problems — unmatched orders, unclear which deliveries actually collected payment, and disputes that are hard to resolve without a proper audit trail. We build COD reconciliation logic as a first-class part of the payment flow, tracking delivery confirmation and payment collection as linked events rather than assuming card-based payment is the default case with COD handled as an afterthought.

Does it matter whether a business is a free zone or mainland entity?

Yes, for invoicing and documentation specifically — free zone and mainland UAE companies can have different regulatory and invoicing requirements, and a platform's billing and documentation generation should reflect whichever structure applies to the business it serves. We confirm this during discovery for any UAE ecommerce project rather than assume a single generic UAE business model covers every client.

How does UAE Pass fit into an ecommerce build?

UAE Pass integration is more relevant for platforms needing verified identity — age-restricted products, high-value transactions requiring stronger identity assurance — than for a typical ecommerce checkout, which usually does not need identity verification beyond payment authentication. We scope UAE Pass integration specifically where the business case calls for verified identity, not as a default addition to every UAE project.

What's the realistic cost and timeline impact of these requirements versus a generic ecommerce build?

Building these requirements in from the start, rather than retrofitting them, generally adds a moderate amount to timeline and cost compared to a single-language, single-payment-method store — mainly from the bilingual content workflow and the additional payment gateway integrations. It is a meaningfully smaller cost than retrofitting the same requirements onto a platform not originally designed for them, which is the scenario we most often get called in to fix. See ecommerce development for our general pricing structure, adjusted for UAE-specific scope during discovery.