Travel eSIM Providers and eSIM Adapter Cards: Compatibility Reference

Short answer: most travel eSIM providers work with an eUICC adapter card, because most of them give you either a QR code or a manual SM-DP+ address and activation code — and that's all an adapter needs. The exceptions are providers that only install through their own app, and carrier eSIMs that provision through a carrier app. Those cannot reach an adapter card at all, and no amount of troubleshooting will change it.

Before you buy any plan, find the provider's manual install details. If you can see an SM-DP+ address and an activation code, you have a path. If the only option is a button in their app that says "Install," you don't.

Disclosure: Switch eSIM sells eUICC adapter cards. The compatibility results below are for our card specifically, and results do not transfer between adapter brands — the reason why is explained in the method section. Where we have not tested, we say so.

How to tell before you buy

Three checks, in order. The first takes thirty seconds and rules out most problems.

Check 1 — Is a QR code or manual code available?

Look in the provider's help centre, or in the confirmation email, for any of: "QR code," "manual installation," "SM-DP+ address," "activation code," "LPA string." A QR code for eSIM installation is just a text string beginning LPA:1$ followed by the SM-DP+ address and the activation token. If you can get that string, an adapter app can consume it.

Airalo documents all three routes explicitly, including "Enter Details Manually" with SM-DP+ Address and Activation Code fields. That's the pattern to look for.

Check 2 — Is the profile pinned to a device or an EID?

Rare among travel providers, common among home carriers. If a provider issues a profile pre-assigned to a specific EID, it will not install on a different eUICC — and your adapter has its own EID, not your phone's. Ask before buying: "Is this profile locked to a specific device or EID?"

Check 3 — Will the provider support you if it doesn't work?

This is the one that costs money. Every major provider conditions support and refunds on device compatibility. Airalo's requirements are that the device supports eSIM, is not carrier-locked, and is not jailbroken or rooted, and it publishes a compatibility list — noting that "some regional models may not support eSIMs." A phone with no native eSIM, using an adapter, is not on any provider's compatibility list. That doesn't mean the profile won't work. It does mean a refund claim can be declined on compatibility grounds.

Practical consequence: buy a small, cheap plan from a new provider first. Don't discover this on a 30-day 50GB purchase. (Refund-policy specifics vary and change — verify current terms before quoting them to a customer.)

The compatibility table

How to read this. Columns are the three independent tests described in the method section. Every cell carries an evidence tier:

P — Primary: provider's own documentation, checked and dated
S — Secondary: vendor blog, review site, or community report
U — Untested / unverified by us

Rows marked U in the "Installs on card" column have not been tested on our hardware. They are structural predictions from the install method available, not results. Treat them as a shortlist for your own testing, not as findings.

Provider	QR / manual code available?	Installs on our card	Survives switching & device move	Reinstall after delete?	Notes
Airalo	✅ QR + manual SM-DP+/activation code, plus Direct (P)	U	U	Provider-side; contact support before deleting (S)	Use QR or Manual, not Direct. Direct targets the system LPA. Airalo's own docs note install instructions may disappear from the app once it detects installation — screenshot the manual details first (P)
Holafly	✅ QR-code led; SM-DP+ and activation code issued after purchase (S)	U	U	Profile deletion doesn't cancel the plan; usually reinstallable, support can reissue (S)	[VERIFY against Holafly's own help centre — sourced from a competitor's blog, which is not acceptable for a citation asset]
Saily	⚠️ App-led install is the documented path (S)	U	U	Refund via app / Refund Center (S)	Highest-risk row. If app-only, structurally incompatible. [VERIFY whether a QR/manual fallback exists on request]
Nomad	[VERIFY]	U	U	[VERIFY]
Ubigi	[VERIFY — both app and QR paths believed available]	U	U	[VERIFY]
aloSIM	[VERIFY]	U	U	[VERIFY]
Jetpac / Yesim / Maya / GigSky / Roamless	[VERIFY each]	U	U	[VERIFY]	Batch these into one doc-check pass
Orange Travel	✅ QR activation (S)	U	U	[VERIFY]	Voice + SMS + real French number, unlike the data-only majority (S) — relevant if the reader needs SMS 2FA
1Global / BNESIM / Flexiroam	[VERIFY]	U	U	[VERIFY]
Google Fi	❌ Provisions through the Fi app (U — verify)	❌ predicted	—	—	Carrier-app provisioning cannot target a third-party eUICC
US postpaid carrier eSIMs (T-Mobile, Verizon, AT&T)	❌ Typically carrier app or in-store (U — verify)	❌ predicted	—	—	Also frequently EID- or device-bound
Home carrier eSIM conversion (most countries)	⚠️ Varies — many will issue a QR on request (U)	U	U	Usually one-shot; reissue needs a carrier request	Worth asking. Some carriers issue a standard QR happily

What this table already tells you, before any testing: the split is not provider-by-provider goodwill. It is architectural. Travel eSIM resellers overwhelmingly issue standard GSMA activation codes because they have to support hundreds of device models they don't control. Home carriers and carrier-app ecosystems don't, because they control the device relationship. Travel providers are the compatible category. Carrier eSIMs are the incompatible one. That generalisation will outlive every individual row.

The ones that don't work, and why

Carrier-app-only provisioning. Google Fi and most US postpaid carrier eSIMs provision through their own app talking to the platform's eUICC APIs. AOSP is explicit that carrier apps operate on profiles their carrier owns, with privileges granted in the profile metadata — "carrier A should not be able to download, enable, or disable a profile owned by carrier B." There's no user-facing activation code to redirect at an adapter. This is a design decision, not a bug, and it will not be worked around.

