OSP から SDK 統合への移行
概要
この移行では、One-Step Payment（OSP） 統合を新しい Android Billing SDK 統合に置き換えます。SDK は、URL ベースの課金フローと外部ウェブコールバックを、Aptoide Wallet に直接接続するより統合されたクライアントに切り替えます。
開始する前に、必要なコード変更を正しく実装するために、Android Billing SDK のドキュメントを確認してください。
統合の仕様
OSP 統合（現在の実装）
- 課金フロー:
- サーバー上で署名済みの OSP URL を生成します。
- その URL を使用して Intent を起動します。
- Aptoide Wallet が支払いを処理します。
- POST コールバックがお客様のウェブサービスエンドポイントに送信されます。
- お客様のサーバーがトランザクションを検証してから、プロダクトを提供します。
- 主な特徴:
- URL ベースの支払い呼び出しを使用します。
- サーバーサイドのエンドポイントと URL 署名の生成が必要です。
- ウォレットは（Intent 経由で）外部から呼び出され、アプリにはコールバックを通じて通知されます。
- 主要な機能を持たないシンプルなユーザー獲得です。
- Consumables（消費型） 以外のプロダクトタイプはサポートしていません。
Android Billing SDK 統合（新しい実装）
- 課金フロー:
AppcoinsBillingClientを介して Android Billing SDK との接続を確立します。- Aptoide Connect から
productsを直接クエリします。 - SDK を介して Aptoide Wallet を起動し、購入フローを開始します。
- アプリ内コールバック（
PurchasesUpdatedListener）で購入結果を処理します。 - 購入の正当性を確保し、不正を回避するために購入を検証します。
- 必要に応じてアイテムを再購入できるように、購入を消費します。
- 主な特徴:
- シームレスなアプリ内課金体験を提供します。
- 外部 URL 生成とウェブコールバックの必要性を排除します。
- ネイティブ Android コンポーネントと非同期コールバックを使用します。
- ユーザー獲得とリワードを向上させる D2C 機能を備えています。
- Subscription（サブスクリプション） タイプのプロダクトをシームレスにサポートします。
OSP 統合と SDK 統合の主な違い
OSP 統合と SDK 統合の主な違いは次のとおりです。
| 観点 | OSP 統合 | Android Billing SDK 統合 |
|---|---|---|
| 支払いの呼び出し | 署名済み URL で Intent を起動 | Billing client を使用して購入フローを開始 |
| トランザクション処理 | トランザクション完了時のウェブサービスコールバック | PurchasesUpdatedListener を介したアプリ内コールバック |
| サーバーの関与 | サーバー上で署名済み URL を生成する必要がある | サーバーサイドのロジックは最小限。公開鍵は Console 経由で提供され、RTDN を使用してサーバーサイドに購入状態を通知できる |
| プロダクトのクエリ | 不要。プロダクトの詳細は Aptoide Connect に登録されるか、手動で取得される | querySkuDetails を介して Aptoide Connect から直接プロダクトをクエリする |
| 購入の消費 | 該当なし（コールバックで処理される） | consumeAsync を使用して購入を明示的に消費する必要がある |
| メンテナンス | 破壊的変更を伴う機能については手動での更新と調整が必要 | SDK 内で管理され、メンテナンスの労力を軽減する |
追加の考慮事項
保留中の購入
保留中の購入を正しく処理するには、Billing Client への接続をセットアップした後、直ちに queryPurchases メソッドを使用して保留中の購入を確認し、検証済みのものを消費します。これにより、未完了のトランザクションが適切に処理されます。
スレッディング
Android Billing SDK では、一部の呼び出し（特にネットワーク呼び出し）を IO スレッドで実行する必要があります。この変更が必要なものには特に注意を払い、アプリケーションの UI がスムーズで応答性を保つようにしてください。
購入の識別
購入フロー中に developerPayload（例: ユーザー ID や内部の注文 ID）を使用して、購入をユーザーにさらに紐付けます。
テスト
提供されているテスト用認証情報とサンプル実装（Diceroll SDK sample など）を使用して、本番環境に展開する前に新しい統合が正しく動作することを確認してください。
FAQ
課金サービスが準備できていない場合はどうなりますか?
SDK は、Billing Client の準備状態を確認するための isReady メソッドを billing client 上に提供しています。購入フローを開始したり、購入や Sku Details をクエリしたりする前に、必ずこれを確認してください。
サーバーサイドのコールバックを引き続き管理する必要がありますか?
いいえ。Android Billing SDK は、PurchasesUpdatedListener を介してアプリ内でトランザクションの更新を処理します。これにより、別個のサーバーサイドコールバックエンドポイントの必要性がなくなります。RTDN を使用して、Subscriptions および Voided Purchases の変更を検証できます。
購入を消費するにはどうすればよいですか?
SDK が提供する consumeAsync メソッドを使用して購入を消費します。購入が 48 時間以内に消費されない場合、自動的に返金されます。
SDK のバージョンはどのくらいの頻度で更新すべきですか?
SDK バージョンの更新は必須ではありませんが、新しいリリースごとに SDK の重要な機能や改善がもたらされることに留意してください。更新はほとんどの場合バージョン自体のバンプのみで済むため、バージョンを最新の状態に保つよう努めてください。
不正を回避し、購入の正当性を確保するにはどうすればよいですか?
クライアントアプリケーションで受け取る購入が正当なものであることを保証するには、アプリ内購入の検証ページのガイドラインに従ってください。