返金対策に使える、Google Playのリアルタイム通知と連携するツールとは？

結論から言うと、思っているより少なく、そのほとんどは「聞くだけ」です。

Google Play RTDNは、いわば通信パイプです。更新、解約、無効化された購入を運んでおり、2026年半ば以降は「チャージバックが審査中で、24時間以内に意見を述べられる」というメッセージも流れるようになりました。この最後のメッセージこそが、Google Playの返金対策が実際に行われる唯一の場所です。それ以外のフィードは、Googleがすでに下した決定を通知しているだけです。

そのため、「返金対策のためにGoogle Playのリアルタイムデベロッパー通知と連携できるツールはどれか」と聞かれたとき、実際には2つの質問がされていることになります。フィードを「聞ける」のはどれか、そして「応答できる」のはどれか、という点です。Apple側については、弊社の CONSUMPTION_REQUEST解説記事で、iOSにおける同様の問題を取り上げています。

重要なポイント

• Google Play RTDNはPub/Subのトピックです。Googleがパブリッシュし、あなたがサブスクライブします。

• 異議を申し立てられるRTDNタイプはPendingRefundReviewNotificationの1つだけです。チャージバック発生時に送信され、24時間の猶予が与えられます。

• 2026年8月3日以降、チャージバックの費用は開発者負担となります。購入価格からGoogleの手数料を差し引いた金額に加えて、15～25ドルの銀行手数料が上乗せされます。

• ほとんどのサブスクリプションプラットフォームはGoogle Playの返金通知を受信しますが、何かを送り返すものはごくわずかです。

• RevenueCatはチャージバックレビューに応答しますが、同社のドキュメントによれば消費データは送信されません。送られるのは意向（preference）と1つのフラグのみです。

• 24時間を過ぎると、Googleはあなたからの情報なしに紛争対応を進めます。

Google Play RTDNが実際に送信するもの

リアルタイムデベロッパー通知は、あなた自身が所有するGoogle Cloud Pub/Subのトピックに届きます。各メッセージは、5種類のペイロードのいずれかを保持するbase64形式のデータです。サブスクリプションイベント、単発商品イベント、テストping、そしてここで重要になる2種類です。

VoidedPurchaseNotificationは、いわば定番のGoogle Play返金通知です。購入が返金、チャージバック、またはその他の理由で無効化されたことを示します。フィールドはpurchaseToken、orderId、productType、refundTypeの4つ。アクセス権の剥奪には使えますが、お金はすでに戻ってしまっているため、異議申し立てには役立ちません。

PendingRefundReviewNotificationは新しく追加されたものです。Googleの RTDNリファレンスによれば、これは「ユーザーが購入に対してチャージバックを申請し、そのリクエストに開発者によるレビューが必要な場合」に送信されます。届くのはpendingRefundToken、orderId、そして現時点では常に7（CHARGEBACKを意味する）であるrefundReasonです。その時点から24時間のカウントダウンが始まります。

つまり、Google Play RTDNの返金通知には2種類あるということです。一方は「領収書」、もう一方は「質問」です。

なぜ24時間の猶予が突然重要になったのか

長年、Android上のチャージバックはGoogleの問題でした。ユーザーが銀行に対して課金を異議申し立てすれば、Googleがその費用を負担し、あなたはvoided purchase通知を受け取って先に進むだけでした。

それも2026年8月3日以降に行われた注文については終わりを迎えました。現在は、購入価格からPlayのサービス手数料を差し引いた金額に加え、銀行が請求するチャージバック手数料を支払うことになります。Googleが負担するのは自社のサービス手数料のみです。

カードネットワークの手数料は、紛争1件につき15～25ドル、時にはそれ以上かかります。そのため、$4.99のコインパックがチャージバックされると、約3.50ドルの収益損失に加えて20ドルの手数料がかかることになります。4ドルの売上に対して23ドルが失われる計算です。

その代わりに、GoogleはReviewRefund APIを公開しました。PendingRefundReviewNotificationが届いたら、トークン、refundPreference（DECLINE、APPROVE、またはNEUTRAL）、サンプルを提供したかどうか、ミリユニット単位の消費率、そして最大1,000件の利用イベントを添えて orders.reviewrefundにPOSTします。Googleがそれをもとに銀行と交渉してくれます。

この猶予を逃すと、Googleは何の材料もないまま交渉に臨むことになります。業界データによれば、証拠なしのチャージバック勝率は20～30%程度とされています。証拠がある場合、一部のベンダーは80%を主張しています。どちらの数字も割り引いて考える必要はありますが、方向性は明らかです。

実際の機能で分類したツール一覧

多くの製品が「Google Play RTDNに対応している」とうたっていますが、そのほとんどは単にトピックをサブスクライブしているだけの意味です。実際に応答するものはごくわずかです。

Refund Sensor。この用途のために作られたツールです。Cloudプロジェクト内にPub/Subトピックをプロビジョニングし、Play Consoleに登録します。PendingRefundReviewNotificationが届くと、Review Refund APIを通じて配信・消費に関する証拠とともにDECLINEの推奨を提出します。セットアップはGoogleサインインとPlay Console権限2つのみで、SDKは不要です。執筆時点で、単なる意向だけでなく証拠を提出する数少ないツールの一つです。詳細は Google Play対策ページをご覧ください。

