私が初めて見逃したチャージバックは、土曜日の夜11時40分に発生しました。これがわかったのは、月曜日にPub/Subのログを調べてみたところ、誰も消費していないトピックの中にそれが残っていたからです。
これは2026年8月3日より前の話です。当時は、チャージバックで負けても失うのはその売上分だけで、それ以上の影響はほとんどありませんでした。
現在、Google Playではその日付以降に行われた注文について、チャージバックのコストが開発者に課されるようになりました。注文額からGoogleのサービス料を差し引いた金額に加え、1件につき$15から$25のカードネットワーク手数料を負担することになります。その一方でGoogleは見返りも用意しました。Review Refund APIと、証拠を提出するための約24時間の猶予です。
つまり問題は、チャージバックに対応するかどうかではありません。深夜にそれを処理するのは何かという点です。セットアップについては Google Playのチャージバック対策をご覧ください。本記事はその詳細版で、4つの選択肢を紹介しますが、そのうち2つについてはほとんどのチームにお勧めしません。
重要なポイント
Google Playのチャージバック対応には入力ポイントが1つしかありません。それがReviewRefund APIで、Pending Refund Review Notificationから24時間以内に実行する必要があります。
Googleは最初の呼び出しのみを記録し、それ以降は無視しますが、レスポンスとしてはOKを返し続けます。チャンスは一度きりで、修正はできません。
異議を申し立てられるのはチャージバックのみです。サポートによる返金、48時間以内のPlay返金、未確認の試用版については、あなたの関与なしに決定されます。
現実的な選択肢は4つです。自前で構築する、既存のサブスクリプションプラットフォームを使う、専用ソフトウェアを導入する、あるいは損失を受け入れる、のいずれかです。
この計算は2026年8月3日に変わりました。年額$99のプランで対応期限を1回でも逃すと、注文額に加えてネットワーク手数料も負担することになります。
手動対応の実態
公平に言うと、「手動」といってもその範囲は広いものです。一方では、共有の受信箱を誰かが思い出したときにPlay Consoleを確認するといったレベルのものがあり、もう一方では、当番制やSlackチャンネル、異議申し立て中の注文をまとめたスプレッドシートを使うといった体制もあります。
後者のほうが優れていますが、それでも失敗します。それは努力とは関係のない理由によるものです。
第一に、残り時間が見えないという問題があります。24時間のカウントはPendingRefundReviewNotificationがあなたのPub/Subトピックに届いた時点で始まります。リアルタイム デベロッパー通知を有効にしていない場合、審査が開始されたことを知らせてくれるものは何もなく、Play Consoleにもバッジ表示されません。
第二に、これは多くの人を驚かせる点ですが、Googleは最初のReviewRefund呼び出しのみを記録し、それ以降の呼び出しはすべて無視します。それでもOKを返すため、うまくいったように見えてしまいます。午前9時に誰かが手作業で集めたデータをもとにスクリプトへ回答を入力する、というやり方では、フィールドを一つ間違えても取り消しができません。
どれだけ努力しても、この2つの問題は解決しません。
Google Playのチャージバック処理の流れ
対応期限は想像以上に短いため、ここで流れを整理しておく価値があります。
顧客が自分の銀行に対して請求に異議を申し立てます。開発者やGoogleに対してではありません。
Googleがその注文を審査対象としてフラグを立て、RTDN経由でPendingRefundReviewNotificationを送信します。これにはpendingRefundToken、orderId、refundReasonの値7（CHARGEBACKを示す）、そして購入時に設定していればobfuscatedAccountIdが含まれます。
その後約24時間以内に ReviewRefundを呼び出し、希望する判定（preference）と、用意できる限りの証拠を提出する必要があります。
Googleはそれを使って銀行側に対して異議を主張します。
敗訴した場合、2026年8月3日以降の注文であれば、そのコストは開発者が負担することになります。
ここで注目すべき非対称性があります。AppleはCONSUMPTION_REQUESTを通じて通常の返金についても確認を求めてきますが、Google Playが審査を開くのはチャージバックの場合のみです。それ以外はすべて開発者の関与なしに決着し、voided purchase（無効化された購入）という形で結果を知ることになります。詳しい仕組みは Google Playのチャージバックを徹底解説をご覧ください。
選択肢1：自前でハンドラーを構築する
必要なのはPub/Subトピック、Monetize（収益化）内のMonetization setupでRTDNを有効化すること、メッセージを信頼する前に検証を行うプッシュエンドポイントです。そのうえでbase64のdataフィールドをデコードし、5種類の通知オブジェクトのうちどれが届いたかに応じて処理を分岐させ、注文をユーザーに紐づけ、証拠を収集し、スコープを絞ったOAuthトークンを使ってReviewRefundを呼び出します。
構築自体はそれほどコストのかかる部分ではありません。webhook周りの実装経験があれば、2週間程度で済むでしょう。
コストがかかるのは2年目以降です。Googleがフィールドを変更する。OAuthのリフレッシュトークンが日曜日にひっそりと期限切れになる。そして、なぜかいつもそうなるのですが、$200の異議申し立てが届いた同じ夜にハンドラーが停止します。可視性の確保、リプレイ処理、まだ見たことのない形の通知に対するテストが必要になります。
バックエンドを自社で運用していて、返金対応が実際に収益に関わる規模であれば、自前で構築すべきです。むしろそうしてほしいと思います。しかし、一人でプロダクトをリリースしている立場であれば、1か月をそこに使うのは得策ではありません。
選択肢2：すでに利用しているサブスクリプションプラットフォームを使う
コードを書く前に、まずこれを確認してください。RevenueCatはRefund ControlのもとでGoogleのReview Refund APIを追加しており、AdaptyはApple側でRefund Saverを提供しています。
魅力的なのは、レシート、エンタイトルメント、顧客のマッピング情報がすでにそこに存在しているため、証拠が手近にあり、アカウントの紐づけも解決済みである点です。
限界もあります。返金対応は彼らにとって一機能であり、プロダクトそのものではありません。期待できるのはpreferenceと数個のフラグ程度で、IPアドレス付きの1,000件の利用イベントのようなものではありません。多くのアプリにとってはそれで十分ですが、不正利用が多い異議申し立てには不十分です。
選択肢3：Google Playチャージバック管理専用のソフトウェア
このカテゴリーは8月3日以前にはほとんど存在していませんでした。それだけ、この分野へのインセンティブが新しいものであることがわかります。
仕組みはどれも似ています。サービスがあなたのRTDNをサブスクライブし、期限内に配信・エンゲージメントの証拠とともに拒否(decline)の推奨を提出し、ケースごとに結果を追跡します。
Refund Sensorは、1つのアカウントからGoogle PlayとApp Storeの両方に対してこれを行います。Googleでサインインし、Play Consoleの権限を2つ（財務データの表示、注文とサブスクリプションの管理）付与するだけで、Pub/Subトピックも自動的に用意されます。SDKの導入もコードの変更も、再提出も必要ありません。
トレードオフは、また別のベンダー、また別の月額費用が発生することです。それと引き換えに得られるのは、自分が起きていなくてもよくなるということです。
選択肢4：損失を受け入れる
これが妥当な選択となるアプリもあり、そうでないかのように言うつもりはありません。$1.99の消費型アイテムを販売していて、年間のチャージバックが4件程度であれば、2週間分のエンジニアリングコストは決して回収できません。
ただし、まずは数字を計算してみてください。年額$99のプランで1件のチャージバックに敗訴すると、注文額からGoogleのサービス料を引いた額に加え、$15から$25のネットワーク手数料がかかります。四半期に2件発生すれば、答えは変わってきます。
Google Playのチャージバック対応を自動化する方法
選択肢1を選んだ場合の、構築の順序を示します。順序は思っているより重要です。
Play ConsoleでRTDNを有効化し、Pub/Subトピックを作成します。パイプを信頼する前に「テストメッセージを送信」を実行してください。
dataフィールドをデコードし、届いた通知オブジェクトの種類に応じて処理を分岐させます。1つのメッセージには1種類しか届きません。pendingRefundReviewNotificationが来た場合は、pendingRefundTokenを保存し、タイマーを開始してください。メールではなく、タイマーです。
orderIdをユーザーに紐づけます。obfuscatedAccountIdを使うのが最も速い方法であり、それだけでも購入時に設定しておく理由になります。
証拠を収集します。sampleContentProvided、consumptionPercentageMilliunits（45200は45.2パーセントを意味します）、そしてタイムスタンプとIPアドレス付きのconsumptionUsageEventsを最大1,000件まで用意します。
orders.reviewrefundを1回呼び出し、refundPreferenceにはAPPROVE、DECLINE、NEUTRALのいずれかを指定します。呼び出し内容、ペイロード、レスポンスをログに記録してください。
これとは別に、アクセス削除のためにvoidedPurchaseNotificationを処理し、Voided Purchases APIを毎晩実行して整合性を取ります。こちらは1日6,000回の呼び出しが上限です。
この最後のステップは、誰もが省略してしまう部分です。私も数か月間、省略していました。通知は障害発生時に取りこぼされることがあり、プルAPIを使えば、ダウンしていた間に何が届いていたかを確認できます。どのフィードが何を担うかについては、 Voided Purchases APIとリアルタイム デベロッパー通知の比較で解説しています。
Google Playのチャージバックを未然に防ぐ
これは上記のどの方法よりも低コストで、しかも予期していなかった異議申し立てにも効果があります。
サポートに連絡してくる顧客は、銀行には連絡しません。アプリ内にわかりやすい連絡手段を用意し、1日以内に返信することで、驚くほど多くの異議申し立てを未然に防ぐことができます。
さらに、更新内容をわかりやすく表示しましょう。価格、期間、更新日を購入ボタンと同じ画面に表示します。予期しない驚きは、私が見てきた中で最も異議申し立てを引き起こす要因です。
あまり注目されていない点がさらに2つあります。1つは未確認の購入（unacknowledged purchases）を監視することです。気づかれずに変換された試用版は、1か月後にチャージバックへとつながります。もう1つは、voidedReasonを不正検知のシグナルとして利用することです。これには9種類の値があり、fraud、friendly_fraud、chargebackなどが含まれます。こうしたアカウントは繰り返す傾向があるため、次の試用版を提供する前にフラグを立てておきましょう。
チャージバック率はGoogleのしきい値以下に維持してください。問題が繰り返されるとアカウントの状態に影響が及び、それは個々の返金よりもはるかに深刻です。
出典
よくある質問
返金はGoogleを通じて処理され、Googleまたは開発者がPlay Console上で判断します。一方チャージバックは、顧客が自分の銀行に申し立てを行うものであり、カードネットワークのルールが適用されます。審査が開かれ、開発者が回答できるのはチャージバックの場合のみであり、そのコストが開発者に課されるのもチャージバックの場合に限られます。
PendingRefundReviewNotificationから約24時間です。カウントは通知が配信された時点で始まり、気づいた時点からではありません。
Googleが開発者の証拠なしにチャージバックに対する主張を行うことになり、これは最も不利な立場です。2026年8月3日以降の注文で敗訴した場合、注文額からサービス料を引いた金額に加え、ネットワーク手数料がかかります。
できません。Googleは最初のReviewRefund呼び出しのみを記録し、それ以降はすべて無視しますが、レスポンスとしてはOKを返します。本番環境に反映する前に、テスト購入を使って動作を確認しておきましょう。
自分が起きていなくても回答を送信してくれるものであれば、どれでも構いません。バックエンドを運用しているなら、自前で構築するのも十分に理にかなったプロジェクトです。そうでない場合は、Play Consoleの権限を通じて連携するGoogle Play返金管理ソフトウェアを使うほうが、たった一つのエッジケースのためにPub/Subコンシューマーを書くよりも優れています。
ありません。開発者はGoogle自身が提供するPlay Developer APIを通じて、配信や消費に関する証拠に基づいた推奨を行っているだけです。これはGoogleがそのために用意した正規のチャネルです。
