【Google】定期購入のリアルタイムデベロッパー通知の種類とハンドリング
saratogax
サラトガ牧場
アプリ内課金(Google,Apple,Amazon)の最新動向
saratogax
記事内に商品プロモーションを含む場合があります
アプリ内課金は、現代のデジタル経済の中心となる要素の 1 つで、ユーザがアプリ内で追加コンテンツやサービスを購入することを可能にしています。
この記事では、現在主流となっている以下の 3 つの主要なプラットフォームについての最新情報を詳細に解説します。
Google Play Billing
Apple In-app Purchase
Amazon In-app Purchase
これらのプラットフォームは、開発者がアプリ内課金を簡単に統合し、ユーザがスムーズに購入を行えるようにするための重要なツールとなっています。
それぞれのプラットフォームがどのように機能し、それぞれが提供する独自機能やサービスについて紹介していきます。
Contents
Google Play Billing
Google Play Billing は、Google Play 上でデジタル商品やサービスの課金を管理するシステムです。
サービス提供者が Google Play Billing を利用すると、以下のような機能を実装することができます。
・消費アイテム
・非消費アイテム
・定期購入アイテム
アプリ内課金アイテムには消費アイテムと非消費アイテムがあり、それぞれ以下の特徴があります。
消費アイテム
ユーザが使用すると消費され、再度購入する必要があるアイテムのこと。ゲーム内通貨(コインやジェムなど)や一時的なブースト(パワーアップ、時間制限の強化など)がイメージしやすいでしょうか。
非消費アイテム
ユーザが一度購入すると永続的に所有し続けることができるアイテムのこと。ゲーム内のプレミアムアップグレード(特別な特典)やオリジナルのキャラクタースキン(アバター)などがイメージしやすいでしょうか。
定期購入アイテムはサブスクリプションのことで、1 か月や 3 か月など特定の利用期間ごとに料金を支払うアイテムですね。
サブスクリプションの状態取得
2022 年、サブスクリプションの状態取得の API にバージョン 2 が登場しました。
しかし 2023 年 12 月現在、まだ完全互換があるところまでいかず v1 の API も「deprecated」にはなっていません。
今後の機能拡張は v2 中心なので、早く移行したいところですね。
あわせて読みたい
【Google】purchases.subscriptionsv2のAPIとv1の互換性
無効となった購入(返金, チャージバック)
都度課金にもサブスクにも言えることですが、Google のアプリ内課金の購入に対して以下から無効化される可能性があります。
・Google
・サービス利用者(ユーザ)
・サービス提供者(developer)
特に都度課金の無効化の情報は、Google の voided API からしか取得できませんでしたが、2023 年にデベロッパー通知でも受けることができるようになりました。
あわせて読みたい
【Google】無効(返金やチャージバック)となった購入の情報をリアルタイムに通知で取得する
あわせて読みたい
【Google】購入したアイテムの払い戻し(返金)の実行や確認
レシートからサブスクリプションの情報がいつまで参照できるか
ユーザの自発的な解約や、決済不備で AccountHold を抜けた際、その時の有効期限から 60 日くらいが経過すると Google の API から 400 や 410 エラーが返るようです。
詳しくは下記の記事をご覧ください。
あわせて読みたい
【Google】参照期限が過ぎたレシートやトークン無効化のレスポンス(400, 410エラー)
リアルタイムデベロッパー通知
Google Play Billing には「リアルタイムデベロッパー通知」の機能が用意されていて、機能も拡張され続けています。
2023 年 11 月には、新たに無効となった購入が発生した際に通知が届くようになりました。
あわせて読みたい
【Google】無効(返金やチャージバック)となった購入の情報をリアルタイムに通知で取得する
DeveloperPayloadの取り扱い
2018 年くらいまで一般的に利用されていたようですが、ネイティブアプリ側でレシートオブジェクトの developerPayload にプロジェクトやユーザの必要な情報を入れて、それをサーバサイドに渡すという手法が取られていました。
私がアプリ内課金を触り始めたときには、Goolge のベストプラクティスでは非推奨とされていて、署名(signature)を使った改ざんチェックなどが一般化され始めた頃。
ただ現在、その署名を元にした改ざんチェックが公式ドキュメントからなくなっているので、何が最新のベストプラクティスなのかモヤモヤしているところです。
あわせて読みたい
【Google】アプリ内課金レシートのDeveloperPayloadの扱いについて
購入状態の判定に使うデータ
アプリ内課金では Billing Library2.0 から保留決済(pending)が導入されました。
この状態ではアイテム付与など、ユーザにはまだ特典を与えないことになっているのですが、その状態を持つのが「purchaseState」
しかし、似たようなオブジェクトが Billing Library の中に 2 箇所存在して、それぞれ定義されている値が異なるのですよね。
あわせて読みたい
【Google】AndroidとAPI(purchases.products)のPurchaseStateについて
ABOUT ME
仕事にも趣味にも IT を駆使するフリーランスエンジニア。技術的な TIPS や日々の生活の中で深堀りしてみたくなったことを備忘録として残していきます。
