Google Play RTDNとVoided Purchases API:返金対策にはどちらを使うべきか?

迅速なイベント処理にはGoogle Play RTDNを使用します。無効化された注文のチェックと記録の照合にはVoided Purchases APIを使用します。ほとんどの有料アプリにとって、より安全な選択は両方を使うことです。

アプリ向けの Google Playの返金対策を計画している場合は、まずこの使い分けから始めましょう。一方は何かが変化したことを知らせてくれます。もう一方は、サーバーが無効化された購入のリストを取得し、見逃したものを確認できるようにします。

この選択は、単純に2つの通知システムの間で行うものではありません。Google Play RTDNはCloud Pub/Sub経由でメッセージをプッシュします。Voided Purchases APIはプル型のAPIであり、バックエンドが呼び出します。

どちらの仕組みも、それ単体でユーザーの返金リクエストを止めることはできません。これらの価値は、変化を検知し、注文を確認し、有料アクセスが購入状態と一致していることを確認する点にあります。

重要なポイント

• 購入およびサブスクリプションのイベントに迅速に対応するにはRTDNを使用します。

• 影響を受けた注文を確認するための第二の経路として、無効化された購入のリストを使用します。

• サブスクリプションの解約を返金の証拠として扱わないようにします。

• 両方の経路で、同じ安全なアクセス更新ロジックを使用するようにします。

• 保留中のチャージバックレビューは、完了した無効化処理とは別に管理します。

Google Play RTDNとは?

Google Play Real-Time Developer Notifications(通常はRTDNと呼ばれます)は、購入に関連するイベントをCloud Pub/Subのトピックに送信します。

バックエンドはメッセージを受信し、適切なワーカーへとルーティングします。メッセージの種類は重要です。更新、解約、無効化された購入は、それぞれ異なるイベントです。

返金の追跡では、voidedPurchaseNotificationに注意を払ってください。これには以下が含まれます。

• purchaseToken:イベントを購入に紐付けます。

• orderId:影響を受けた注文を識別します。

• productType:サブスクリプションか単発購入かを識別します。

• refundType:全額無効化か、数量ベースの部分返金かを区別します。

Googleの RTDNリファレンスとイベント定義では、これらのフィールドやその他の通知タイプについて説明されています。

RTDNは、変化の直後に対応したい場合に役立ちます。ただし、メッセージはあなたの購入データベースそのものではありません。アクセスを変更する前に、保存されている記録と照合し、必要に応じて関連する購入状態を取得してください。

サブスクリプションの解約は返金を意味するのか?

いいえ。顧客は今後の更新を停止しても、現在の契約期間の残りについては有料アクセスを維持できます。

SUBSCRIPTION_CANCELEDが届くたびにアクセスを削除するようなルールを作らないでください。代わりに、サブスクリプションの状態と有効期限を確認します。取り消し(revocation)と有効期限切れは、それぞれ個別の処理が必要です。

Voided Purchases APIとは?

Google Play Voided Purchases APIは、サポート範囲内でキャンセル、返金、またはチャージバックされた購入のリストを返します。

これは単発のアプリ内注文とサブスクリプションの両方に適用されます。サーバーはこの結果を使って、どの購入がもはやアクセスを付与すべきでないかを確認できます。

このリストには、注文ID、購入トークン、無効化日時、無効化のソース、無効化の理由が含まれる場合があります。サポートされている数量ベースの部分返金については、返金された数量も含まれることがあります。

Googleの Voided Purchases APIガイドでは、30日間の遡及期間が記載されています。これは恒久的な返金アーカイブではありません。処理済みの記録は自社のシステムに保存してください。

このAPIは、ワーカーの停止、ルーティングのバグ、またはローカル記録の抜け漏れが発生した後に特に役立ちます。また、処理済みのイベントに対する定期的なチェックも可能にします。

RTDN対Voided Purchases API:実務上の違い

