Getting sandbox access to Gulf gateways as a non-resident developer
What the public signup paths of Gulf payment providers required, where they blocked a foreign evaluator, and which routes were self-serve versus sales-led.
For Gulf payment gateways, the first integration problem is often not technical. It is access.
Before any webhook can be tested or payment flow implemented, a team has to get far enough into a provider’s product to see credentials, docs, dashboards or onboarding steps that are more useful than the public marketing site. In the Gulf, that first step is inconsistent enough to be worth tracking on its own.
This article records the public onboarding paths observed while evaluating regional gateways as a non-resident developer writing public technical documentation. It is intentionally narrow. It does not claim whether a provider can ultimately board a foreign merchant, nor whether an enterprise sales route exists behind the public site. It records what the public route allowed, what it asked for, and where it stopped.
All observations are dated. Public onboarding flows change quietly.
Results at a glance
| Provider | Date checked | Public route shape | What was required before meaningful access | Outcome from the public path |
|---|---|---|---|---|
| Moyasar | 2026-07-26 | Self-serve registration | Saudi mobile number at registration | Blocked before any form completion |
| Tap Payments | 2026-07-30 | Public site protected by anti-bot verification | Human-verification puzzle before site access | Blocked before reaching signup |
| PayTabs | 2026-07-30 | Self-serve lead / onboarding form | Country and business email, with email verification required | Public route leads into guided onboarding rather than instant dashboard access |
| Telr | 2026-07-30 | Explicit sales-led onboarding | Contact with sales, business documents, KYC and website review | Integration work can begin during review, but access is not positioned as instant self-serve |
| Paymob | 2026-07-30 | Public route unavailable from test session | Site failed on public load with Cloudflare SSL handshake error | Blocked before any signup evaluation |
What was actually tested
The test was simple: use the public website only, from outside the target market, and follow the most obvious route for a developer or merchant evaluating technical access.
No fake data was submitted. No account was created. If a flow required email verification, phone verification, a captcha or manual intervention, the observation stops at that point and records the blocker.
That makes this an article about public first-contact friction, not about every possible commercial route a provider may offer behind a sales conversation.
Moyasar: local-number requirement appears at registration
Observed 26 July 2026.
Moyasar’s public registration flow required a Saudi mobile number at the point of signup. Accepted
formats included Saudi mobile variants such as 05x, +9665x, 9665x and 009665x.
That matters because the requirement appeared before any test credentials were issued and before the public route exposed enough of the product for meaningful technical evaluation.
This does not prove there is no exception path through support or sales. It does prove that the self-serve route was blocked for a non-resident evaluator at the registration step on the date checked.
Tap Payments: anti-bot protection blocks the public route first
Observed 30 July 2026.
The public Tap site presented a human-verification screen before the main site or any signup path could be reached. The page stated:
Before proceeding to your request, you need to solve a puzzle, and the puzzle requires Google Translate to be disabled.
From the perspective of a first-contact evaluation, that is the first relevant fact. The public path was blocked by an anti-bot gate before any onboarding fields or developer-access route could be inspected.
Again, that does not prove Tap lacks a workable onboarding path. It means the public route was not inspectable from this session without passing the site’s anti-bot challenge.
PayTabs: self-serve form first, but guided onboarding rather than instant sandbox
Observed 30 July 2026.
PayTabs exposes a visible Signup entry from the main site. That route resolves to a hosted
onboarding form on sales.paytabs.com, not directly to a technical dashboard.
The first visible required fields were:
- Country
- Contact Email, preferably Business Email
The page explicitly says email verification is required and advises against using personal email accounts such as Gmail, Hotmail or Yahoo.
The rest of the page positions the flow as guided rather than instant. It says:
Through this digital experience, get connected to the optimum product fit. Then speak to a PayTabs executive to expedite your business growth.
So PayTabs does have a self-serve public intake, but the evidence from the public path points to lead qualification and guided follow-up rather than immediate technical access with test keys on arrival.
Telr: openly sales-led, with documents and KYC up front
Observed 30 July 2026.
Telr’s public Get Started page is unusually candid about its onboarding sequence. The published
steps are:
- Get in touch with Telr
- Telr contacts you to understand the business and propose a fit
- Provide the necessary documents while Telr conducts a KYC process
- Telr reviews the website and its terms and conditions
- The merchant can start integration work while documents and website are under review
- Start accepting payments
That is useful because it settles two questions quickly.
First, Telr is not presenting public technical access as an instant self-serve product. The front door is sales-led and review-heavy.
Second, the site explicitly says integration work can start while documentation and website review are ongoing. That is a meaningful detail for teams trying to shorten the evaluation cycle.
In other words: gated, yes, but not necessarily sequentially gated.
Paymob: the public route failed before any evaluation could begin
Observed 30 July 2026.
In the test session, the public Paymob route redirected to paymob.pk and returned a Cloudflare
525 SSL handshake failed error before any signup or product page could be evaluated.
That is a public-access problem, not an onboarding requirement. But it still matters. If the first-contact experience for an evaluator is an origin-SSL failure, the effective result is the same: no technical evaluation can start from the public path.
This is the kind of friction that rarely appears in vendor comparisons and is exactly why it is worth recording the access path separately from the API itself.
What these routes suggest
Even from a small sample, three patterns are already clear.
1. Gulf onboarding is often sales or compliance shaped before it is developer shaped
PayTabs and Telr both push the evaluator into a guided route before anything resembling a self-serve technical dashboard is visible. That is different from the expectation many developers bring from US or European gateways.
2. Access friction is part of the product
A local-number requirement, an anti-bot gate, or a broken public route are not merely administrative inconveniences. They directly affect how fast a team can evaluate, compare and prototype.
3. “Has APIs” and “is easy to evaluate” are different questions
A provider may have perfectly good APIs and still make early technical evaluation slow. Those are separate traits and should be treated separately in a shortlist.
How to use this if you are choosing providers
At the early stage, the shortlist question is not only “who has the best pricing?” or “whose API looks cleanest?” It is also:
- Which provider can my team evaluate without local operational prerequisites?
- Which provider exposes enough of the route publicly to justify pursuing?
- Which provider requires sales, KYC or manual approval before we can even compare them properly?
That does not mean the easiest public path is always the best production choice. It means public access friction has to be priced into the decision rather than treated as invisible overhead.
What is still unknown
This article deliberately does not claim:
- whether each provider offers a better route through support or enterprise sales
- whether local incorporation is required for go-live in every case
- whether the eventual sandbox or test credentials are generous, restrictive or incomplete
Those need either successful account creation, direct provider confirmation or deeper integration work.
Sources
First-hand observation of public provider routes, checked on the dates listed above.
The observations describe what the public path required or exposed at first contact. They do not describe private commercial conversations, approved merchant onboarding, or credentials issued after verification.