A customer wanted your product enough to put it in the basket. Whatever happens next is a problem you created, and almost all of it is fixable without knowing a single industry statistic.
That is the useful frame for this subject, because the subject is drowning in statistics. Nearly every cart abandonment figure in circulation traces back to a research firm that sells reports about cart abandonment, and we are not going to repeat any of them. What follows is drawn from what the web standards bodies and the platforms actually publish, which turns out to be specific and practical.
This article covers the checkout itself, from add-to-cart to payment confirmed. Platform choice is in our Shopify, WooCommerce and custom comparison, gateway fees are in our payment gateway comparison, and VAT compliance is in our VAT-compliant e-commerce guide.
Stop forcing people to create an account
Make guest checkout the default. Google's developer guidance says forcing users to create an account to make a purchase is cited as a major reason for shopping cart abandonment, and that guest checkout should be the default [4]. Apple's merchant documentation makes the same point independently, noting that requiring registration before purchase is a leading cause of checkout abandonment, and suggesting you offer account setup after the purchase completes [5].
Two platform vendors with no shared interest reached the same conclusion in their own documentation. That is stronger evidence than a percentage from a company selling conversion consulting.
The business objection is usually that accounts are needed for order history and marketing. Both are available after the sale. A customer who has just paid is far more willing to create an account than one who has not yet decided to trust you.
The form layer, which is where most of the loss is
This is the least glamorous section and the highest return, because it is specified in public standards rather than argued about.
Use the right input types. The HTML standard defines an email type for email addresses and a tel type for telephone numbers, and it notes deliberately that the telephone type does not enforce a syntax because phone fields tend to be free form [1]. That last detail matters here, where numbers get written with and without country codes and with varying spacing.
Do not use the number type for card numbers, phone numbers or account numbers. Google's guidance explains why plainly: it adds an up and down arrow to increment numbers, which makes no sense for that data [3]. Use a text field with a numeric input mode, which gives the numeric keypad without the spinner.
Build the card number as one field. Google's guidance recommends a single input rather than four boxes, allowing spaces during entry and stripping them before submission, with a length that accommodates cards from fourteen to twenty or more digits, and advises against a manual card-type selector since the type can be inferred from the number [3]. Four separate boxes break pasting and autofill and buy nothing.
Get the autocomplete attributes right. The HTML standard defines a specific vocabulary for this: given name, family name, organization, street address, address lines, address levels, postal code, country, telephone, email, and the card fields, all of which can carry a shipping or billing prefix [2]. Used correctly, this is what lets a browser fill an entire checkout in one tap.
Google adds the requirement that makes it work: fields need a stable name or id that is not randomly generated on each page load or deployment [4]. Several front-end frameworks generate fresh identifiers on every build, which silently breaks autofill and password managers for every returning customer, and produces no error anyone will ever see.
Validate as they go. Google's guidance is to show problems inline and explain how to fix them as soon as the user has entered a value, rather than after submission [4].
Address forms and why this market breaks them
Most checkout address forms assume house number, street name and postal code. In the UAE, buildings have names, the area matters more than the street, and postal codes are not part of the standard postal system.
Google's address guidance happens to fit this market well. It recommends a flexible two-line format or a single text area rather than rigid per-field structures, says not to require a postal code for countries where one is not standard, and uses inclusive labelling such as ZIP or postal code rather than one locale's term [3]. That is our reading of a general rule rather than a UAE-specific requirement anyone published, but the fit is exact.
One line of that guidance deserves its own paragraph: avoid regular expressions that only match Latin characters [3]. A validation rule written for English silently rejects a valid Arabic building or area name. The customer sees an error they cannot resolve, leaves, and tells you nothing. It is a one-line fix and it is very common.
The payment step
Digital wallets remove typing, which is the whole benefit. Apple's guidance is unusually specific and worth following exactly. Put the Apple Pay button prominently and above the fold, on product pages, the cart and checkout [5]. Offer express checkout so users can select shipping options and addresses inside the payment sheet and check out without typing, which Apple says leads to decreased cart abandonment and increased conversion [5]. Present the payment sheet immediately after the button is tapped, with no interim screens except to collect a necessary product detail such as size [5].
And critically: use the name, billing address, shipping address, shipping method, phone and email that the sheet provides, rather than asking the user to enter any of them, because doing so increases abandonment [5]. Collecting the same address twice is a common implementation error that removes the entire benefit.
Apple describes the outcome as substantially increased checkout conversion [5] and does not publish a percentage. Neither will we. Google Pay works through the same mechanism of tokenised card data and fewer typed fields [7], though Google does not make an equivalent published claim.
There is also a standards-track route worth knowing about before commissioning a custom payment form. The W3C Payment Request API exists to let merchants use payment methods with minimal integration while the browser supplies stored payment and address details [6].
On 3D Secure, we checked the regulation rather than repeating what everyone says. We searched the Central Bank's own retail payment services and card schemes regulation and its consumer protection standards, and neither text mentions 3D Secure or 3DS anywhere. What the regulation requires is multi-factor authentication for high-risk transactions, stated without naming a protocol. Stripe's own documentation lists the jurisdictions with a regulatory mandate as the EEA, UK, India, Japan and Australia, and the UAE is not among them [8].
So the accurate position is that 3D Secure is effectively required through card scheme rules rather than named in UAE law. It is still a real friction point: a redirect or a one-time code is a step where some card payments are lost. That is the mechanism, and you should measure it in your own funnel rather than accept a figure for it.
Cash on delivery, treated as a checkout decision
Cash on delivery is the payment method most often argued about on feeling rather than arithmetic, so treat it as a checkout decision with a cost attached rather than a cultural given.
The case for offering it is straightforward: it removes payment friction entirely for customers who will not enter card details on a site they do not know. For a new brand with no reputation, that is a genuine barrier being lowered.
The costs are equally concrete and they land in three places. Couriers charge a fee to collect cash, which is a per-order cost your card payments do not carry. Refused deliveries tie up stock and cash at once, and the goods come back needing inspection before they can be resold. And reconciliation takes staff time every week, because cash collected by a courier arrives as a batch that has to be matched against orders by hand.
We are not going to tell you what share of UAE orders pay cash. No government or platform source publishes that figure, and the numbers in circulation come from vendor surveys. What we can say is that the decision is measurable inside your own business: compare the contribution per order on cash against card, including the courier fee and your actual refusal rate, and the answer stops being a matter of opinion.
Two middle positions are worth knowing. You can offer cash above a basket value where the margin absorbs the cost, and card only below it. And you can offer it to repeat customers while requiring card from first-time buyers in higher-risk categories. Both keep the option available without applying its cost to every order.
Trust, which mostly means no surprises
Show prices including VAT. Article 38 of the UAE VAT law states that for taxable supplies the advertised price shall include the tax, with exceptions determined by the executive regulation [9]. At checkout that means the total at cart, checkout and confirmation should be the VAT-inclusive figure rather than a smaller number that grows at the last step.
Show delivery cost before the final step. We looked for a specific numbered UAE rule requiring this at a particular stage and did not find one on the Ministry of Economy's own legislation list [10], so we are not citing the clause numbers that circulate on advisory sites. Treat it as sound practice and as a reasonable reading of the general transparency duty in consumer protection law.
The operative law is Federal Law No. 15 of 2020 as amended by Federal Decree-Law No. 5 of 2023 [10]. It requires a dated invoice covering trade name, address, type of goods, price and quantity, and requires e-commerce businesses to provide licensing details, Arabic product information, and payment and warranty data [11]. On returns, rights exist but the conditions and any time limit depend on the goods and circumstances rather than one universal window, so do not publish a flat fourteen days as a rule.
A pattern we see constantly. A UAE store adds a delivery charge at the final step because the shipping rule needs the address to calculate. The customer has entered everything, and the total then rises. They leave. The fix is not a better checkout design, it is showing an estimate earlier and confirming it later. The order was lost to sequencing, not to price.
The step after payment still counts
The order confirmation is part of the checkout, and treating it as a receipt wastes the one moment when a customer is most willing to hear from you.
Two things belong there. A delivery expectation specific enough to be useful, which means a date range rather than a promise to be in touch, because the most common post-purchase support ticket in this market is somebody asking where their order is. And the account offer, which is the moment Apple's guidance points at: ask for the account after the purchase completes rather than before it [5].
There is also a quieter benefit. A confirmation page that states clearly what was bought, at what VAT-inclusive total, to which address, gives the customer a chance to catch your mistake before it becomes a return. A wrong address caught on the confirmation screen costs an email. The same error caught at delivery costs the courier fee, the return, and usually the customer.
Measure it, then change one thing
You cannot fix a leak you cannot see. Instrument the funnel using the standard e-commerce events covering viewing an item, adding to cart, beginning checkout, adding payment information and purchasing [12]. That gives you a step-by-step view of where people stop rather than a single conversion rate that tells you nothing about cause.
Our product analytics guide covers the event model in full, including the registration step that leaves most implementations collecting data nobody can report on.
On benchmarks, the honest answer is that your own last quarter is the only comparison worth having. Published checkout conversion figures vary so widely by category, price point, traffic source and counting method that comparing yourself to one changes no decision you would make.
What it costs
A focused checkout audit starts from around AED 3,000 with us, covering the form and field layer, the payment step, the mobile experience, and the funnel instrumentation needed to see where the leak actually is. Implementing the fixes starts from around AED 4,000, depending on your platform and how much of the checkout you are allowed to change.
These are our own figures rather than a market survey, since no official body publishes rates for this work. Final pricing depends on scope. For comparison, a single landing page and CRO engagement starts from around AED 2,500, and a measurement setup starts from around AED 2,500.
Worth saying plainly: if very few people reach your checkout at all, an audit will tell you that rather than fix it. The problem is upstream, and the money belongs somewhere else.
The order to fix things in
- Turn off forced account creation and make guest checkout the default
- Add correct autocomplete attributes to every field, with stable names and ids
- Fix input types: email and tel, never number for card or phone
- Rebuild the card number as one field that accepts pasted input
- Loosen address validation so Arabic characters and no postal code both pass
- Move validation errors inline, at the moment the field is completed
- Show delivery cost and VAT-inclusive totals before the final step
- Add a digital wallet and let its payment sheet supply the address, once
- Instrument the funnel so the next change can be measured
The first six cost nothing but a developer's attention and are specified in public standards. That is the part worth internalising: most of what loses orders at checkout is not a design opinion, it is documented, and somebody simply has not done it yet.
If your checkout has never been looked at properly, contact us and we will start by telling you whether your problem is actually in the checkout at all.
References
[1] WHATWG, HTML Standard: the input element. html.spec.whatwg.org
[2] WHATWG, HTML Standard: autofill. html.spec.whatwg.org
[3] Google, Payment and address form best practices. web.dev
[4] Google, Sign-up form best practices. web.dev
[5] Apple Developer, Apple Pay Planning. developer.apple.com
[6] W3C, Payment Request API. w3.org
[7] Google Pay for Web, Web tutorial. developers.google.com
[8] Stripe, 3D Secure authentication. docs.stripe.com
[9] UAE Federal Tax Authority, Federal Decree-Law No. 8 of 2017 on VAT, Article 38. tax.gov.ae
[10] Ministry of Economy and Tourism, Consumer protection and commercial control legislations. moet.gov.ae
[11] The Official Portal of the UAE Government, Consumer protection. u.ae
[12] Google Analytics Help, Recommended events. support.google.com
