If you're adding eSIM to a travel, banking or mobility app, the first week usually goes to vocabulary. Provider docs mention SM-DP+, LPA, ICCID, EID, matching IDs and profile states as if everyone already knows them. This glossary explains each term in plain language and, more importantly, what it means for your integration: what to store, what to show the customer, and where things tend to break.
The hardware and the "SIM" itself
eUICC
The embedded chip inside the phone that replaces the plastic SIM. Unlike a physical SIM, it can hold several operator profiles at once and download new ones over the air.
For your integration: you never talk to the eUICC directly. The phone's operating system does. Your job is to deliver a profile in a form the OS can install.
Profile
The downloadable "SIM": the operator credentials, network settings and identifiers that used to live on a plastic card. When a customer "buys an eSIM", they're really getting a profile installed on their eUICC.
For your integration: one profile can usually carry many data bundles over time. Banks like N26 and Santander advertise exactly this in their apps: install once, then buy more data for each trip. Design your data model so a customer has one profile and many bundles, not one eSIM per purchase.
EID
The eUICC Identifier, a 32-digit number that identifies the chip itself. Users can find it in their phone's settings. It belongs to the device, not to a plan.
For your integration: you only need the EID if your provider supports device-bound delivery (pushing a profile to a known device) or if support needs to confirm which phone a profile was sent to. Treat it as personal data.
ICCID
The Integrated Circuit Card Identifier, usually 19 or 20 digits and starting with 89. It identifies the profile, the same way the number printed on a plastic SIM did.
For your integration: this is the most important ID you'll store. Link the ICCID to your customer, order and booking. Almost every provider call after purchase (usage, top-up, status, refund) is keyed on it, and it's the first thing a support agent needs.
IMSI and MSISDN
The IMSI is the subscriber identity the mobile network uses internally. The MSISDN is the phone number. Most travel eSIMs are data-only and have no usable phone number, which surprises customers who expect to receive SMS on them.
For your integration: say "data only" clearly at checkout if that's what you sell. It prevents a lot of tickets.
The servers behind provisioning
SM-DP+
Subscription Manager Data Preparation (the "+" marks the consumer version). This is the server that prepares, stores and securely delivers profiles to devices. When an order is placed, a profile is reserved on an SM-DP+ and waits there until the phone downloads it.
For your integration: you rarely run one yourself. Your connectivity provider does. What you get back from an order is the SM-DP+ address and a matching ID, usually combined into an activation code.
SM-DS
Subscription Manager Discovery Server. It lets a phone find a profile waiting for it without the user entering a code, as long as the profile was linked to that device's EID.
For your integration: it's useful for "it just appears" experiences, but support for it varies by provider and device. Most travel flows still rely on activation codes.
GSMA SGP.22 and SGP.32
The GSMA specifications behind all of this. SGP.22 covers consumer devices like phones, tablets and watches. SGP.32 covers IoT devices that have no screen or user. If you sell to travellers, SGP.22 is the one that matters.
On the device
LPA
The Local Profile Assistant: the software on the phone that downloads, installs, enables, disables and deletes profiles. On iPhone and most Android phones, it's built into the system settings ("Add eSIM", "Add mobile plan").
For your integration: the LPA is why your install instructions must be specific to each platform. The menu names, the order of steps and the options for installing from a link or from inside an app differ between iOS and Android, and between OS versions. Check current platform documentation instead of hard-coding screenshots that will go out of date.
Activation code
The string that tells the LPA where to fetch the profile. It usually looks like LPA:1$smdp.example.com$ABCD-1234-EFGH, which breaks down as the format version, the SM-DP+ address, and the matching ID. A QR code is just this string encoded as an image.
For your integration: show both the QR code and the copyable text, plus a one-tap install link where the platform supports it. A customer who opens your email on the same phone they need to scan with can't scan a QR code.
Matching ID
The part of the activation code that identifies one specific order on the SM-DP+. It's effectively a one-time voucher.
For your integration: treat it like a secret. Anyone with the full code can try to download the profile first.
Confirmation code
An optional extra PIN some providers require on top of the activation code. If yours does, deliver it through a separate channel or at least a separate step, and tell the user they'll be asked for it.
Lifecycle terms
Profile states
Providers describe the same journey with slightly different names, but it usually runs: released (ready on the SM-DP+), downloaded, installed, enabled, and later disabled or deleted. Bundles have their own states, such as not started, active, depleted and expired.
For your integration: subscribe to state-change webhooks if your provider offers them, and store the latest state per ICCID. "Was it ever installed?" is the first question in almost every support case, and you should be able to answer it without asking the customer.
Re-download and deletion
With many providers, a profile can be downloaded only once. If the customer deletes it from their phone, the profile may be gone, and a new one has to be issued. Policies vary, so check yours.
For your integration: warn customers inside the app before they remove an eSIM, and build a clear "reissue" path for support agents.
Activation policy
Many travel bundles start counting validity only when the phone first connects to a network in the destination, not at purchase or install. Starling's and N26's public descriptions of their eSIM plans both mention plans activating automatically on arrival.
For your integration: encourage installing before the trip (while the customer has Wi-Fi) and make it clear that the clock starts on arrival. That single message removes a common source of refund requests.
Data roaming and the data line
Because a travel profile's home network is usually not in the destination country, the phone treats it as roaming. If data roaming is off on that line, or the phone is still using the home SIM for data, nothing works.
For your integration: most "it's not connecting" tickets come down to these two settings. Put a three-step check in the app (correct line selected for data, data roaming on for that line, restart if needed) before the "contact support" button.
Top-up
Adding a new bundle to an existing profile. No new QR code, no reinstall.
For your integration: top-ups are where repeat revenue comes from. Trigger the offer from a low-data webhook or usage check, and make it one tap using the customer's saved payment method.
A minimal data model
If you only take one thing from this glossary, store these fields per customer:
- ICCID, with the order and booking it came from
- Profile state and the time it last changed
- Bundles linked to the ICCID, each with its country or region, size, validity, state and remaining data
- The activation code (stored securely) and when it was delivered
- EID, only if your provider uses it
With that in place, support, top-ups and reporting (activation rate, attach rate, revenue per market) all become queries rather than investigations.
Where One-eSIM fits
Disclosure: I work on One-eSIM, a B2B platform that handles the telecom side of this (connectivity supply, provisioning, lifecycle, top-ups, support tooling and analytics) through a white-label storefront or an API, so your team can focus on the customer experience. If you're building eSIM into a travel, mobility or fintech product, the travel, mobility and fintech page explains how that works. I'm happy to answer questions in the comments, including if you're building it all yourself.
Top comments (0)