重要な問いは、どちらのツールが単体で優れているかではありません。それぞれのツールがどのような失敗への対処に役立つか、という点です。

RTDNは迅速な経路を提供します。APIは確認のための経路を提供します。これらを統合するのは、自社のデータベースの役割です。

アプリはどちらを使うべきか?

スピードが重要な場合はRTDNを使用する

有料アプリは、購入状態の変化に気づくために、定期スキャンを待つ必要はないはずです。

サブスクリプション、単発購入、無効化された注文について迅速な更新が必要な場合は、RTDNを使用します。すべてのメッセージに1つの返金ルールを適用するのではなく、イベントの種類ごとにルーティングしてください。

網羅性が重要な場合はAPIを使用する

定期的なAPIチェックを使って、ワーカーが記録に反映しなかった無効化済みの注文を見つけます。

例えば、レシーバーはメッセージを受け取ったものの、バグによってその後のアクセス更新が妨げられた可能性があります。配信を修正するだけでは、このローカルな抜け漏れは解消されません。

本番の返金ワークフローでは両方を使用する

ほとんどの有料アプリでは、両方を組み合わせます。両方の経路を、注文を確認し、変更を安全に適用する1つの共有ハンドラーに集約してください。

これにより、見逃した1件のイベントによってアクセスが有効なままになるリスクを減らせます。また、同じ返金に対してアクセスを二重に削除してしまう、逆のリスクも減らせます。

Google Playの返金を段階的に検知する方法

1. 購入台帳を管理する

アプリのパッケージ、購入トークン、注文ID、プロダクト、ユーザーのマッピング、付与された数量を保存します。台帳とは、何が購入され、どのようなアクセスが付与されたかを示す明確な記録にすぎません。

サブスクリプションについては、更新時の注文IDも保存してください。RTDNリファレンスには、自動更新のたびに新しい注文IDが発行されると記載されています。購入トークンだけでは、影響を受けたすべての更新を特定するには不十分です。

2. RTDNメッセージを保護し、ルーティングする

Pub/Subのアクセスを正しく設定します。プッシュ配信の場合は、認証済みリクエストを検証します。プル配信の場合は、サブスクリプションを読み取れるユーザーを制限します。

メッセージをデコードし、パッケージ名を確認したうえで、時間のかかる処理を実行する前に保存します。テストイベントは、受信エンドポイントだけでなく、経路全体を通して送信してください。

3. 定期的な無効化購入スキャンを実行する

適切な認証情報とPlay Consoleの権限を使って、listメソッドを呼び出します。すべての結果ページを取得してください。

見落としがちなクエリ設定が2つあります。

• type=1は、単発購入とサブスクリプションの両方を含みます。デフォルトの0は、単発購入のみを含みます。

• includeQuantityBasedPartialRefund=trueは、サポートされている数量ベースの部分返金を含みます。デフォルトはfalseです。

Googleの voidedpurchases.listメソッドリファレンスでは、リクエストおよびページネーションのフィールドについて説明されています。

スキャン間には適度な重複を持たせ、結果の重複を排除してください。スキャンの頻度は、処理量、クォータ、アプリが許容できる遅延の程度に基づいて選択します。遡及期間がほぼ終わるまで待ってはいけません。

4. 各変更は1回だけ適用する

両方の経路が、同じ無効化を報告することがあります。冪等な処理を構築してください。同じ変更を再度実行しても、結果が変わらないようにします。

注文IDだけを使って、以降のすべてのイベントを破棄しないでください。複数数量の購入には、複数回の部分返金が発生することがあります。処理済みの調整と返金された数量を追跡し、本当に発生した後続の返金を見逃さないようにしてください。

5. メッセージ件数だけでなく、抜け漏れも監視する

最後に成功したスキャン、未完了のページ、ワーカーのエラー、一致しない注文を追跡してください。確定したイベントの後、アクセスの更新にどれくらい時間がかかるかを計測します。

