PexxがFirsty APIをベースに作成したホワイトラベルの旅行用eSIM製品

2026年5月に、 Pexx は、彼らの暗号ウォレットアプリ内にホワイトラベル旅行eSIM製品を立ち上げました。忠実なPexxユーザーは、アカウントの作成や取引によって報酬として無料データを受け取ります。この統合は、FirstyのAPIをエンドツーエンドで利用しています。

このケーススタディでは、Pexxが構築したもの、それらがより単純なWebアプリよりもAPI統合を選んだ理由、そして非通信事業者製品内に接続性を埋め込む方法について学んだことを取り上げています。

Pexxが解決した問題

Pexxユーザーは暗号ネイティブです：彼らはデジタル資産を保持し、取引します。多くの人が国際的に旅行します。暗号ウォレットの旅行ケースは現実のものです：

• 伝統的な銀行手数料なしで海外での支払い

• タイムゾーンを越えて資産を管理する

• 国を移動しながら支払いを受け取る

しかし、Pexxユーザーが旅行するとき、彼らは他のすべての人と同じ問題に直面します：国際ローミングは高価であり、公共WiFiは感度の高い金融作業には安全ではなく、ローカルSIMカードでは主番号を失うことを意味します。

Pexxは、アカウントの作成や取引の完了など、ユーザーに行わせたい行動を強化しながらこれを解決したいと考えました。無料データは報酬の手段となりました。

彼らが構築したもの

Pexxアプリ内で、ユーザーはデータ残高を表示する「無料データ」セクションを見ます。ユーザーが資格のあるアクションを完了すると、残高が増加します：

• アカウントの作成：初期データ残高

• 最初の取引の完了：追加データ

• 取引のマイルストーン達成：ボーナスデータ

• 特定の資産価値の保持：継続的なデータ割り当て

ユーザーが旅行の準備ができたら、「eSIMを有効化する」をタップして、PexxブランドのQRコードを取得し、携帯電話にインストールします。eSIMはホワイトラベルで、顧客はFirstyブランドを見ずにPexxのブランドを見ることができます。

Pexx側の技術フロー：

1. ユーザーがPexxアプリで資格のあるアクションを完了

2. Pexxのバックエンドがユーザーのアカウントにデータを付与（内部残高）

3. ユーザーがeSIMを使用する準備ができたとき、PexxがFirstyのAPIを呼び出してプロビジョニングを行う

4. Pexxがユーザーの獲得した残高に一致するデータパッケージを添付

5. PexxがユーザーにLPA QRコードを返す

6. ユーザーがeSIMをインストールして旅行

データの残高はPexxのデータベースに保存され、実際のeSIMとは分離しています。これにより、Pexxは接続レイヤーと独立してロイヤルティメカニズムを管理することができます。

なぜAPI統合（Webアプリではない）

PexxはWebアプリのアプローチ（Belfiusパターン）を検討しましたが、3つの理由でAPI統合を選びました：

1. 深いロイヤルティ統合：無料データはPexx製品内の特定のユーザーアクションに結びついています。Webアプリではこの状態にきちんとアクセスできませんでした。直接的なAPI統合により、Pexxは各ユーザーの行動に基づいてどれだけのデータを得るかを正確に制御できました。

2. ホワイトラベル体験：Pexxはユーザーが「Firsty」ブランドを見ないようにしたかったのです。Webアプリオプションは共同ブランドで、摩擦を生む可能性がありました。API統合により、Pexxはアプリ全体の体験をネイティブにレンダリングできます。

3. データと分析：Pexxはユーザーの行動を細かに追跡しています。彼らはeSIMの有効化とデータ使用を分析の一級イベントにしたかったのです。Webhook駆動のAPI統合により、それらのイベントをPexxのパイプラインに直接送ることができます。

その代償はエンジニアリング工数でした。Webアプリ＝数時間のリンク統合。API統合＝数週間の作業。Pexxには十分なエンジニアリング能力があり、より深い統合が価値があると判断しました。

統合タイムライン

Pexxの統合は、初期の決定から公開ローンチまで約10週間かかりました：

• 週1-2：アーキテクチャデザイン、eSIMデータフロー仕様、ロイヤルティメカニズムに関する合意

