RVSの概要
次の画像は、レシート検証を使用する購入ワークフローを表しています。RVSは、アプリ内課金（IAP）APIによる購入が完了した後に開始され、購入レシートをアプリに返します。
次の表の手順番号は、上図の引き出し線の番号に対応しています。
また、RVSでは、アプリ以外のプラットフォーム（ウェブサイトなど）で購入された定期購入型アイテムへのアクセスを有効にすることもできます。ただし、その購入がAmazonを通じて行われた場合に限ります。このワークフローは次のようになります。
- アプリのユーザーが、アプリ提供元のウェブサイトからAmazonを通じて定期購入型アイテムを購入します。
- アプリが、購入された定期購入型アイテムのレシートを受け取ります。
- アプリがレシートの情報をアプリサーバーに送信します。アプリサーバーがRVSに問い合わせを送信して、このトランザクションを検証します。成功すればアクセスが有効になります。
RVSリクエストの構文
RVSは、PurchaseResponseオブジェクトまたはPurchaseUpdatesResponseオブジェクトを検証するために使用します。これらのレスポンスオブジェクトから、ユーザーを一意に識別するUserIdを抽出できます。PurchaseResponseオブジェクトにはReceiptIdが含まれています。これをUserIdと共に使用して、サーバー側で購入のアウトオブバンド検証を実行します。アプリサーバーから送信するリクエストには、共有シークレットを渡す必要があります。これによって身元確認が行われ、セキュリティが確保されます。
リクエストの形式は次のとおりです。
- Protocol：サーバーまたはRVS Sandboxとの通信に使用するプロトコル（httpsなど）。
- Server：通信相手となるRVSサーバーのURL。
- sandbox：「sandbox」という値を使用します。
- Operation_version_number：
verifyReceiptIdオペレーションのバージョン番号。このバージョン番号は、IAPのバージョン番号とは関係ありません。現在のverifyReceiptIdバージョン番号は「1.0」です。 - Shared_secret：リクエストを発行した開発者を識別するための共有シークレット。共有シークレットは、Amazonアプリストアの開発者アカウントの [共有キー] ページ（https://developer.amazon.com/sdk/shared-key.html）で確認できます。RVSSandboxの場合は、空でない任意の文字列を共有シークレットとして使用できます。
- UserId：Amazonアプリストアで公開したアプリを使用する個々のAmazonユーザーを表すID（
PurchaseResponse.getUserData().getUserId()）。 - ReceiptId：購入を一意に識別するID（
PurchaseResponse.getReceipt().getReceiptId()またはPurchaseUpdatesResponse.getReceipts()→Receipt.getReceiptId()）。
RVSレスポンスの構文
RVSは、RESTfulなJSON APIインターフェイスを提供します。ベストプラクティスとして、RVSサーバーから返されたJSONレスポンスを読み取るには、JSONパーサークラスを使用することをお勧めします。 トランザクションの検証をリクエストすると、RVSサーバーまたはRVS Sandboxから、リクエストが成功したかどうかを示すレスポンスコードが返されます。成功した場合、JSONレスポンスにはトランザクションに関する情報が含まれています。 以下は、リクエストに成功した場合のレスポンスの例です。RVSのレスポンスコード
レシート検証サービスは、応答として次のいずれかのコードを返します。各コードは、検証チェックの結果を示しています。成功したトランザクションのRVSレスポンスフィールド
次の表は、成功したトランザクションのRVSレスポンスに含まれるフィールドとその説明をまとめたものです。キャンセル日と更新日
renewalDateフィールドには、自動更新される定期購入型アイテムの購入が次に更新される日付が格納されます。このフィールドは、定期購入型アイテムの購入にのみ適用されます。ユーザーが月額制の定期購入型アイテムを所有している場合、その定期購入型アイテムは、初回購入日と同じ日付で毎月更新されます。翌月に同じ日付がない場合は、最も近い前の日付が更新日となります。次に例を示します。
- ユーザーが1月2日に定期購入型アイテムを購入した場合、次の3か月間の更新日は、2月2日、3月2日、4月2日になります。
- ユーザーが1月31日に定期購入型アイテムを購入した場合、次の3か月の更新日は、2月28日（うるう年の場合は2月29日）、3月31日、4月30日になります。
cancelDateフィールドには、定期購入型アイテムの購入が期限切れになった日付、またはAmazonカスタマーサービスが購入をキャンセルした日付が格納されます。キャンセル日は、ユーザーがコンテンツにアクセスできなくなった日付を表します。ユーザーが自動更新をオフにして定期購入をキャンセルした場合は、次の更新予定日がキャンセル日となります。
renewalDateフィールドとcancelDateフィールドは、ミリ秒単位の時間として格納されます。この値を日付オブジェクトに変換するには、java.util.Date(timeInMillis)を使用します。
消費型アイテムまたは非消費型アイテムの購入
有効なレシートでは、キャンセル日と更新日はどちらもnull値になります。キャンセル日フィールドがnullでない場合、その値は、Amazonカスタマーサービスが購入をキャンセルした日付を表します。
定期購入型アイテムの購入
有効な定期購入型アイテムのレシートでは、キャンセル日はnullになります。cancelDateフィールドが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となります。