より広範なレポートについては、 モバイルアプリの返金・チャージバック追跡ツールガイドをご覧ください。

例:1件の返金、2つの検知経路

これは仮の例であり、実際に報告された顧客事例ではありません。

あるプレイヤーが500コインを付与する単発パックを購入します。その購入は、後になって全額無効化されます。

RTDNが無効化購入のメッセージを送信します。ワーカーは注文を見つけ、記録されている付与内容を確認し、その購入に紐づくコインに対して、公開済みのポリシーを適用します。

その後、定期的なAPIスキャンが同じ注文を返します。共有ハンドラーは、全額無効化の調整がすでに適用済みであることを確認します。一致を記録し、二重に控除することはありません。

ここで、最初の変更を適用する前にワーカーが失敗したと仮定します。スキャンがその注文を見つけ、システムに処理するための別の経路を提供します。

これこそが、両方を使うことの意味です。2つの別々の「罰」ではなく、1つの正しい結果にたどり着くための2つの手段です。

すでに一部のコインが使われていた場合、無関係な有料パックからコインを無条件に差し引くことは避けてください。明確なポリシーを用い、対応内容を説明し、サポート窓口を用意してください。

保留中の返金レビューは別のワークフロー

現在のGoogleのドキュメントには、デベロッパーによるレビューが必要なチャージバックリクエストに対応するpendingRefundReviewNotificationも記載されています。

このイベントについて、Googleは24時間以内にorders.reviewrefundを通じて返金提案と購入利用の証拠を提供するよう案内しています。

これをvoidedPurchaseNotificationと混同しないでください。一方は保留中のレビューに関するものであり、もう一方は無効化された購入を報告するものです。

Voided Purchases APIは、保留中のレビューイベントの処理に代わるものではありません。この分岐は別途管理し、すべての返金リクエストがこのイベントを発生させるとは限らないことを念頭に置いてください。

App Storeの返金と収益漏れ:デベロッパーが知っておくべきこと

収益の漏れは、ストアがお金を返金するかどうかだけの問題ではありません。該当する購入がもはや根拠とならなくなった後も、バックエンドが有料アクセスを付与し続けてしまうことも意味します。

両方のプラットフォームを扱うチームにとって、目標は共通しています。それは、お金、購入状態、アクセス記録を整合させることです。ただし、ストアごとのツールやイベントルールは異なります。Appleのワークフローをそのままの形でGoogle Playに流用しないでください。

当社の App Store返金収益管理ガイドでは、より広範な収益管理の課題を取り上げています。このGoogle Play連携については、まず見逃された無効化、重複控除、誤ったサブスクリプションアクセスの変更に注目してください。

Google Playの返金不正防止でできること、できないこと

Google Playの返金不正防止は、しっかりとした記録と公正なルールから始まります。無効化された注文は、顧客が不正を働いた証拠ではありません。

ユーザーには正当な苦情があるかもしれません。決済が失敗することもあります。アプリが誤ったアイテムを配信してしまった可能性もあります。

これらのツールを使って事実を確認し、アクセスの変更を適用してください。繰り返されるパターンは、文脈を踏まえて検証します。1件の返金を理由にアカウントを自動的にバンすることは避け、顧客が誤りを申し立てられるようにしてください。

RTDNもリストAPIも、返金を防ぐこと、拒否すること、取り消すことを保証するものではありません。

まとめ

RTDNとVoided Purchases APIのどちらを選ぶかは、ほとんどの有料アプリにとって二者択一の問題ではありません。

迅速に対応するためにはRTDNを使用します。記録を照合するためには、定期的な無効化購入のチェックを使用します。両方を1つの安全なハンドラーに通し、保留中のレビューは完了した無効化処理とは別に管理してください。

まずは小さなテストから始めてください。1件の無効化を両方の経路に通し、アクセスの変更が1回だけ行われることを確認します。次に、ワーカーを停止し、復旧経路が抜け漏れを検知できるかを確認してください。