Currency, Payments & Market Scope — the model and why
This page records how the eSIM store handles pricing, currency, payment methods, and market scope — and why each decision was taken. It exists so nobody re-litigates these from scratch, and so the difference between "what v1 does" and "where we're going" is always explicit.
The model at a glance
| Layer | v1 today (mock stage) | Target |
|---|---|---|
| Catalog | Base USD, destination-priced, synced from the provider | Same — permanent |
| Display | USD, SAR, AED, EUR, GBP, EGP — rates fetched daily into fx_rates (display-only) | More presentment currencies, added deliberately |
| Charge | USD (the store's invoice currency; the local lane stays SAR) | Possibly the customer's presentment currency, via an international-capable PSP |
| Payment methods | Mock gateway | International cards + Apple Pay as the store's core set |
| Market scope | Development only | Saudi + GCC at launch. Wider later, deliberately |
Why the catalog is base-USD
Wholesale eSIM catalogs are priced in USD across the industry. Every major global seller (Airalo, Holafly, Nomad, Saily) runs a single base-currency catalog where price varies by destination, never by the buyer's country. Airalo's own reseller documentation instructs its downstream resellers to keep a USD price list and convert with an admin-adjustable rate — exactly this design. This layer is settled.
How FX rates work
A provider adapter fetches USD rates from the configured source. A scheduled queue refreshes them daily and at startup. Batches are validated against a SAR sanity band of 3.00–4.50 and a leap guard that rejects a majority of tracked currencies moving over 15% from a fresh stored baseline (under 48 hours old). A valid majority move is recoverable once the stored baseline is at least 48 hours stale: the batch is accepted as a controlled rebaseline, emits a high-severity warning, and records its baseline age and jumped currencies in the refresh audit entry. That successful write makes the new batch fresh, so the majority guard applies again on the next refresh. A single-currency jump is accepted with a review warning. Stored rates keep serving if a refresh fails. A staleness warning fires at 48 hours. The health probe exposes the batch age. Raw rates are never exposed publicly. Transient fetch failures retry through the queue.
Payment methods: the store is not the local operator lane
mada and STC Pay exist in this platform for the local operator business. They are not requirements for the eSIM store. This matters because both schemes process only in SAR — importing them as store requirements would force the whole store into SAR processing, which is exactly the local-first coupling the store must not have.
The store's own method set is the international one: cards and Apple Pay, extended by whatever the contracted PSP offers. If the business later wants a mada/STC rail for the Saudi segment, it can be added as an optional extra — those transactions would be SAR by scheme rule, a per-method footnote, never the architecture. (For reference: no major global eSIM seller supports mada — a mada-only customer cannot buy from any of them. Serving that segment is an option this platform uniquely has, when it chooses to.)
Charging: presentment-true, at PSP day
Store orders are charged in USD. The local activation lane stays SAR. The target is the industry norm: charge the customer in the currency they saw. Charging foreign cards in SAR maximizes conversion surprise (the bank's rate plus a foreign-transaction fee lands on the statement) and raises cross-border decline risk.
The PSP filter is: international multi-currency acquiring available to a Saudi-registered entity. Shortlist from research: Checkout.com (150+ presentment currencies, own SAMA license — onboarding terms to verify), PayTabs (documented KSA processing currencies: SAR, USD, EUR, GBP, BHD, OMR, AED), then Telr / Amazon Payment Services. Stripe is not available to KSA entities. If a local rail is ever added, dual-PSP routing is a normal, productized pattern — choosing the international PSP first closes no doors.
Market scope: Saudi + GCC first — and exactly why
Selling to consumers in the EU or UK creates a VAT obligation in the customer's country from the very first sale. There is no minimum threshold for a seller with no establishment there. Rates run 17–27% by country, registration must precede selling, and tax-compliant pricing means the displayed price differs per country.
Neither the eSIM provider nor the PSP carries this duty — the store is the merchant of record, so the obligation is ours wherever we sell. The cheapest, cleanest control is therefore where we sell: at launch, purchases are limited to Saudi + GCC customers. The store proves itself on clean ground. Expansion is a deliberate step with a known price tag, not a default.
The scale path — two recorded options
When international expansion becomes real, two paths are on record:
- Own the compliance: one EU registration (the Non-Union OSS — a single quarterly filing covering all 27 member states) plus a tax-calculation engine, with the UK registered separately. Full control, real ongoing ops.
- Outsource the merchant-of-record — kept deliberately on the table: platforms of the Paddle / Lemon Squeezy class become the legal seller, handling every country's VAT, registration, remittance, and chargebacks for roughly 5%+ per transaction. Less checkout control, and KSA-vendor eligibility must be verified with them directly. A hybrid is explicitly viable: charge KSA/GCC directly, route only the international slice through the MoR.
The choice between them is made at expansion time, against real volume — not now.
Before any real sale, regardless of scope
Two external checks gate real money and have long lead times, so they start early:
- CST licensing: confirmation that reselling foreign-network eSIMs from Saudi Arabia does not require a telecom license. No public ruling exists.
- ZATCA position: how sales for use outside the Kingdom are treated (the "use and enjoyment" rule may place them outside Saudi VAT entirely), and whether the deemed-supplier marketplace rules apply to the store's domestic leg.
Decision log
| Date | Decision | Why |
|---|---|---|
| 2026-08-05 | Base-USD catalog stays permanently | Industry-validated; matches wholesale reality |
| 2026-08-05 | Store's payment set = international (cards + Apple Pay); mada/STC are local-lane rails, not store requirements | The store must not inherit local-first coupling; local rail stays an optional future add-on |
| 2026-08-05 | Target charging = customer's presentment currency (presentment-true) | Industry norm; SAR-charging foreign cards maximizes FX surprise and declines |
| 2026-08-05 | SAR-only charging in v1 = mock stand-in only, not a commitment | Real PSP not chosen; schema already snapshots presentment/charge/rate separately |
| 2026-08-05 | Launch scope = Saudi + GCC, geo-limited at purchase | EU/UK VAT liability starts at sale #1 with no threshold; sell where clean, widen deliberately |
| 2026-08-05 | Merchant-of-Record outsourcing recorded as a first-class expansion option | The one arrangement where global VAT is genuinely handled for us; decide at expansion time |
| 2026-08-11 | Store charges USD. Admin FX dial replaced by fetched provider rates | The admin-set dial was removed when multiple presentment currencies were introduced. Rates are now fetched daily from the configured provider and validated with sanity bands and jump guards. |
| 2026-08-18 | A stored FX baseline at least 48 hours stale may rebaseline a valid majority move | Legitimate market-wide moves must recover deterministically without weakening fresh-baseline corruption protection; the warning and audit metadata make the exception reviewable |