[旧バージョン]アプリ内課金のレシート検証

 重要

本記事では、すでに非推奨となっている「旧レシート検証機能」について説明しています。 詳細については、以下をご参照ください。お知らせ:旧レシート検証機能(Legacy Receipt Validation)の廃止について

概要:レシート検証の機能を実装することで、iOS および Android のアプリストアで発生する不正なアプリ内課金を防止し、レポートされたとおりにアプリ内課金が実際に発生したことを確認できます。注意:本機能は旧機能です。新しく完全自動化され、改善されたアプリ内課金検証メカニズムについてはこちらをご確認ください。

レシート検証のフロー

レシート検証の流れは以下のとおりです。

  1. エンドユーザーがアプリ内課金を実行。
  2. アプリストアが、課金が成功したことをアプリへ通知。
  3. アプリ開発者が、SDK のレシート検証関数を呼び出す。

    validateAndLogInAppPurchase
  4. SDK が AppsFlyer のレシート検証サービスを呼び出す。
  5. AppsFlyerが、課金が不正なものではないことを確認するために検証。
  6. 検証に成功した場合、AppsFlyer は内部的に通常の af_purchase イベントを生成。検証に失敗した場合、そのイベントは不正としてマーク(Protect360 で確認可能)。
  7. AppsFlyer の検証サービスが結果を SDK に返す。
  8. SDK がレシート検証の結果(成功/失敗)をアプリに返す。
    (レシート検証に失敗した場合、そのイベントはブロックされたアプリ内イベントのローデータレポートに表示されます(Protect360 契約者のみ利用可能)。

レシート検証の実装方法については、以下の SDK ドキュメントをご参照ください。

注意:

  • iOSのsandboxアプリ(App Storeには公開されていないアプリ)の場合、レシート検証を実装するにはコードの追加が必要です。
  • sandbox環境で行われた購入イベントは、通常の af_purchase イベントとして記録され、AppsFlyer の管理画面やレポートに収益が反映されます。
  • AppsFlyerのレシート検証機能は、すべてのご契約プランで無料で利用できます。
  • Android では、購入時にエンドユーザーがインターネットに接続していない場合、レシート検証が null を返し、検証失敗と判断されることがあります。

 重要

validateAndLogInAppPurchaseを呼び出すと、af_purchase のアプリ内イベントが自動的に生成されます。そのため、検証時に 別途 af_purchase イベントを送信しないでください。 送信した場合、収益イベントが二重計上されてしまいます。

 注意

  • 本記事で説明している旧レシート検証機能は、StoreKit v2 をサポートしていません。現行バージョンについては、「iOS App Store との連携設定」をご参照ください。
  • アプリ内課金のレシート検証機能は、Android のサードパーティのアプリストアではサポートされていません。