Comment Pexx a construit un produit eSIM de voyage en marque blanche sur l'API Firsty

En mai 2026, Pexx a lancé un produit eSIM de voyage en marque blanche dans leur application de portefeuille crypto. Les utilisateurs fidèles de Pexx gagnent des données gratuites en récompense pour la création de comptes et les transactions. L'intégration utilise l'API de Firsty de bout en bout.

Cette étude de cas couvre ce que Pexx a construit, pourquoi ils ont choisi l'intégration API plutôt qu'une webapp plus simple, et ce que nous avons appris sur l'intégration de la connectivité dans un produit non télécom.

Le problème résolu par Pexx

Les utilisateurs de Pexx sont natifs de la crypto : ils détiennent et échangent des actifs numériques. Beaucoup voyagent à l'international. Les cas d'utilisation de voyage pour les portefeuilles crypto sont réels :

• Payer à l'étranger sans frais bancaires traditionnels

• Gérer des actifs à travers des fuseaux horaires

• Recevoir des paiements en se déplaçant entre les pays

Mais quand les utilisateurs de Pexx voyagent, ils rencontrent le même mur que tout le monde : l'itinérance internationale est coûteuse, le WiFi public n'est pas sûr pour les opérations financières sensibles, et les cartes SIM locales signifient perdre votre numéro principal.

Pexx voulait résoudre cela d'une manière qui renforçait également leur produit principal : récompenser les comportements qu'ils veulent que les utilisateurs adoptent (créer des comptes, effectuer des transactions). Les données gratuites sont devenues l'incitation.

Ce qu'ils ont construit

Dans l'application Pexx, les utilisateurs voient une section "données gratuites" qui montre leur solde de données. Le solde augmente lorsque les utilisateurs effectuent des actions éligibles :

• Création d'un compte : solde de données de départ

• Complétion de la première transaction : données supplémentaires

• Atteindre des jalons de transaction : données bonus

• Détenir certaines valeurs d'actifs : allocation de données continue

Lorsque l'utilisateur est prêt à voyager, il tape sur "activer eSIM" et obtient un code QR de marque Pexx à installer sur son téléphone. L'eSIM est en marque blanche : les clients voient la marque Pexx, pas Firsty.

Le flux technique du côté de Pexx :

1. L'utilisateur effectue une action éligible dans l'application Pexx

2. Le back-end de Pexx accorde des données au compte de l'utilisateur (solde interne)

3. Lorsque l'utilisateur est prêt à utiliser l'eSIM, Pexx appelle l'API de Firsty pour la provisionner

4. Pexx associe un forfait de données correspondant au solde gagné par l'utilisateur

5. Pexx renvoie le code QR LPA à l'utilisateur

6. L'utilisateur installe l'eSIM et voyage

Le solde de données est stocké dans la base de données de Pexx, découplé de l'eSIM réelle. Cela permet à Pexx de contrôler les mécaniques de fidélité indépendamment de la couche de connectivité.

Pourquoi l'intégration API (pas de webapp)

Pexx a envisagé l'approche webapp (le modèle Belfius) mais a choisi l'intégration API pour trois raisons :

1. Intégration fidèle profonde: les données gratuites sont liées à des actions spécifiques de l'utilisateur dans le produit Pexx. Une webapp ne pourrait pas accéder à cet état de manière claire. L'intégration API directe permet à Pexx de contrôler exactement combien de données chaque utilisateur reçoit en fonction de son comportement.

2. Expérience en marque blanche: Pexx voulait que les utilisateurs ne voient jamais la marque "Firsty". L'option webapp est co-marquée, ce qui aurait introduit des frictions. L'intégration API signifiait que Pexx pouvait rendre toute l'expérience de manière native dans leur application.

3. Données et analyses: Pexx suit de près le comportement des utilisateurs. Ils voulaient que l'activation de l'eSIM et l'utilisation des données soient des événements de première classe dans leurs analyses. L'intégration API déclenchée par des webhooks livre ces événements directement dans le pipeline de Pexx.

Le compromis était l'effort d'ingénierie. Webapp = intégration de lien en quelques heures. Intégration API = semaines de travail. Pexx avait la capacité d'ingénierie et a décidé que l'intégration plus profonde en valait la peine.

Chronologie de l'intégration

L'intégration de Pexx a pris environ 10 semaines, de la décision initiale au lancement public :

• Semaines 1-2: Conception de l'architecture, spécification du flux de données eSIM, accord sur les mécaniques de fidélité

• Semaines 3-5: Intégration de l'API Firsty (authentification, provisionnement eSIM, commande des forfaits, gestionnaire de webhooks)

