How Pexx built a white-label travel eSIM product on top of the Firsty API

In May 2026, Pexx launched a white-label travel eSIM product inside their cryptowallet app. Loyal Pexx users earn free data as a reward for creating accounts and transacting. The integration uses Firsty's API end to end.

This case study covers what Pexx built, why they chose API integration over a simpler webapp, and what we learned about embedding connectivity inside a non-telco product.

The problem Pexx solved

Pexx users are crypto-native: they hold and transact digital assets. Many travel internationally. The travel use cases for crypto wallets are real:

• Paying for things abroad without traditional banking fees
• Managing assets across timezones
• Receiving payments while moving between countries

But when Pexx users travel, they hit the same wall everyone else does: international roaming is expensive, public WiFi is unsafe for sensitive financial operations, and local SIM cards mean losing your primary number.

Pexx wanted to solve this in a way that also strengthened their core product: rewarding the behaviors they want users to do (creating accounts, completing transactions). Free data became the carrot.

What they built

Inside the Pexx app, users see a "free data" section that shows their data balance. The balance grows when users complete qualifying actions:

• Creating an account: starting data balance
• Completing first transaction: additional data
• Reaching transaction milestones: bonus data
• Holding certain asset values: ongoing data allocation

When the user is ready to travel, they tap "activate eSIM" and get a Pexx-branded QR code to install on their phone. The eSIM is white-labeled: customers see Pexx branding, not Firsty.

The technical flow on Pexx's side:

1. User completes a qualifying action in the Pexx app
2. Pexx's backend awards data to the user's account (internal balance)
3. When the user is ready to use the eSIM, Pexx calls Firsty's API to provision it
4. Pexx attaches a data package matching the user's earned balance
5. Pexx returns the LPA QR code to the user
6. User installs the eSIM and travels

The data balance is stored in Pexx's database, decoupled from the actual eSIM. This lets Pexx control the loyalty mechanics independently from the connectivity layer.

Why API integration (not webapp)

Pexx considered the webapp approach (the Belfius pattern) but chose API integration for three reasons:

1. Deep loyalty integration: the free data is tied to specific user actions inside the Pexx product. A webapp couldn't access this state cleanly. Direct API integration lets Pexx control exactly how much data each user gets based on their behavior.

2. White-label experience: Pexx wanted users to never see "Firsty" branding. The webapp option is co-branded, which would have introduced friction. API integration meant Pexx could render the entire experience natively in their app.

3. Data and analytics: Pexx tracks user behavior closely. They wanted eSIM activation and data usage as first-class events in their analytics. Webhook-driven API integration delivers those events directly to Pexx's pipeline.

The trade-off was engineering effort. Webapp = link integration in hours. API integration = weeks of work. Pexx had the engineering capacity and decided the deeper integration was worth it.

Integration timeline

Pexx's integration took about 10 weeks from initial decision to public launch:

• Weeks 1-2: Architecture design, eSIM data flow specification, agreement on loyalty mechanics
• Weeks 3-5: Firsty API integration (auth, eSIM provisioning, package ordering, webhook handler)
• Weeks 6-7: Pexx-side UI for the eSIM section, loyalty balance display, activation flow
• Week 8: Internal testing with Pexx employees
• Week 9: Beta testing with a select group of power users
• Week 10: Public launch

The Firsty API integration itself was about 3 weeks of one engineer's work. The remaining time was UI, business logic, and internal review.

Technical decisions worth highlighting

Webhook-driven state: Pexx doesn't poll our API for eSIM status. They rely on Firsty webhooks (esim.installed, package.activated, package.usage) to update their internal state. This means real-time accuracy with no rate-limit concerns.

Pre-provisioning: For high-engagement users who travel frequently, Pexx pre-provisions eSIMs before the user explicitly requests them. The eSIM is ready, but the package isn't attached until activation. This shortens activation time from "provisioning happens now" to "package attaches now," which feels instant to the user.

Two-step provisioning patterns: by separating eSIM creation from package ordering, Pexx can pre-provision eSIMs for popular destinations and attach packages dynamically based on user choice. This wouldn't be possible with bundled APIs.

Idempotency keys: every provisioning call from Pexx includes a deterministic idempotency key (combining user ID and action timestamp). If their backend retries a request after a network blip, Firsty returns the cached response instead of double-provisioning.

What worked

Crypto-native users adopted fast: Pexx users skew technical. They understood eSIM installation immediately and didn't need hand-holding. Activation completion rates were significantly higher than typical consumer eSIM apps.

Loyalty mechanic creates compounding engagement: users who unlock data earn more by transacting more. The data reward becomes a reason to use the core product more, which strengthens the core product. Classic loyalty flywheel.

Multi-IMSI failover prevented support issues: during the first month after launch, two regional carrier outages happened. Pexx's customers stayed connected. The support team didn't even know about the outages until they read Firsty's incident reports.

What we learned

Loyalty integration is a strong embed pattern: tying data rewards to product actions is more effective than offering a flat allocation. Pexx's data shows users who unlock data through transactions retain better than users who simply get free data.

API integration is worth it when connectivity is part of the product story: for Pexx, the eSIM isn't a side feature. It's an extension of the core "use Pexx anywhere" value proposition. Deep integration matters when the feature is core, not when it's optional.

Crypto + connectivity is a real combination: we hadn't anticipated how naturally these fit. Travel crypto users genuinely need both. Other crypto products may want to follow Pexx's pattern.

Could this work for your fintech or crypto product?

If you have:

• A user base that travels internationally
• Engineering capacity for an API integration (2-4 engineer weeks)
• A loyalty or rewards mechanic you want to extend
• A reason your users would value connectivity from your brand

The Pexx pattern probably works for you. The integration is well-documented and the time-to-launch is measured in weeks.

If you're interested in exploring this for your product, contact us. We can share more about how Pexx structured their flow and what we'd recommend for your context.