Seven Country Codes Arrive in Jeddah in Five Days. Your Signup Form Accepts Only 05

Seven Country Codes Arrive in Jeddah in Five Days. Your Signup Form Accepts Only 05

Jeddah hosts the 27th Arabian Gulf Cup from 23 September to 6 October 2026, with eight national teams split into two groups, playing at King Abdullah Sports City Stadium and Prince Abdullah Al-Faisal Stadium. That is a sports story, and for most people it ends there.

There is an operational story inside it that concerns every restaurant, hotel, shop, transport company and clinic in and around Jeddah. For two full weeks the composition of the customer standing in front of your checkout changes. The competing teams come from Iraq, Oman, Kuwait, the UAE, Qatar, Bahrain and Yemen, and each brings a crowd carrying mobile numbers that begin 964, 968, 965, 971, 974, 973 and 967. Seven country codes other than the one your systems were built around.

The silent assumption underneath most Saudi systems

Under the Kingdom's national numbering plan a local mobile number starts 05 and runs to ten digits. That is a clear regulatory fact and it is not the problem. The problem is how that fact migrated into code as a hard validation rule: a field that rejects any input failing to match ten digits beginning zero five.

The rule looks correct because it works for 99 per cent of customers all year. Then a fortnight like this one arrives and the rule stops being protection and becomes a locked door. The difference matters: protection rejects bad input, whereas this rule rejects a real customer trying to pay you.

Worse, the pattern does not live in the phone field alone. It repeats everywhere a developer assumed the customer was a Saudi resident:

• The mobile field. Validation anchored to 05, or to a fixed length of ten digits, rejects a Gulf number before it ever reaches your server.
• The verification code. Even if the field accepts the number, your messaging provider may not have international delivery enabled on your account, so the customer enters a number and waits for a message that never arrives.
• The payment page. A gateway configured for Mada alone. The visitor holds a card issued by a Gulf bank on an international scheme and sees a decline they cannot explain.
• The ID field. A mandatory ten-digit national ID or residency number beginning with one or two. The visitor holds a passport, and the form offers no third option.
• The address. A closed city list containing only Saudi cities and a mandatory postcode in local format, inside a form that needs no address at all because the order is collection from the branch.
• The language. An Arabic-only interface on a critical path such as booking or payment. Gulf visitors read Arabic, but a share of the travelling crowd and the people with them do not.

Why none of this shows up in your reports

This is where the real danger sits. When your form rejects a visitor's number, nothing measurable happens. There is no failed order on the dashboard, no error in the logs, no support ticket. The customer tries twice, closes the tab, and goes to the competitor whose form accepted the number. You see the outcome as a sales figure slightly below what you expected in a busy week, and you explain it with any other explanation.

Systems record success in excellent detail and stay silent about what failed before it started. A completed order carries a full trail from the first click to the invoice, while a visitor stopped by validation in the browser never reached the server to leave a trace. So the first fix here is not in the form but in the measurement: log validation failures as their own event, carrying the field name and the reason for rejection, without storing the input itself. One week of that tells you exactly which field is turning customers away, and it is the same kind of visibility we covered in the single point of failure you cannot see in your architecture.

What can genuinely be fixed before 23 September

Five days is not enough to rebuild a system, but it is more than enough to remove the six barriers above, because most of them are configuration rather than development. The order below runs from highest impact downward:

• Open the mobile field to international format. A country-code selector defaulting to Saudi Arabia, and numbers stored in one canonical international format beginning with a plus. This is a change in a single layer, and it solves the problem for every country rather than seven.
• Test verification delivery to a real Gulf number before the tournament. Do not assume it is enabled. Send a code to an actual number in a competing country and confirm it lands within seconds. The test takes minutes and exposes a fault that would cost you a fortnight.
• Enable international cards and mobile wallets. Check with your payment provider which schemes are actually live on your account, not which are theoretically available on your plan. Add a wallet option if you do not have one, since it is the fastest path for a visitor who will not type a card number into a site they have never used.
• Make the ID field optional or add the passport alternative. If the field exists for a statutory reason, say so beside it and accept a passport format. If it exists out of habit, delete it this week.
• Free the address from the closed list. Make the city a free text field and the postcode optional, particularly on orders that involve no delivery.
• Translate the critical path only. The menu or product list, the booking steps, the payment page, and the directions page. You do not need the whole site translated by Tuesday. You need the visitor to be able to buy.

Immediately after the fixes comes the capacity question. This peak is not spread across the day but concentrated into two short windows before and after each match, which behaves much like the pattern we described in payday and the peak whose date you already know, with one difference: this crowd also moves geographically, in one direction, at one time.

The data you will collect over the fortnight

A visitor from outside the Kingdom registering in your system means personal data subject to the Personal Data Protection Law, exactly as a local customer's data is. The practical point is simple: do not collect a field you will not use. Every extra field added to a form built in a hurry is an obligation that stays with you for months after the tournament ends.

State on your privacy page what you collect, why, and how long you keep it, in language the visitor understands rather than copied legal boilerplate. Someone registering with you once in a fortnight will not read ten paragraphs, but they will notice if you ask for a national ID number to book a table.

The Origami view

We meet this pattern often when reviewing existing systems: a validation rule written three years ago for a situation that was true at the time, then left in the code as a permanent decision nobody revisited. The fault is not that a developer got it wrong. It is that the assumption was never written anywhere reviewable, so it became part of the structure instead of a setting.

That is why when we build a system we separate validation rules from the code and treat them as configuration, and we always store mobile numbers in international format even when every customer today is local. The cost at build time is close to zero. The cost two years later, when you open a branch in Dammam serving visitors from Bahrain, or when a tournament arrives in your city, is the difference between an hour of configuration and a change project measured in weeks. We apply the same principle across everything we build within our services: an assumption that holds today is written as a setting, not as a condition in a line of code.

What survives 6 October

The tournament ends on the sixth of October. The part you fixed does not. The Kingdom hosts major events continuously, and seasons, conferences and tournaments are now a permanent feature of the calendar rather than an exception in it. A system that accepts a visitor from outside the Kingdom today will accept them at the next event with no further work.

Start with the smallest executable step this week: open your site or app and try to complete a full purchase using a real Gulf mobile number and a non-Saudi card. If it works, you are ready. If you stop at a particular field, you have just found where two weeks of sales were going to go.

Sources

• Visit Saudi, the official Saudi tourism site — the Gulf Cup 27 page for Jeddah and official visitor information.
• Saudi Press Agency — the official announcement that Gulf Cup 27 ticket sales had opened.
• Communications, Space and Technology Commission — the national numbering plan and the format of mobile numbers in the Kingdom.
• Saudi Data and AI Authority — the Personal Data Protection Law and its implementing regulations.
• Saudi Central Bank — the regulatory framework for payment service providers in the Kingdom.