The Call at 3 AM (iWanteSIM)
It was 3:14 AM when PagerDuty lit up my phone. A traveler had just landed in Nairobi, bought an eSIM data plan through our platform, and… nothing. No activation. No data. Just a spinning icon and a growing sense of panic as they stood in Jomo Kenyatta International Airport with no way to call their ride.
The Call at 3 AM
That was the first of what would become thousands of similar tickets over the next eighteen months. By the time we stabilized things, I had personally debugged eSIM activation failures in 200+ countries and territories — from Andorra to Zimbabwe, from the urban canyons of Tokyo to a remote village in the Peruvian Andes.
This is the story of what broke, how we fixed it, and what I wish someone had told me before I started.
The Stack We Were Working With
The Stack We Were Working With
Before diving into the failures, here's the landscape. Our platform aggregated eSIM plans from multiple providers — think Airalo, Holafly, Nomad, and a handful of regional carriers. The flow looked deceptively simple:
- User buys a plan → we generate an eSIM profile via the provider's API
- User receives a QR code or activation code
- User scans/enters it on their device
- The device talks to the carrier's SM-DP+ (Subscription Manager Data Preparation) server
- Profile downloads → device provisions → data flows
Four steps that should take 30 seconds. In practice? Sometimes 30 minutes. Sometimes never. And when you're serving travelers who just stepped off a 14-hour flight, "never" is not an acceptable answer.
Failure Category 1: Carrier Provisioning Errors (38% of failures)
This was our biggest bucket, and the most frustrating because it was almost entirely outside our control.
The Symptom
User scans the QR code. The phone says "Activating…" for 2-3 minutes. Then: "Unable to activate eSIM. Contact your carrier."
What Was Actually Happening
The provider's API returned a successful response — profile created, QR code generated, everything looked green on our dashboard. But behind the scenes, the profile hadn't actually been provisioned on the carrier's SM-DP+ server. The API said "done" before the backend was ready.
This was especially bad with smaller regional carriers in Southeast Asia and Africa. Their provisioning pipelines had race conditions: the API endpoint would accept the request, queue it for processing, and return 200 OK immediately. But the actual provisioning could take anywhere from 30 seconds to 15 minutes. If the user scanned the QR code before provisioning completed, the SM-DP+ server would reject the activation with a cryptic 8.1.2.3 error code.
The Fix
We built a provisioning readiness check — a polling mechanism that would query the SM-DP+ server directly after profile creation and only release the QR code to the user once the profile was confirmed downloadable. For providers that didn't expose a readiness endpoint, we implemented an exponential backoff: wait 30 seconds, poll, wait 60 seconds, poll, up to 5 minutes. If still not ready, we'd flag it for manual review and offer the user a refund or alternative plan.
This single change dropped our provisioning-related failures from 38% to under 4%.
Failure Category 2: Device Compatibility Surprises (22% of failures)
"eSIM compatible" is not a binary state. It's a spectrum, and the edges are sharp.
The Chinese Market Phone Problem
Chinese-market iPhones (models sold in mainland China, Hong Kong, and Macau) have eSIM hardware but no eSIM software support. Apple disables it at the OS level for regulatory reasons. We learned this the hard way when a wave of Chinese tourists buying plans for their trips to Europe all failed simultaneously.
The Samsung Region Lock
Certain Samsung models sold in Latin America and the Middle East have eSIM functionality that's region-locked at the firmware level. A Galaxy S23 bought in Brazil might work fine with a Brazilian eSIM but reject a European travel eSIM outright. The error messages were spectacularly unhelpful: "SIM card not supported" — which made users think the problem was with our service, not their device.
The Dual-SIM Conflict
Many users kept their physical SIM active while trying to activate an eSIM. On some devices (particularly Google Pixels and OnePlus phones running certain Android builds), having an active physical SIM would block eSIM profile downloads entirely. The modem firmware would refuse to initialize a second SIM profile while the first was in an active data session.
Check out our eSIM plans.### The Fix
We built a device compatibility pre-check into the purchase flow. Before allowing a user to buy, we'd ask for their device model and run it against a database we maintained of known compatibility issues. For Chinese-market iPhones, we'd show a clear warning before purchase. For Samsung region-lock issues, we'd flag the specific model numbers. For dual-SIM conflicts, we added a step in the activation guide: "Temporarily disable your physical SIM during eSIM activation."
We also open-sourced our compatibility database as a public JSON endpoint. Other travel-tech companies started using it, and the community contributions (especially from users in markets we didn't have direct access to) made it far more comprehensive than we could have built alone.
Failure Category 3: Network Timeouts and SM-DP+ Unreachability (18% of failures)
This one was geography-dependent in ways I never anticipated.
The Great Firewall Problem
Some carriers host their SM-DP+ servers in data centers that are unreachable from certain countries due to internet routing policies. A traveler in mainland China trying to activate a European eSIM would see timeouts because the SM-DP+ server was hosted in a blocked IP range. The same profile would activate perfectly from Hong Kong or Singapore.
The Satellite Backhaul Issue
In remote areas — think Pacific islands, parts of central Africa, rural Mongolia — internet connectivity goes through satellite backhaul with 600-800ms latency. The GSMA spec for eSIM activation (SGP.22) has a default timeout of 90 seconds for the profile download. On a satellite connection with packet loss, that's often not enough. The download would fail mid-way, and the partial profile would leave the eSIM in a corrupted state that required a full reset.
The Fix
We implemented geo-aware SM-DP+ routing. For each provider, we mapped which SM-DP+ servers were reachable from which regions. When a user initiated activation, we'd detect their approximate location (via IP or device-reported country code) and route them to the nearest reachable SM-DP+ endpoint.
For the timeout problem, we worked with providers to increase the profile download timeout window and added a resumable download mechanism — if a download failed at 60%, the next attempt would resume from that point rather than starting over. This required changes on the provider side, which took months of negotiation, but it was worth it.
Failure Category 4: The Human Factor (12% of failures)
Not all failures were technical. A surprising number came down to user error — but that's still our problem to solve.
QR Code Confusion
Users would screenshot the QR code, then try to scan the screenshot from the same phone. (You can't scan a QR code displayed on your own screen with your own camera.) Others would print the QR code on low-quality printers where the pattern became unreadable.
The Wi-Fi Paradox
eSIM activation requires an internet connection to download the profile. But many users were trying to activate their travel eSIM after leaving their hotel Wi-Fi — at the airport, on the road, with no connectivity. They'd disabled their home SIM to avoid roaming charges, leaving the phone with no data connection at all. No connection = no profile download = no eSIM.
The Fix
We redesigned the activation flow to be foolproof by default:
Instead of just a QR code, we added a one-tap "Install eSIM" button that used the device's native eSIM installation API (where supported)
We added a pre-activation checklist: "Are you on Wi-Fi? Is your physical SIM temporarily disabled? Is your phone charged above 20%?"
We embedded a short animated guide showing exactly what to do, localized into 12 languages
For the Wi-Fi paradox, we partnered with airports to offer free 15-minute activation Wi-Fi passes at major international hubs
Failure Category 5: Provider API Quirks (10% of failures)
Every eSIM provider's API had its own personality. Some were well-documented REST APIs with proper error handling. Others were… not.
The Silent Failure
One major provider's API would return HTTP 200 with a valid-looking QR code even when the underlying profile creation had failed due to insufficient inventory. The only way to detect the failure was to parse a specific field deep in the response JSON — a field that wasn't documented and only appeared when things went wrong. We discovered this after 47 users received QR codes that led to dead profiles.
The Rate Limit Roulette
Another provider had aggressive rate limiting that wasn't documented anywhere. During peak travel seasons (December holidays, summer in Europe), their API would silently throttle requests. Our system would retry, hit the limit harder, and get throttled more aggressively — a classic death spiral.
The Fix
We built a provider abstraction layer with per-provider validation rules, retry policies, and circuit breakers. Each provider integration got its own:
Response validation: Custom validators that checked not just HTTP status codes but the semantic validity of the response (does the profile actually exist on the SM-DP+ server?)
Adaptive rate limiting: Token bucket per provider with automatic backoff when we detected throttling
Dead letter queue: Failed activations went into a queue for automatic retry with exponential backoff (1min, 5min, 15min, 1hr) before alerting a human
Provider health dashboard: Real-time monitoring of success rates, latency, and error patterns per provider per region
The Numbers That Matter
When I started, our eSIM activation success rate was 77%. That means nearly 1 in 4 users who paid for a plan couldn't use it. Every one of those failures meant a support ticket, a frustrated traveler, and often a refund.
You might also find our eSIM plans useful.After eighteen months of systematic debugging and the fixes described above:
Overall success rate: 99.7%
Average activation time: Down from 4.2 minutes to 47 seconds
Support tickets related to activation: Down 94%
Refund rate: Down from 8.3% to 0.4%
Provider API reliability: We now track per-provider SLAs and automatically deprioritize providers that fall below 98% success rate
What I Learned (The Hard Way)
Lesson 1: Trust Nothing, Verify Everything
An API returning 200 OK means nothing. A QR code being generated means nothing. The only thing that matters is: did the profile actually land on the device? Build your monitoring around that single question. Everything else is noise.
Lesson 2: Geography Is a First-Class Concern
You can't test eSIM activation from your office in San Francisco and assume it works in Lagos, Lahore, or La Paz. Network topology, carrier infrastructure, internet routing policies, and even device firmware vary dramatically by region. If you're building a global product, you need global testing — or at least a way to simulate it.
Lesson 3: The User Is Always Right About Their Problem
When a user says "your eSIM doesn't work," they're right. It doesn't work for them. Maybe the technical fault is on the carrier side, or their device, or their network. But the experience of failure is real, and it's your responsibility to either fix it or make the path to resolution so smooth that they don't remember the failure — they remember how well you handled it.
Lesson 4: Automate the Detection Before the Fix
For the first six months, we were fixing problems reactively — a user would complain, we'd investigate, we'd patch. This doesn't scale. The turning point was when we invested in proactive monitoring: SM-DP+ reachability checks from multiple geographic regions every 5 minutes, provider API health checks, and automated alerts when any metric dipped below threshold. Once we could see failures before users reported them, everything changed.
Lesson 5: Document the Weird Stuff
That undocumented field in the provider's JSON response? The Chinese-market iPhone quirk? The Samsung firmware region lock? Write it down. Better yet, make it machine-readable. Our device compatibility database started as a shared Google Doc and evolved into a public API. The weird edge cases you discover today will save someone (probably future you) weeks of debugging tomorrow.
Lesson 6: Build for Degradation, Not Perfection
In 200+ countries, something is always broken somewhere. A carrier's SM-DP+ server is down in Southeast Asia. A provider's API is throttled during European summer. A submarine cable cut is causing 2-second latency to Oceania. Your system needs to degrade gracefully: fall back to alternative providers, queue for retry, offer manual activation paths. Perfection is impossible at this scale; resilience is mandatory.
The Unexpected Upside
Here's something I didn't expect: the failures made our product better in ways that success never could have. Every activation failure was a signal — about carrier infrastructure, about device behavior, about user expectations. Aggregated across 200+ countries, those signals painted a map of global connectivity that no single carrier or device manufacturer has.
We started publishing anonymized reliability reports by country and provider. Travelers used them to decide which eSIM to buy. Carriers used them to identify infrastructure gaps. Device manufacturers reached out to understand compatibility issues. What started as a firefighting exercise became a data product in its own right.
Closing Thoughts
If you're building something that operates at global scale — whether it's eSIMs, payments, messaging, or anything else that crosses borders — expect the unexpected. The internet is not a uniform utility. It's a patchwork of policies, infrastructure, and hardware that behaves differently in every corner of the world.
The difference between a 77% success rate and 99.7% wasn't one big fix. It was hundreds of small ones — each discovered through a user's frustration, each validated across dozens of countries, each deployed with the humility of knowing that somewhere, in some airport at 3 AM, someone was counting on it to work.
And when it does work? When a traveler lands in a new country and their phone just… connects? That's the magic. That's why we do this.
Have you dealt with eSIM activation issues or global-scale connectivity challenges? I'd love to hear your war stories in the comments. And if you're building something that needs to work everywhere, reach out — I have a database of edge cases I'm happy to share.
Top comments (0)