RevenueCat。RTDNを受信し、Voided Purchases APIをポーリングして、返金時に権利を剥奪します。2026年7月にGoogleをRefund Controlに追加したことで、現在はチャージバックレビューに応答するようになりました。ただし、 同社のドキュメントをよく読んでください。Google側ではトークン、trueに設定されたsampleContentProvided、そしてあなたの意向を送信します。彼らの言葉を借りれば、「RevenueCatは現時点で消費率や利用イベントを収集も送信もしていません」とのことです。投票はできても、論拠は示されません。すでに利用しているなら問題ありませんが、完全な対策にはなりません。

Adapty。しっかりしたRTDN受信機能を備えています。ドキュメントでは、トピック名をPlay Consoleに貼り付けてテストボタンを押す手順が説明されています。返金はイベントフィードに表示され、webhookも発火します。ReviewRefund連携は見当たりません。聞くだけです。

Qonversion、Glassfy、その他。事情は同じです。Google Playのリアルタイムデベロッパー通知を取り込んでサブスクリプションの状態を最新に保っていますが、公開されているドキュメントを見る限り、チャージバックレビューには一切関与していません。

自前のバックエンド。常に選択肢の一つです。Pub/Subのサブスクリプション、デコーダー、注文の照会、利用状況のクエリ、認証付きのPOSTを1回。難しいのはコードそのものではありません。通知が日曜日の午前2時に届いても、タイマーは容赦してくれないという点です。

Google Playのチャージバック管理ソフトウェアを検討しているなら、すべてのベンダーに一つだけ質問してください。「レビュー通知が届いたとき、具体的に何を送り返すのか」と。「意向（preference）」を送るのは始まりに過ぎません。消費データこそが対策になります。

返金対策のためにGoogle Play RTDNを自前で連携する方法

購入ではなく自前で構築したい場合は、以下の手順に従ってください。

Google CloudプロジェクトでCloud Pub/Sub APIを有効化します。トピックを作成します。[email protected]にPub/Sub Publisherロールを付与します。このロールを付与し忘れると、通知は一切届きません。これはRevenueCatフォーラムで最もよく見られる不満です。

Play Consoleで「Monetize」から「Monetization setup」に進みます。「Enable real-time notifications」にチェックを入れ、トピックのフルネーム（projects/your-project/topics/your-topic）を貼り付けて、「Send test notification」をクリックします。届けば、パイプは正常に機能しています。

Pub/Subのサブスクリプションをpush方式またはpull方式で作成します。dataフィールドをデコードします。ペイロードに応じて処理を分岐します。

PendingRefundReviewNotificationの場合：注文を照会し、実際の利用状況を取得し、意向を決定して、pendingRefundTokenとともにreviewrefundにPOSTします。24時間以内に行わなければ意味がありません。VoidedPurchaseNotificationの場合：アクセス権を剥奪します。弊社の 返金後のアクセス権に関する記事では、この手順がGoogleに関して特に間違えやすい理由を解説しています。

すべてを記録してください。応答率と勝率は別の数値です。

Googleが提供してくれないものが一つあります。それは、テスト用のPendingRefundReviewNotificationです。仕組みを構築したら、実際のチャージバックが発生するのを待つしかありません。だからこそ、ホスト型ツールでは緑色のチェックマークではなく「awaiting first refund event（最初の返金イベント待ち）」と表示されるのです。

あえてランク付けするなら、Google Play RTDN連携に最適なツール

証拠をもってチャージバックレビューに応答するという意味での、Google Play返金対策に特化したツールとなると、リストは短くなります。Refund Sensorは消費データを用いて、コードなしでそれを実現します。RevenueCatは意向のみで対応しますが、これは何もしないよりはましという程度です。それ以外はすべて、フィードを見ているだけです。

一般的なRTDNの配線と権利同期という点では、RevenueCatとAdaptyはどちらも成熟しており、ドキュメントも充実しています。

これらすべてに関わりたくないなら、TebexやXsollaのようなmerchant of recordをウェブショップで利用することで、責任を自社の帳簿から切り離せます。ただしその場合、購入自体もPlayから切り離されることになり、Play上に残る購入には何の効果もありません。

自社が抱えている課題に応じて選んでください。

まとめ

Google Play RTDNはもともと、あなたに何かを「伝える」ために作られたものでした。「尋ねる」ようになったのはごく最近のことです。PendingRefundReviewNotificationは、Androidにおいて初めてGoogleがあなたの側の言い分を求めるようになった通知であり、それはちょうどGoogleが敗訴分の費用をあなたに負担させ始めたのと同じ時期に登場しました。

これによって計算が変わります。Google Playの返金通知をただ聞いているだけのツールは、返金を失っても売上分の損失で済んでいたころは十分でした。しかし今では、売上分に加えて銀行手数料までかかるようになり、その請求を防げるかどうかは、24時間以内のPOSTリクエスト一つにかかっています。

まずはトピックを設定しましょう。次に、あなたのプラットフォームが実際に何を送り返しているのかを確認してください。もし答えが「何もない」、あるいは「意向のみ」であれば、次のチャージバックが発生する前にそのギャップを埋めておくべきです。