アプリ内課金

【Amazonサブスク】リアルタイム通知で購入状態の変化を検知する

2021 年の 7 月 15 日、Amazon のアプリ内課金で「リアルタイム通知(Real-Time notifications)」の機能が発表されました。

Apple や Google には以前から同様の機能があり、サブスクや都度課金で活用されています。

【Googleサブスク】リアルタイムデベロッパー通知の種類とハンドリング「Google(Androidサブスク)のレシート検証について」で書いたように、Google Play Billing のサブスクリプシ...

Amazon もサブスクと都度課金の両方に対応しているようですが、仕組みや通知内容を詳しくチェックしてみましょう。

リアルタイム通知の公式ドキュメント

機能の発表と同時に、リアルタイム通知のドキュメントページも公開されました。

これまでは、サブスクの有効期限を過ぎたタイミングなどで Amazon のサーバへ購入状態をチェックしにいかないといけませんでしたが、今後はこの通知が購入状態の変更を検知する トリガーになります。

通知が届いたら、該当の購入情報のレシート検証をして、保持しているユーザのデータに反映する流れですね。

ちなみに通知は、Amazon から送られてくるので、それを受信するための仕組みはこちらで用意する必要があります。

API など受け口となるエンドポイントを用意しておくといいでしょう。

レシート検証とリアルタイム通知の利用フロー

このリアルタイム通知、どのような場面で利用価値が出てくるでしょうか。

これまでの通常のレシート検証やサブスクの更新タイミングと合わせて見てみましょう。

まずは商品購入完了までの流れ。

1. アプリで商品を購入
2. 購入情報(レシート)をバックエンドサーバに送信
3. バックエンドサーバが Amazon RVS でレシート検証

Amazon RVS のレシート検証については、過去にまとめた記事があるので興味があればご覧ください。

【Amazonサブスク】本番RVSとサンドボックスを使ってレシート検証するこれまで、Google のアプリ内課金については何度か記事を書いてきましたが、アプリ内課金には他にも Apple や Amazon など...

次に、リアルタイム通知(RTN)の流れです。

1. Amazon RTN サーバからバックエンドサーバに通知される
2. バックエンドサーバが Amazon RVS でレシート検証

こちらは非同期で処理されるので、商品購入の流れが完了する前に「CONSUMABLE_PURCHASED」の通知が届くケースが考えられそうです。

システムの設計によっては、購入処理は同期的に処理を完了させるケースが多いと思うので、特定の通知タイプを無視するなど考慮は必要になります。

通知タイプの種類は後半で紹介したいと思います。

GooglePlay Billing のデベロッパー通知と同じく、Amazon のリアルタイム通知も状態変更のトリガー的な役割に限定されます。正確な購入状態を確認する場合は必ず Amazon RVS でレシート検証する必要があります。

リアルタイム通知を受け取るための要件

先ほど、リアルタイム通知を受け付ける API などのエンドポイントを用意しておくといいと書きました。

具体的には、エンドポイントには以下の前提条件があります。

・HTTPS の通信が可能(有効な SSL サーバ証明書)
・POST リクエストを受け付けるエンドポイント

通常、HTTPS のプロトコルを介してリクエストを受ける際は、信頼された認証局から発行された証明書を利用します。

なので、HTTPS かつ POST のリクエストを処理するエンドポイントを用意しておけば問題ありません。

テスト購入の通知にも対応しているようなので、テスト環境でも同様に設定しておくと開発もスムーズですね。

リアルタイム通知の内容

リアルタイム通知は、JSON メッセージを介して配信されます。

ただし、JSON の 1 階層目に必要な情報が羅列されているわけではなく、AWS SNS の通知フォーマットの形式となります。

以下の「Message」フィールドにリアルタイム通知の内容が入ってくると言うことですね。

リアルタイム通知の内容は以下の通り。

「レシートID」と「AmazonのユーザID」があれば、バックエンド側で保持している情報と紐付けはできそうです。

項目内容
receiptIdレシートの ID
relatedReceipts関連する追加のレシート
appUserIdAmazon のユーザ ID
notificationType通知タイプ
appPackageNameアプリのパッケージ名
timestampタイムスタンプ
betaProductTransactionテストアプリの商品かどうか

JSON に置き換えると、こんなイメージです。

通知タイプの種類

Amazon のリアルタイム通知には多くの通知タイプが用意されています。

消費型やサブスクの購入時には以下のタイプになりますし、

CONSUMABLE_PURCHASED
SUBSCRIPTION_PURCHASED

サブスクの状態変更に合わせたタイプも最低限は揃っていますね。というか、むしろ充実しています。

SUBSCRIPTION_RENEWED
SUBSCRIPTION_AUTO_RENEWAL_OFF
SUBSCRIPTION_CANCELLED
SUBSCRIPTION_EXPIRED
SUBSCRIPTION_IN_GRACE_PERIOD
SUBSCRIPTION_SCHEDULED_TO_END

どちらにしても、通知タイプに関係なく AmazonRVS でレシート検証を行うことが推奨されているので、最新の状態はそちらで確認すべきでしょう。

リアルタイム通知と言っても、通知が遅れてくる可能性もありますし、こちらのバックエンドサーバの処理でエラーとなり処理に時間が掛かるケースも想定しておかないといけないですからね。

幸い「timestamp」の項目があるので、タイムスタンプを履歴などに残しておくと後から時系列で確認しやすいですね。

通知メッセージに対するセキュリティ

リアルタイム通知が本当に Amazon から送られてきたものかどうかの判断ですが、公式ドキュメントによると AWS の IP レンジ内から送られてくるということが明記されています。

IP レンジは公開されていますが、変更は発生するので、定期的にリストをメンテナンスする必要が出てきます。

できれば署名や暗号化など、レシート検証で使用するような共有鍵を利用できるといいのですが・・・。

まとめ

Amazon のリアルタイム通知について調べてみました。

これまで、サブスク商品の状態確認の推奨方法が「72 時間に 1 回、RVS でレシート検証を行う」というものでした。

キャンセルや解約予約などの状態変化を厳密にチェックしない場合は、有効期限が切れてからレシート検証を行い、サブスクが継続されているのか解約されているのかを判断するという地味な作業ですね。

これが通知トリガーでできるようになるので、通知を取りこぼしたり、Amazon から通知が送られてこないようなレアケースを除けば、通知のみで状態管理ができるようになります。

Amazon のアプリ内課金の仕様は、Apple や Google に比べると遅れている感がありますが、少しずつ追従してきていることは確かです。

ユーザが快適にアプリ内購入を楽しめるようにしていきたいものです。