Skip to main content
Rasad

Blog

Blog Overview

Saudi checkout conversion fixes: the ten issues we find most

PublisherAbwab Admin
Published OnNov 6, 2026
Reading Duration11 min read
Last UpdateNov 6, 2026
Saudi checkout conversion fixes: the ten issues we find most

Ten issues that recur in Saudi checkout and how to test each one before fixing it, and what to measure before and after.

Saudi stores lose orders at the last step, not on the product page. The customer has already decided after reading the description, seeing the photos, and weighing the price, then meets a long form, a difficult verification step, or an unexpected payment method and stops. The problem here is not advertising and not price. It is a stage the customer had already committed to, so every drop on it is pure loss.

Available numbers help you size the opportunity without inventing results. The 50-study average cart abandonment rate reported by Baymard is 70.19%, the average checkout has 11.3 form fields, and 22% of users have abandoned an order because checkout was too long or complex. Saudi checkout adds a second layer: mada and cash on delivery, a national address, Hijri dates, verification codes, and Arabic forms that read right to left. This page lists ten issues we find most often in audits, and how to test each one with evidence you already hold before you change anything.

First: field count and forced account steps

The average checkout has 11.3 form fields, a naturally high number, but the count alone is not the issue. The issue is fields that shipping, tax, and confirmation do not require, a field asked twice in one flow, and a field buried in a long list. Every extra field takes time and opens an error path, and Baymard reports that 22% of users abandoned an order because the checkout was too long or complex. Unnecessary fields are the easiest thing to measure, because removing them needs no third party decision.

Guest checkout sits in the same space. When a customer must create an account with an email, a password, a confirmation, and an activation before seeing delivery and payment, a ready order is abandoned for a membership step. The clean fix is to show shipping and payment first, and offer membership after purchase as an option. WCAG 2.2 criterion 3.3.7 on redundant entry states the rule plainly: do not ask for the same information twice within a single process. In a form, that means capturing email, phone, and address once and reusing them in the summary, the invoice, and delivery without re-entry.

Second: local payment and delivery expectations

Saudi customers expect to see mada and cash on delivery on the first payment screen, not after a card is rejected. If mada is missing or de-emphasised, or cash on delivery appears in small text under a retry button, the customer concludes the store does not accept his method and leaves. The order of payment options on the checkout screen signals respect for this customer's expectation, including not demanding full card data when mada or cash on delivery is the expected choice. To test this before changing anything, the payment gateway already reports it: attempts, failures, and completions by method, and support messages that point to visibility rather than trust.

The national address, delivery slots, and delivery dates expose a second problem. The customer enters a long Arabic name, a flat, and building details, then meets a Gregorian calendar to pick a slot, or no evening slots, or default times that do not fit his household. The Saudi national address should not be assembled by phone support after the order, and Hijri dates matter for some customers in invoicing or home appointments while others read only Gregorian. The fix is not full localisation of every date. It is showing both calendars side by side and marking clearly which times are counted in Hijri.

Third: verification codes, error recovery, and Arabic forms

One-time codes fail often even when they work technically. The code arrives late, expires quickly, rejects Arabic numerals, hides the attempt count, or offers no resend without leaving the page. In checkout, one failed code entry equals a failed order, because the customer reads the failure as insecurity or incompetence. The right tests are simple: measure delivery rate, arrival time, and entry failure rate for codes, segment by device, and read support messages that point to delay rather than to mistakes.

Error recovery is what the customer wants to see after a failure, not what the interface offers. A good form names the field in words and keeps everything the customer entered, so a failed payment never requires rewriting the name and address from scratch. If a single error wipes the whole form, the order is abandoned. The network test is straightforward: disconnect, place the order, then check what the customer sees and whether his data survives. As for right-to-left Arabic forms, the problem goes past field order into detail: the direction of the completion icon, the alignment of messages, number formatting, and reading direction when phone numbers and amounts sit inside Arabic sentences. Each mismatch makes the form look untrustworthy.

Fourth: speed and trust at the moment of payment

Page weight is measurable before any redesign. Checkout does not need the store's full scripts or fresh product images. Folding for mobile, thumbnails instead of originals, and deferring scripts until after payment all reduce time to the payment choice without changing the look of the page. The study Deloitte ran for Google found that a 0.1 second improvement in mobile site speed was associated with 8.4% higher retail conversions. Do not copy that figure to your store; treat it as a warning that slow checkout costs before the pay button is pressed. Core Web Vitals gives you the thresholds to measure against: LCP within 2.5 seconds, INP within 200 milliseconds, and CLS within 0.1 at the 75th percentile of real visits.

