アプリ内課金(IAP)アプリのレシート検証


アプリ内課金(IAP)アプリのレシート検証

レシート検証サービス(RVS)を使用すると、アプリのユーザーが行った購入を検証できます。

RVSの概要

次の表は、レシート検証を使用する購入ワークフローを示しています。RVSは、アプリ内課金(IAP)APIによる購入が完了した後に開始され、購入レシートをアプリに返します。

手順 コンポーネント タスク
手順1 IAP API IAP APIがユーザーとやり取りして購入を完了します。IAP APIからアプリに購入レシートが返されます。
手順2 アプリ アプリがアプリサーバーに購入レシートを転送します。
手順3 アプリサーバー アプリサーバーがRVSサーバーにレシート検証リクエストを送信します。
手順4 RVSサーバー レシートが有効であることをRVSサーバーが確認します。
手順5 アプリサーバー アプリサーバーがユーザーに対してコンテンツを利用可能にします。

上の表の手順番号は、下図の引き出し線の番号に対応しています

また、RVSでは、アプリ以外のプラットフォーム(ウェブサイトなど)で購入された定期購入型アイテムへのアクセスを有効にすることもできます。ただし、その購入がAmazonを通じて行われた場合に限ります。このワークフローは次のようになります。

  1. アプリのユーザーが、アプリ提供元のウェブサイトからAmazonを通じて定期購入型アイテムを購入します。
  2. アプリが、購入された定期購入型アイテムのレシートを受け取ります。
  3. アプリがレシートの情報をアプリサーバーに送信します。アプリサーバーがRVSに問い合わせを送信して、このトランザクションを検証します。成功すればアクセスが有効になります。

RVSのセットアップ

RVSには、アプリが開発/テスト段階にあるか、Amazonアプリストアで公開されているかに応じて、2つの環境オプションが用意されています。

  • RVS Sandbox: アプリの開発中およびテスト中は、RVS Sandbox環境を使用して、App Testerテストツールで生成されたレシートを検証します。RVS Sandboxをセットアップするには、RVS Sandbox環境のセットアップ手順を参照してください。
  • RVS本番サーバー: アプリをAmazonアプリストアに公開した後は、Amazon RVS本番サーバーを使用できます。RVS本番環境のセットアップ手順を参照してください。

RVSリクエストの構文

PurchaseResponseまたはPurchaseUpdatesResponseで受け取ったレシートオブジェクトを検証するには、RVSを使用します。これらのレスポンスオブジェクトには、ユーザーを一意に識別するユーザーIDが含まれています。PurchaseResponse内のレシートにはReceiptIdが含まれています。これをユーザーIDと共に使用して、サーバー側で購入のアウトオブバンド検証を実行します。アプリサーバーから送信するリクエストには、共有シークレットを渡す必要があります。これによって身元確認が行われ、セキュリティが確保されます。

リクエストの形式は次のとおりです。

<プロトコル>//<サーバー>/<[_RVSSandbox_]>/version/<オペレーションのバージョン番号>/verifyReceiptId/developer/<共有シークレット>/user/<ユーザーID>/receiptId/<レシートID>