• 週3-5：Firsty API統合（認証、eSIMプロビジョニング、パッケージ注文、Webhookハンドラー）

• 週6-7：Pexx側のeSIMセクション、ロイヤルティ残高表示、アクティベーションフローのUI

• 週8：Pexx従業員による内部テスト

• 週9：一部のパワーユーザーグループによるベータテスト

• 週10：公開ローンチ

Firsty APIの統合自体は1人のエンジニアの作業で約3週間かかりました。残りの時間はUI、ビジネスロジック、内部レビューでした。

強調する価値のある技術的決定

Webhook駆動の状態：Pexxは、eSIMステータスをAPIからポーリングしません。彼らはFirstyのWebhook（esim.installed、package.activated、package.usage）に頼り、内部状態を更新します。これにより、レート制限の心配なしにリアルタイムの正確性が得られます。

事前プロビジョニング：頻繁に旅行する高エンゲージメントのユーザー向けに、Pexxはユーザーが明示的に要求する前にeSIMを事前プロビジョニングします。eSIMは準備ができていますが、パッケージはアクティベーションまで添付されません。これにより、プロビジョニングが「今行われる」から「今パッケージが付く」にアクティベーション時間が短縮され、ユーザーにとって瞬時に感じられます。

二段階のプロビジョニングパターン：eSIMの作成とパッケージ注文を分けることで、Pexxは人気の目的地用にeSIMを事前にプロビジョニングし、ユーザーの選択に基づいて動的にパッケージを添付できます。これはバンドルAPIでは不可能でした。

冗長性キー：Pexxからのすべてのプロビジョニングコールには決定論的な冗長性キー（ユーザーIDとアクションのタイムスタンプを組み合わせたもの）が含まれています。ネットワークの揺らぎがあった後でバックエンドがリクエストを再試行した場合、Firstyは二重プロビジョニングを回避してキャッシュされたレスポンスを返します。

成功した点

暗号ネイティブユーザーの素早い採用：Pexxユーザーは技術的です。彼らはeSIMのインストールを即座に理解し、指示を必要としませんでした。アクティベーション完了率は、一般的な消費者eSIMアプリよりも大幅に高かったです。

ロイヤルティメカニズムが組織的なエンゲージメントを生む：データを解除するユーザーは、より多くの取引を行うことでより多くを獲得します。データ報酬は、コア製品をより多く使用する理由となり、コア製品を強化します。古典的なロイヤルティのフライホイールです。

Multi-IMSIフェイルオーバーがサポート問題を防止：ローンチ後の最初の月に、2つの地域キャリアの障害が発生しました。Pexxの顧客は接続を維持しました。サポートチームは、Firstyのインシデントレポートを読むまでその障害について知りませんでした。

学んだこと

ロイヤルティ統合は強力な埋め込みパターンです：データ報酬を製品アクションに結びつけることは、単に割り当てを提供するよりも効果的です。Pexxのデータでは、取引を通じてデータを解除したユーザーが、単に無料データを受け取るだけのユーザーよりも保持率が高いことを示しています。

接続性が製品ストーリーの一部である場合、API統合には価値があります：Pexxにとって、eSIMはサイド機能ではありません。それは「どこでもPexxを使用する」というコアバリュー提案の拡張です。機能がコアである場合、深い統合が重要です。オプションであるときではありません。

暗号＋接続性は現実の組み合わせです：我々はこれがどれほど自然にフィットするかを予想していませんでした。旅行する暗号ユーザーには両方が本当に必要です。他の暗号製品もPexxのパターンに従いたいかもしれません。

これがあなたのフィンテックまたは暗号製品で機能するでしょうか？

あなたが持っている場合：

• 国際的に旅行するユーザーベース

• API統合のためのエンジニアリング能力（2-4エンジニア週）

• 拡張したいロイヤルティまたは報酬メカニズム

• あなたのブランドからの接続性をユーザーが価値に感じる理由

Pexx パターンはおそらくあなたに適しているでしょう。その統合は十分に文書化されており、立ち上げまでの時間は数週間で測定されます。

あなたの製品にこれを探求することに興味がある場合は、お問い合わせください。Pexx がどのようにそのフローを構築したか、またあなたの状況におすすめする方法について詳細を共有することができます。