E-Commerce Software Engineering
We build online stores and checkouts for the way UAE shoppers actually buy: local payment methods, cash on delivery, Arabic and English product pages, and VAT-ready invoices.
If your invoice data is wrong at the point of sale, your B2B customers may not be able to reclaim VAT on it. It is cheaper to get the invoice data right when the order is created than to fix it after launch.
Commercial Landscape
An online sale in the UAE involves VAT, consumer protection rules, and, for more and more businesses, e-invoicing. The storefront is the part customers see. The tax and invoice decisions are made in the order and product data behind it.
The Ministry of Finance e-invoicing pilot started on 1 July 2026. Businesses with revenue of AED 50 million or more must go live on 1 January 2027, and smaller businesses follow on 1 July 2027. If your product and order data is set up properly from the start, e-invoicing becomes a setting you switch on, not a second project.
Sources: Ministry of Finance UAE e-invoicing portal, including Ministerial Decisions 243 and 244 of 2025 and Ministerial Decision 66 of 2026 (which moved the Phase 1 provider-appointment deadline to 30 October 2026), and the Ministry's Electronic Invoicing Guidelines. Dates checked October 2026. Rules can change, so confirm current dates with the Ministry of Finance or the FTA.
Domain Overview
Every sale is decided on a page that loads on a customer's phone, next to many other open tabs. We handle the store and its payment connections as UAE ecommerce development with local payment gateways, and the Arabic and English pages as Arabic and English ecommerce website development. Checkout is also where things break most often, because scripts, payment frames, address checks, tax, fraud checks and stock holds all compete for the same few seconds.
Our rule is to remove before we add. Every script on a checkout page can fail, slow the page, or leak data. Card fields come from the payment provider, not from us. Tax and fraud decisions are made on the server, where a customer cannot change them. The browser only shows the page and sends the order. If you also want customers to find your store through Google, SEO for ecommerce stores in the UAE is worth planning from the start.
Headless is often sold as a speed upgrade. Speed can improve, but the bigger benefit is that the storefront, checkout, product data and order system can each be released on their own schedule.
That only works when the connections between them are written down and versioned. Without that, headless just spreads the same complexity across more places. We define the API contracts first, generate types from them, and treat a breaking change as a planned, versioned release.
If you hold physical stock, you probably have at least three places that each think they know the count: the warehouse, your store, and a marketplace. They will sometimes disagree, and the cost lands on one side. A unit sold twice cannot be un-promised to a customer.
So we treat stock as a reservation, not just a number. Stock is held for a set time against a pending order, released when the order completes or expires, and checked against every channel continuously. Your operations team can see the state of each reservation, not only the total.
The simplest way to keep card data out of your PCI DSS scope is to never handle it. With hosted fields and tokenised payment gateways, the card number goes from the customer's browser straight to the payment provider. Your system only receives a token. It can store the token, show the last four digits, and use it for later charges.
Some work always remains: the checkout flow, the order system, the staff admin and the data moving between them still need controls and records. We keep those records so that a payment question from a customer or an assessor does not turn into a week of digging through logs. Formal PCI attestation is handled with your acquiring bank and assessor.
Operational Friction
These are common problems for online retail teams, described the way they show up day to day.
The site copes with normal traffic, so nobody tests the sale until it is live and customers are paying for orders the system cannot confirm.
We test the checkout path itself under many shoppers at once, not just the homepage, because that is where revenue is decided and where third-party services tend to be slowest.
The warehouse, your store and the marketplace show different numbers, and the customer promised the last unit hears something else.
Stock is held against a pending order for a set time and checked against every channel, so one unit cannot be promised twice.
A campaign price or a regional price needs a code change and a release, so it goes out late or not at all.
Prices, regional prices and campaign rules are settings your merchandising team controls, not code that needs a developer and a release.
If checkout sends card details to your own server, the whole platform can fall into PCI scope, and card data can end up next to application logs.
Card data goes from the browser to the payment provider, and your platform stores only a token. This keeps most of your system outside card-data scope.
Core Capabilities
Each module exists to fix a specific, repeating problem.
A fast online store with a product model that handles variants, bundles, regional availability and merchandising rules without code changes.
A checkout built on provider-hosted card fields, with several payment methods, safe retries, and fraud and tax decisions made on the server.
Stock held against pending orders with an expiry, reservation status visible to operations, and ongoing checks across channels.
Price rules your merchandising team owns, regional prices, promotional pricing, and VAT calculation stored with the order.
Order and payment capture, split shipments, returns and refunds, and an order timeline for the customer that matches the internal status.
Funnel, basket and repeat-customer reports built from the order record, with returns and discounts subtracted instead of counted as revenue.
Reference Architecture
The most important boundary is between the browser and everything that makes decisions.
Server-rendered store, mobile apps and B2B ordering. Display only, with no business rules.
Cart state, payment method choice, retries, and recovery when a step fails in a third-party embed.
Catalogue, pricing, promotions, tax and order status in one place, as the single source of truth.
Reservation lifecycle, warehouse and store stock, shipments, and ongoing checks across channels.
Tokenised gateway connection, detailed order records, refund handling, and matching against bank records.
Payment, tax and fraud decisions happen on the server. The browser shows and submits; it does not decide.
Headless only helps when the contracts between services are versioned. Otherwise it is just more moving parts.
Stock is reserved, not just counted. A count is a snapshot; a reservation is a commitment.
Security & Payment Data
Ecommerce platforms handle payment data and personal information in volume. These are the controls we put in place. Formal attestation, such as PCI DSS, is done with your acquiring bank and assessor.
With provider-hosted fields, the card number goes from the browser to the payment provider. We store a token and the last four digits.
Provider-hosted fields · token storage only
Price, tax, discount and shipping are recalculated and checked on the server, so a changed browser request cannot change what is charged.
Server-side price authority · signed order payload
Order changes, refunds and price edits are restricted by role and recorded with who did them and why.
Role-based access · reason required
Profiles, addresses and order history are encrypted at rest, and only staff and systems that need them for fulfilment can reach them.
Encryption at rest · access limited to fulfilment needs
Rate limits, challenge pages and bot scoring on sensitive endpoints such as checkout and pricing.
Rate limiting · bot scoring · challenge pages
Refunds need a reason and an approval, and every money movement is matched against the payment provider and the bank.
Approval step · reconciliation with provider and bank
Typical Stack
Delivery Lifecycle
We map your catalogue, sales channels, payment methods in use, and where the real stock number lives today.
OutputChannel and data map
We agree in writing on service boundaries, the API contracts between them, and the stock reservation model.
OutputArchitecture and versioned contracts
We build and prove the checkout path early, because it carries the revenue and the outside dependencies.
OutputWorking checkout on real payment methods
We test sale-level traffic, gateway timeouts, two shoppers buying the last unit, and partial payment capture.
OutputLoad report with bottleneck fixes
We launch in stages with a rollback plan for each channel, and set up alerts on the numbers that point to failed orders.
OutputLaunch runbook and alert set
Use Cases
A separate front end that shows UAE payment methods first, so customers pay the way they expect instead of being sent to a page they do not recognise.
Checkout no longer depends on international card acceptance.
Separate product copy for each language, right-to-left layout and a mirrored checkout, with one stock source so the two languages never drift apart.
An Arabic shopper gets the whole store, not a partial one.
A delivery order type with COD eligibility rules, a hold-and-release flow, and a returns path that matches what was collected against what was kept.
COD stops being the place where margin quietly disappears.
Catalogue, stock and order sync with Amazon.ae and noon, with clear rules for conflicts so a price or stock change does not quietly differ between channels.
One stock number that is true everywhere.
Invoice data built into the product and order model, so structured e-invoices can be created and sent through an accredited service provider when your business comes into scope.
E-invoicing becomes a configuration change, not a rebuild.
Account pricing, credit limits, purchase orders and a separate approval flow for trade customers, running next to your consumer store.
B2B orders stop going through the consumer checkout.
Integration Surface
Related Services
Ecommerce projects usually go together with UI/UX design for the store, web development for the wider site, and SEO so shoppers can find it.
FAQ
VAT is calculated on the cart and the order, based on the customer's tax treatment. Invoice data is stored in a structured form, so it can be sent as e-invoice data and not only as a PDF. This matters because the Ministry of Finance e-invoicing programme started its pilot on 1 July 2026. Businesses with revenue of AED 50 million or more must go live on 1 January 2027, and smaller businesses on 1 July 2027. Invoice and credit note data has to reach the Federal Tax Authority through an accredited service provider. We build the invoice model once, so switching on e-invoicing is a configuration change when your business comes into scope. Please confirm your own deadline with the Ministry of Finance or your tax adviser.
For UAE card acquiring we work with Telr, PayTabs and Network International, with wallets such as Apple Pay on top. For cross-border sales we can add an international gateway. We usually start with local acquiring for local customers, because it settles in a way UAE businesses are familiar with. The right choice depends on your customer mix, your average basket and whether you need instalments, so we normally test two or three options with your own traffic before you commit.
Yes. We build Arabic stores properly instead of just flipping an English layout. That means right-to-left text and spacing, mirrored navigation and icons, numbers and currency that read correctly in Arabic, and Latin brand names and order numbers kept separate so they do not scramble the sentence around them. We also test the full checkout in Arabic from start to finish, because payment and address forms are where layout bugs usually show up.
Yes. We set up COD as its own order type with eligibility rules, such as which areas, order values or customers qualify. We add a hold-and-release step for stock and a returns flow that matches the cash collected against what the customer kept. That makes COD orders easier to track and reconcile, instead of a manual process on the side.
It depends on what is actually holding you back. Headless is worth it when you need the storefront, catalogue and checkout to be released independently, or when your current platform's speed is the real limit. It is not worth it if the real problem is messy catalogue data or a checkout that has never been load-tested. We diagnose first, then recommend an architecture.
Promotions are data, not code. A campaign price, a bundle, a free-shipping threshold and a regional price are stored as settings that your merchandising team controls. The server checks the rules when an order is placed. A campaign can start and end on schedule, and the price is still enforced on the server, so it cannot be changed from the browser.
It depends on how the move is done, and this is where many rebuilds cause damage that could have been avoided. A good migration keeps URLs the same or sets up permanent redirects, keeps page titles and structured data, and checks that the new pages show the same content as the old ones. We crawl the site before and after the change and compare the results, so problems are found before launch and not in search results afterwards.
Send us your current store URL and what traffic looks like during a promotion. We will reply with a written view of what is slow and what we would change.
A 30-minute technical conversation, not a sales call.