山かっこで囲まれた部分は、以下を参考に、検証対象のトランザクションに応じた値に置き換えてください。

  • プロトコル: サーバーまたはRVS Sandboxとの通信に使用するプロトコル(httpsなど)。
  • サーバー: 通信相手となるRVSサーバーのURL。
    • RVS Sandboxを使用している場合は、「localhost:8080」またはTomcatをセットアップしたURLを使用します。
    • RVS本番サーバーを使用している場合のURLは「appstore-sdk.amazon.com」です。
  • [RVSSandbox]: RVSSandboxを使用している場合は、「RVSSandbox」という値を使用します。RVS本番サーバーを使用している場合は、このフィールドを省略します。
  • オペレーションのバージョン番号verifyReceiptIdオペレーションのバージョン番号。このバージョン番号は、IAPのバージョン番号とは関係ありません。現在のverifyReceiptIdバージョン番号は「1.0」です。
  • 共有シークレット: リクエストを発行した開発者を識別するための共有シークレット。共有シークレットは、Amazonアプリストアの開発者アカウントの [共有キー] ページ(https://developer.amazon.com/sdk/shared-key.html)で確認できます。RVSSandboxの場合は、空でない任意の文字列を共有シークレットとして使用できます。
  • ユーザーID: Amazonアプリストアで公開したアプリを使用する個々のAmazonユーザーを表すID(purchaseResponse->userData->userId
  • レシートID: 購入を一意に識別するID(purchaseResponse->receipt->receiptIdまたはpurchaseUpdatesResponse->receipts->receipt->receiptId

RVSレスポンスの構文

RVSは、RESTfulなJSON APIインターフェイスを提供します。ベストプラクティスとして、RVSサーバーから返されたJSONレスポンスを読み取るには、JSONパーサークラスを使用することをお勧めします。

トランザクションの検証をリクエストすると、RVSサーバーまたはRVS Sandboxから、リクエストが成功したかどうかを示すレスポンスコードが返されます。成功した場合、JSONレスポンスにはトランザクションに関する情報が含まれます。

以下は、リクエストに成功した場合のレスポンスの例です。

   { "betaProduct":false,
     "cancelDate":null,
     "parentProductId":null,
     "productId":"com.amazon.iapsamplev2.gold_medal",
     "productType":"CONSUMABLE",
     "purchaseDate":1399070221749,
     "quantity":1,
     "receiptId":"wE1EG1gsEZI9q9UnI5YoZ2OxeoVKPdR5bvPMqyKQq5Y=:1:11",
     "renewalDate":null,
     "term":null,
     "termSku":null,
     "testTransaction":true
   }

RVSのレスポンスコード

レシート検証サービスは、応答として次のいずれかのコードを返します。各コードは、検証チェックの結果を示しています。

レスポンスコード 説明
HTTP 200 成功しました。 レシートID、ユーザーID、共有シークレットがすべて有効です。商品タイプは、 「ENTITLED」(非消費型アイテム)、「CONSUMABLE」(消費型アイテム)、「SUBSCRIPTION」(定期購入型アイテム)のいずれかです。
HTTP 400 このreceiptIdで表されるトランザクションが無効です。または、このreceiptIdに対応するトランザクションが見つかりませんでした。
HTTP 496 sharedSecretが無効です。
HTTP 497 ユーザーIDが無効です。
HTTP 500 内部サーバーエラーが発生しました。

成功したトランザクションのRVSレスポンスフィールド

次の表は、成功したトランザクションのRVSレスポンスに含まれるフィールドとその説明をまとめたものです。

フィールド データ型 説明
betaProduct ブール型 購入商品がライブアプリテスト商品かどうかを示します。
cancelDate 長整数 購入をキャンセルした日、または定期購入の期限が切れた日。購入がキャンセルされていない場合、このフィールドはnullになります。
parentProductId 文字列 null。将来使用するために予約されています。
productId 文字列 アプリ内でこのアイテムに対して定義したSKU。
productType 文字列 購入された商品の種類。有効な商品タイプは、CONSUMABLE(消費型アイテム)、SUBSCRIPTION(定期購入型アイテム)、ENTITLED(非消費型アイテム)です。
purchaseDate 長整数 購入日。エポックからのミリ秒数として格納されます。定期購入型アイテムの場合、purchaseDateは最初の購入日を表します。それ以降の更新日を表すものではありません。
quantity 整数 購入された数量。常にnullまたは1になります。
receiptID 文字列 購入の一意の識別子。
renewalDate 長整数 定期購入型アイテムの更新が必要となる日付。エポックからのミリ秒で計算されます。
term 文字列 定期購入型IAPアイテムの有効期間(期間は購入日から始まります)。数字と期間(日、週、月、年)で構成されます(「1週間」、「2か月」など)。
termSku 文字列 定期購入期間に対応する一意のSKU。
testTransaction ブール型 この購入が、Amazonによる公開・テストプロセスの一部として実行されたものかどうかを示します。

キャンセル日と更新日

renewalDateフィールドには、自動更新される定期購入型アイテムの購入が次に更新される日付が格納されます。このフィールドは、定期購入型アイテムの購入にのみ適用されます。

cancellDateフィールドには、定期購入型アイテムの購入が期限切れになった日付、またはAmazonカスタマーサービスが購入をキャンセルした日付が格納されます。

更新日フィールドとキャンセル日フィールドは、ミリ秒単位の時間として格納されます。この値を日付オブジェクトに変換するには、java.util.Date(timeInMillis)を使用します。

消費型アイテムまたは非消費型アイテムの購入

有効なレシートでは、キャンセル日と更新日はどちらもnull値になります。キャンセル日フィールドがnullでない場合、その値は、Amazonカスタマーサービスが購入をキャンセルした日付を表します。

定期購入型アイテムの購入

有効な定期購入型アイテムのレシートでは、キャンセル日はnullになります。cancellDateフィールドがnullでない場合、その値は、定期購入型アイテムが期限切れになった日付、またはAmazonカスタマーサービスが購入をキャンセルした日付を表します。

renewalDateフィールドには、自動更新される定期購入型アイテムの購入が次に更新される日付が格納されます。自動更新が設定されていない定期購入型アイテムでは、このフィールド値はnullになります。

例として、ユーザーがキャンセルした定期購入型アイテムがあるとします。

  • この定期購入型アイテムは、2016年1月1日から2016年3月1日までアクティブでした。レシートでは、この定期購入型アイテムのpurchaseDateは2016年1月1日に設定され、cancelDateは2016年3月1日に設定されます。
  • この定期購入型アイテムが2016年4月1日に再びアクティブにされた場合、2つ目のレシートが生成されます。2つ目のレシートでは、purchaseDateは2016年4月1日を表し、cancelDateはnullになります。

RVS SandboxとRVS本番環境の例

レシート検証サービス(RVS)の例を参照してください。