"Does my phone support eSIM?" is one of the most common questions a travel or fintech app gets right before checkout, and one of the most expensive to get wrong. A customer who buys a plan for a phone that can't take it doesn't just ask for a refund. They open a ticket, wait, and usually leave with a worse opinion of your brand than if they'd never bought anything.

The frustrating part for engineers is that there's no clean "supports eSIM: yes/no" signal you can read everywhere. This post covers what you can and can't detect on the web and in native apps, how to keep a device allow-list honest, and how to write checkout copy for the customers who simply don't know.

1. On the web, you can't really detect it

There is no browser API that tells you whether a device has an eUICC (the embedded chip that holds eSIM profiles). What you get is indirect at best:

  • User-Agent strings. iPhones report "iPhone" without the model, so you can't tell an eSIM-capable iPhone from an older one. Many Android browsers have also reduced the model information in the default User-Agent.
  • User-Agent Client Hints. On Chromium-based Android browsers you can request the high-entropy model hint, which may return a model identifier such as a Samsung or Pixel model code. It isn't available in Safari or Firefox, and a model code still doesn't tell you about regional variants.
  • The customer is often on a different device. Plenty of people buy a travel eSIM on a laptop for the phone in their pocket. Any detection you run in that browser describes the wrong device.

So on the web, treat detection as a hint for pre-filling a question, never as a gate. The reliable path is to ask the customer, help them check, and make the answer easy to give.

2. Native apps get better signals, but not the whole story

If you have a native app, you can do more, but the public APIs are narrower than many teams expect.

  • Android. EuiccManager.isEnabled() (Android 9 and later) tells you whether the eUICC is available on the device. That's a useful signal. Reading the EID itself with getEid() needs privileged phone-state permission or carrier privileges, so an ordinary third-party app usually can't read it. Downloading profiles directly from your app also needs carrier privileges, which is why most non-carrier apps hand off to system settings or an activation link instead.
  • iOS. CoreTelephony has CTCellularPlanProvisioning, but in-app plan installation is gated behind a carrier entitlement that Apple grants case by case. Without it, most apps rely on Apple's eSIM setup link or a QR code. Check Apple's current documentation for which checks are available to your app without that entitlement before you design around them.
  • Neither platform tells you about carrier locks. A phone can have a working eUICC and still refuse a profile from a different provider because it's locked to its original operator. You generally can't detect this from an app.

The practical takeaway: in a native app, you can usually confirm "this device has an eSIM chip" on Android, and narrow things down on iOS. You still can't confirm "this specific profile will install and connect".

3. Let the customer prove it in ten seconds

The most reliable compatibility check is often one the customer does themselves, as long as you make it fast:

  • Dial *#06#. On many eSIM-capable phones, this shows an EID alongside the IMEI. If there's an EID, the phone has an eUICC.
  • Look in settings. On iPhone, an "Add eSIM" option under Settings and then Cellular (or Mobile Data) is a strong sign. On Android, the equivalent usually lives under the SIM or network settings, though menu names vary by manufacturer.
  • Capture the answer. Store "customer confirmed EID present" or "customer selected model X" with the order. When a ticket comes in later, support doesn't have to start from zero.

If you do get an EID (typed by the customer or read by a privileged app), keep it with the order. It identifies the eUICC, helps your supplier trace a stuck profile, and tells support immediately that compatibility wasn't the problem.

4. Maintain a device allow-list, and treat it as data

Most teams end up with a list of supported models. It works if you treat it as living data, not a page someone wrote once:

  • Key it by model and region, not just marketing name. The same phone name can ship in regional variants that differ on eSIM support. Some markets have models without eSIM at all.
  • Source it from more than one place. Manufacturer spec pages, your supplier's compatibility list and your own activation data. When a model shows repeated "installed but can't connect" or "can't add eSIM" tickets, review its entry.
  • Version it. Store which version of the list a customer saw at checkout. When someone disputes a refund, you can see what you told them.
  • Expose it as an API, not only a web page. Your checkout, your app and your support tooling should read the same list. Three copies drift apart within a quarter.

5. Write the "not sure" path on purpose

Some customers won't know their model, won't dial a code and won't open settings. Design for them instead of hoping they don't exist:

  • Add a visible "Not sure if your phone supports eSIM?" link right at plan selection, opening a short check (the dial code, the settings path, and a model search box).
  • Say the carrier-lock caveat in plain words: "Your phone also needs to be unlocked. If you bought it from a carrier on contract, check with them first."
  • Make the refund rule clear before payment, for example that an eSIM which hasn't been installed can be refunded. Customers who trust the refund path are less likely to open a ticket in a panic.
  • Don't block checkout on an unknown answer. Let them continue, but flag the order so you can send an extra check before travel.

6. Why this matters for support load

Compatibility problems are some of the cheapest activation failures to prevent and some of the most expensive to fix afterwards. Once a customer is at the airport with a plan their phone can't use, your options are a refund and an apology. Before checkout, it's a ten-second question.

A good setup usually looks like this: a hint from the browser or app pre-fills the model, the customer confirms it with a quick check, the allow-list makes the call, the answer is stored with the order, and anything uncertain gets a reminder before the trip. Track compatibility-related tickets as their own category so you can see whether changes to the flow actually reduce them.

About One-eSIM

I work on One-eSIM, a B2B platform that lets travel, fintech and telecom brands launch their own branded eSIM through a white-label webshop or an API embed, with a management portal and support tooling behind it. If you're designing checkout and activation flows like the one above, you can see how the pieces fit on our partner solutions page or at 1-esim.com.