経緯
プログラマとして、師と仰いでいるモグメット先生に、レシート検証は大切だから、ちゃんとドキュメント作りなさい。
とご指導頂いたので、ここに書き記します。
達成したい仕様
ユーザが課金アイテムを購入後、課金コールバックが帰ってきた後に、
すぐに課金アイテムを追加するのではなく、レシート検証に成功した場合のみ、追加する。
前提
- 課金処理成功後、課金コールバック帰ってくる。
- 課金処理完了メソッドを叩いた後は、課金コールバックは帰ってこない。
- 正常に課金が行われた場合は、レシート検証は失敗しないものと過程するが、万一何らかの障害があってレシート検証ができなくなった場合でも、開発者のサーバコード修正により、一時的にレシート検証なしに課金処理を成功できる保険を事前に用意しておく。
#流れ
- 課金コールバックが呼ばれる。
- レシート検証APIを叩く。
- （成功時）課金処理を実施する。課金処理完了イベントを発火する。
- （失敗時）レシート失敗ポップアップ。OKボタンを押すと、ポップアップが閉じ、再度課金コールバックの発火を依頼するメソッドを叩く。
詳細なシーケンスについては、
Unityでアプリ内課金を簡単に実装する方法
を参考にする。
論点１ ローカル検証かリモート検証か。
UnityIAPがローカル検証をサポートしており、
工数の観点でローカル検証の方がだいぶ楽そうだが、
課金の履歴をサーバで保管したい。いざという時レシート検証処理をサーバ側で向こうにできるようにしたいという要件を達成するため、サーバでの検証を試みる。そのため、GAEサーバ上で、Google Play,IOS Appstore,Amazon App Store 用のレシート検証処理を構築する必要がある。
#Google Play
一度認証トークン取得APIでトークンを取得してから、
レシート検証APIを叩く必要がある。
[【iOS/Android】アプリ内課金 定期購読のサーバーサイド知識総まとめ]
(https://qiita.com/ckm/items/b8cf23ba4bd0ae5bbf34)
#IOS Appstore
ストアのAPIをサーバから叩けばよいが、サンドボックス環境の可能性を考慮する必要がある。
大切なポイント
審査期間中にAppleがサンドボックス環境のレシートを送信してくるため、「開発時はサンドボックス環境、本番運用時は本番環境用」と設定を切り替えるのではなく、実装としていずれのAPIにもリクエストできるようにしておく必要があります。まず先に本番APIにリクエストし、サンドボックスAPIにリクエストすべきステータスが返却されればそのようにします。
参考文献
[【iOS/Android】アプリ内課金 定期購読のサーバーサイド知識総まとめ]
(https://qiita.com/ckm/items/b8cf23ba4bd0ae5bbf34)
#Amazon App Store
シンプルにGETメソッドを叩けばよい模様
アプリ内課金（IAP）アプリのレシート検証