Providers whose only install path is in-app Direct. Same outcome, different cause: the app calls the system LPA, the system LPA doesn't know about the adapter, the profile goes to the built-in eSIM or nowhere.

Carrier-locked phones. A carrier-locked device blocks third-party profiles regardless of adapter. AOSP has dedicated error codes for it: ERROR_CARRIER_LOCKED on both download and switch. Unlock first; nothing else here helps.

Profiles carrying restrictive Profile Policy Rules. The genuine, under-documented failure mode. If a profile declares policy rules our card's Rules Authorization Table won't accept, installation fails with ERROR_DISALLOWED_BY_PPR. This is the specific case where results differ between adapter brands, and it's why this table has to be built on our own hardware.

Card memory exhausted. ERROR_EUICC_INSUFFICIENT_MEMORY. Storage is finite — eSIM.me markets up to 15 profiles per V2 card, tier-dependent; other vendors differ. Profile count is not unlimited on any card. [Insert our card's actual figure — see open questions.]

Per-provider install notes

The universal sequence, whatever the provider: buy the plan → retrieve the QR code or manual SM-DP+ and activation code → screenshot and save it somewhere offline → install via the adapter's app, not the phone's Settings → enable → verify data before you travel.

Two things that will bite you regardless of provider:

Save the activation details before installing. Most eSIM activation codes are single-use. Providers document "Plan already in use" errors when a code is rescanned. And Airalo notes the install instructions may vanish from its app once installation is detected — so screenshot first, not later.

Do your profile downloading on Wi-Fi, at home. Adapter profile management is the weak point here. One review of eSIM.me lists "dependence on WiFi for profile changes when traveling" as a specific drawback. Downloading a new profile mid-trip, with no working data because the profile you need is the download, is the classic adapter trap. Load every profile you'll need before departure. With storage for multiple profiles, you can — and that is genuinely the adapter's best argument.

A hardware-specific warning worth carrying over. eSIM.me warns users of Samsung One UI 6.1 not to disable the SIM slot containing the card: doing so "will disable all SIM slots and a factory reset will be necessary." Whether our card shares this exposure is unknown and needs testing on Samsung specifically. This is exactly the class of finding that makes a page like this get cited.

Also flag for the reader: some adapter platforms require identity verification (KYC) in-app before the card can be used, and some tie the licence to a device with a paid transfer to move it. Both are real friction points a buyer should know about pre-purchase. [Confirm our card's position on both — see open questions.]

How to test a new provider yourself

Publishing the method is what makes the results credible, and it's useful to readers whether or not they buy from us.

Buy the smallest available plan. A 1GB / 7-day package is enough and limits the loss.
Record the install methods offered. Direct only? QR? Manual SM-DP+ and activation code? Screenshot all of it.
Note the EID your adapter reports before installing.
Install via the adapter's app on Wi-Fi. Record the exact error text if it fails — the AOSP error codes are diagnostic. ERROR_DISALLOWED_BY_PPR means policy rules. ERROR_UNSUPPORTED_VERSION means eUICC OS mismatch. ERROR_CARRIER_LOCKED means the phone, not the plan.
Enable and confirm data. Load a page. Check the provider's app shows usage.
Test survival: disable the profile, enable another, switch back. Does it reconnect without re-installation?
Test portability: move the card to a second phone. Does the enabled profile still work? (Note that enabling, disabling and deleting profiles generally requires the adapter's app and a supported device, even though an already-enabled profile may work in any phone with a SIM slot.)
Record the date and your OS version. Both matter. Results decay.

Steps 6 and 7 are the ones no existing guide performs, and they're where an adapter either earns its price or doesn't.

Limitations

The compatibility column is untested. Everything marked U is a structural prediction. We have not run the tests. The page will be re-versioned when we have.
Results are card-specific. PPR/RAT and eUICC OS version differ between adapter products. Our results won't transfer to 5ber or eSIM.me, and theirs don't transfer to us.
Several rows are sourced from competitors' blogs, which is not good enough for a page meant to be cited. Marked [VERIFY].
Refund and support policies change and are summarised loosely here. Check current terms.
Adapter cards are Android-only per our earlier finding — carried forward, not independently re-verified in this pass.
Provider install methods change without notice. Any provider can add or remove a QR option in a release. Hence per-row dating.

Testing status

Not yet tested. Proposed sprint, two weeks:

Phase 1 (2 days): documentation audit of all 15 providers — confirm QR/manual availability from each provider's own help centre. Converts every [VERIFY] in column 1 to P. This alone makes the page defensible and is the cheapest work on the list.

Phase 2 (5 days): install testing, top 8 providers by search volume, on two devices — one Android with no native eSIM, one with. Records install success, exact error strings, and connection.

Phase 3 (3 days): survival and portability — steps 6 and 7 above. The differentiating data.

Phase 4 (ongoing): quarterly re-test, dated per row.

Sources: Airalo Help Centre — iOS/Android/Samsung install articles, device compatibility, "What devices support eSIM?" (May 2026) · AOSP — eSIM error handling, eSIM MEP, eUICC API, Implement eSIM · GSMA SGP.22 / SGP.29 · eSIM.me FAQ and product pages · Qualcomm Telux ISimProfileManager docs · Apple Support 102478 · secondary: Holafly, Saily, mybestsim, CSL Group, emnify

Learn more: