Trust centre
Every promise here has a number and a way to check it.
Search any large travel eSIM brand and the autocomplete offers you the word scam. That is the market we sell into, so trust is not a values slide here. It is the product.
The targets, and what happens when we miss
| What we measure | Target | What happens when we miss it |
|---|---|---|
| Provisioning success | 99.5 percent of paid orders | Automatic refund inside 60 seconds, no ticket |
| Incident notification | Affected customers told before they notice | Credit applied without a request, and named in the post mortem |
| Post mortem publication | Within 72 hours for anything over 30 minutes | The delay itself is published, with the reason |
| Price drop protection | 30 days from purchase | The difference is credited to the wallet automatically |
Each row states a target we can miss. A target nobody can miss is decoration.
Why the target is not one hundred percent
Because one hundred percent is a lie in any system with a network in it, and a target nobody can miss is a target nobody manages.
Publishing 99.5 percent is an admission that in every thousand orders, roughly five will fail somewhere between the payment and the profile. The useful question is what happens to those five people.
The answer is that the refund fires before they have finished being annoyed. The system detects the failure, reverses the charge inside 60 seconds, and sends a message explaining what happened and what to do instead.
The customer does not open a ticket. Nobody has to decide whether they deserve it. That path is engineered with the same care as the happy one, because it is the path that generates every review we will ever be judged on.
Incident policy
The uncomfortable part is the second step. Moving the status page before we know the cause means publishing our own bad news while it is still confusing, and it means a journalist can quote a timestamp back at us.
We do it because the alternative is a customer in an airport discovering the outage themselves, which is how a technical problem becomes a reputational one.
- Detection, mostly automated, from provisioning success rates rather than from a person noticing
- The status page component moves within five minutes of the incident being declared, before we know the cause
- Affected customers are identified and contacted, with a credit already applied where service was degraded
- An incident commander runs the response and a separate person handles communications, so neither job starves the other
- Anything over 30 minutes gets a written post mortem published within 72 hours
- The post mortem names systems and decisions rather than individual employees, and every fix carries an owner and a date
The transparency commitments
Every one of these can be checked without our help, and none of them need an account. Open a plan in the store and look for the throttle number. Open the pricing page and look for the per gigabyte rate next to the plan you are about to buy.
If any of those checks fails, the commitment is broken, and we would rather hear about it from you than not at all.
- We publish the throttle threshold as a number, on the buy button, on every plan
- We publish a post mortem for every incident over 30 minutes, within 72 hours
- We tell affected customers before they discover a problem themselves
- We publish a transparency report twice a year, including when every number in it is zero
- We refuse the sale in territories our partners cannot serve rather than refunding later
Where to check each thing yourself
| Page | What is on it | What it lets you verify |
|---|---|---|
| Status | Live component state, incident history, every post mortem | That we publish our own bad news on time |
| Security | Passwordless sign in, passkeys, sessions, disclosure contact | That no card data sits on our systems |
| Privacy policy | What we collect, where it lives, your rights | How your personal data is handled |
| Transparency report | Law enforcement requests, data requests, deletions | That we publish at zero rather than only when it suits |
| Accessibility | The standard we target and the pages it covers | That the statement names a standard rather than showing a badge |
| Refund policy | The automatic refund rule and the fair use number | That the plain language summary matches the terms |
Nothing in this table needs our permission or our help. That is the test of whether a trust page means anything.