• Semaines 6-7: Interface utilisateur côté Pexx pour la section eSIM, affichage du solde de fidélité, flux d'activation

• Semaine 8: Tests internes avec les employés de Pexx

• Semaine 9: Tests bêta avec un groupe de super-utilisateurs sélectionnés

• Semaine 10: Lancement public

L'intégration de l'API Firsty a elle-même pris environ 3 semaines de travail d'un ingénieur. Le temps restant était consacré à l'interface utilisateur, à la logique métier et à la révision interne.

Décisions techniques à souligner

État déclenché par webhook: Pexx ne sonde pas notre API pour le statut eSIM. Ils comptent sur les webhooks de Firsty (esim.installed, package.activated, package.usage) pour mettre à jour leur état interne. Cela signifie une précision en temps réel sans souci de limite de taux.

Pré-provisionnement: Pour les utilisateurs à forte fréquentation qui voyagent fréquemment, Pexx pré-provisionne les eSIMs avant que l'utilisateur les demande explicitement. L'eSIM est prête, mais le forfait n'est pas attaché avant l'activation. Cela réduit le temps d'activation de "le provisionnement se fait maintenant" à "le forfait s'attache maintenant", ce qui semble instantané pour l'utilisateur.

Schémas de provisionnement en deux étapes: en séparant la création de l'eSIM de la commande de forfait, Pexx peut pré-provisionner les eSIMs pour les destinations populaires et attacher des forfaits dynamiquement en fonction du choix de l'utilisateur. Cela ne serait pas possible avec des APIs groupées.

Clés d'idempotence: chaque appel de provisionnement de Pexx inclut une clé d'idempotence déterministe (combinant l'ID utilisateur et l'horodatage de l'action). Si leur backend réessaie une demande après une coupure réseau, Firsty renvoie la réponse en cache au lieu de reprovisionner.

Ce qui a fonctionné

Les utilisateurs natifs de la crypto ont adopté rapidement: Les utilisateurs de Pexx ont une tendance technique. Ils ont compris l'installation d'eSIM immédiatement et n'ont pas eu besoin d'accompagnement. Les taux de complétion d'activation étaient nettement plus élevés que ceux des applications eSIM de consommation typiques.

La mécanique de fidélité crée un engagement composé: les utilisateurs qui débloquent des données gagnent plus en effectuant plus de transactions. La récompense de données devient une raison d'utiliser davantage le produit principal, ce qui renforce le produit principal. Mécanisme de fidélité classique.

Le basculement multi-IMSI a évité des problèmes de support: pendant le premier mois après le lancement, deux pannes de réseau régional ont eu lieu. Les clients de Pexx sont restés connectés. L'équipe de support n'a même pas su qu'il y avait des pannes jusqu'à ce qu'ils lisent les rapports d'incidents de Firsty.

Ce que nous avons appris

L'intégration de la fidélité est un modèle fort d'intégration: associer des récompenses de données à des actions produit est plus efficace que d'offrir une allocation fixe. Les données de Pexx montrent que les utilisateurs qui débloquent les données grâce aux transactions conservent mieux que ceux qui obtiennent simplement des données gratuites.

L'intégration API en vaut la peine lorsque la connectivité fait partie de l'histoire du produit: pour Pexx, l'eSIM n'est pas une fonctionnalité secondaire. C'est une extension de la proposition de valeur principale "utiliser Pexx partout". Une intégration profonde est importante lorsque la fonctionnalité est centrale, pas lorsqu'elle est optionnelle.

La crypto + la connectivité est une véritable combinaison: nous n'avions pas anticipé à quel point ces éléments s'adaptent naturellement. Les utilisateurs de crypto en voyage ont réellement besoin des deux. D'autres produits crypto pourraient vouloir suivre le modèle de Pexx.

Cela pourrait-il fonctionner pour votre produit fintech ou crypto ?

Si vous avez :

• Une base d'utilisateurs qui voyagent à l'international

• Capacité d'ingénierie pour une intégration API (2-4 semaines d'ingénieurs)

• Une mécanique de fidélité ou de récompenses que vous souhaitez étendre

• Une raison pour laquelle vos utilisateurs apprécieraient la connectivité de votre marque

Le modèle Pexx fonctionne probablement pour vous. L'intégration est bien documentée et le temps de lancement se mesure en semaines.

Si vous êtes intéressé à explorer cela pour votre produit, contactez-nous. Nous pouvons vous en dire plus sur la façon dont Pexx a structuré leur flux et ce que nous recommanderions pour votre contexte.