Trust signals are not large badges, but small details the customer reads before confirming payment: a clear price including tax and delivery, a returns policy he can open, a working phone or chat channel, the local payment names mada and cash on delivery stated plainly, and a clearly worded Arabic invoice. When tax and delivery stay vague until the final step, the surprise reads as deception and colours trust in the whole store. The sound fix is not adding a designed badge. It is unifying the numbers between the basket, checkout, and the invoice, and showing the total early.

From reading to shipping

Want this built, not just explained?

Bring us the problem behind the article. We will tell you what it takes, what it costs, and whether we are the right team.

Fifth: how to test each issue before fixing it

Good testing uses three sources you already have and needs no new tooling. First, analytics: where exactly the customer leaves, how many fields he fills before stopping, and whether he returns after removing a field. The funnel shows the step where the full price first appears and where the customer stops after it, and you cannot see that without the paths. Second, support: look for repeat questions about price, tax, delivery, codes, and the national address, ranked by frequency rather than by tone. Third, moderated sessions: a facilitator with five to eight customers filling a real form on their phone, thinking aloud about what confuses them.

You do not need a hundred sessions to find the problem. Two focused sessions on checkout usually suffice, because checkout errors repeat in almost the same wording. What matters is that the response comes from the people who run the calls and watch what happens, not from a manager summarising them. Otherwise the answer is the team's opinion rather than what happens with the customer.

Sixth: measuring before and after the fix

Fix the completion rate before any change, then change one thing, then measure the same rate over the same window and from the same page. The three checkout constants are these: completion from the first checkout appearance to a successful OrderPlaced, the first abandon point that ends the session, and the retry rate that shows whether a resend or a repeat error is still at work. A before-and-after comparison without fixing the window and the channel is not measurement, because a campaign alone can create the difference.

Understanding the source of each number stops you copying one from Egypt to Saudi Arabia or from a management call to a government decision. On launch, keep a weekly baseline and compare against previous weeks before any change, measuring the same segment and the same channel.

MeasureDefinitionWhat it tells you before the fix
Completion rateSuccessful orders divided by checkout startsIs the problem a full form or payment only?
First abandon pointThe last step before the session endsIs the leak in entry, address, code, or payment?
Retry rateRepeat attempts divided by attempts per methodIs the error repeating, or the code missing, or the payment refused?
Checkout timeMedian from first entry to successIs the delay in the page, the form, or the thinking?
Support questionsCheckout-related questions per 100 ordersDo people miss the offer or distrust it?

If you are comparing a full interface audit before commissioning a build, a two-week UX audit sets out the process step by step and shows the register you use to decide what to fix first.

Checkout fix checklist

  1. Walk checkout on a real phone in Arabic and English and record the first three abandon points. Do not do it on a desktop.

  2. Show mada and cash on delivery on the first payment screen with the same visual weight as other cards. Review attempts and failures by method in the gateway.

  3. Add guest checkout and remove fields shipping, tax, and confirmation do not require. Let the customer buy before any membership step.

  4. Make OTP forgiving, state the attempt count, and allow resend without leaving the page. Measure arrival time and entry failure by device.

  5. Make address, slots, and Hijri dates clear on one path without re-entry. Fill the address once and reuse it in the summary, invoice, and delivery.

  6. Keep all checkout data after any error and name the affected field in words. Test a mid-payment network disconnect.

  7. Review Arabic RTL: field order, icons, messages, amounts, and phone numbers. Test it on a phone with real reading, not a preview.

  8. Show the total including tax and delivery early and keep the numbers identical across basket, checkout, and invoice. Do not add anything at the final step.

Frequently asked questions

Should I add many payment methods before fixing the form? Start with what the customer expects to see: mada and cash on delivery, a working OTP flow, and guest checkout. Additional methods matter, but they do not fix a form that rejects everyday entries.

What is the difference between a moderated session and asking customers after ordering? A session shows you where the customer stops and what confuses him word for word. A post-order survey records opinions after the result and after bias sets in. Use sessions to find the problem, and surveys to measure after the fix.

Do I need a new analytics tool? No. The analytics that tracks the checkout funnel, the payment gateway with its attempt log, and support tickets are enough to find the problem and confirm the fix. Extra tools cost time and often add nothing new.

How do I know the fix worked? Completion rises, the retry rate falls, and support questions shift away from price, tax, and address toward nothing repeating. Repeat the measurement four weeks after launch on the same segment before calling it settled.

What does rebuilding the checkout page cost? Our published e-commerce band is SAR 5,000 to 15,000 over 10 to 16 weeks for a full store delivery with a corrected checkout. We do not publish a different market range here.

Sources

Get in Touch

We'd love to hear from you. Fill out the form and we'll get back to you soon.