Google Play のチャージバック審査はあなたに 24 時間の反撃機会を与える。何を送るべきかを解説

顧客の銀行が Google Play の請求を取り消すとき、Google Play はただ返金して終わりにするわけではありません。あなたのサーバーに PendingRefundReviewNotification を送り、24 時間のカウントダウンを始めます。ReviewRefund API を通じて、その通知に返金の希望と顧客が実際に何を使ったかの証拠で応答すれば、Google Play はあなたの意見をチャージバックへの反論の仕方に織り込みます。黙っていれば、製品がどう消費されたかを知る唯一の当事者が一言も発しないまま、紛争は決着します。

Google Play のチャージバック審査は、あなたに証拠を求める唯一の Android 返金フローであり、Apple の CONSUMPTION_REQUEST の直接の対応物です。これは以前よりも今のほうが重要になっています。2026 年 8 月 3 日から、Google Play はチャージバックのコストを開発者に移すため、応答しそこねた紛争は Google ではなくあなたの口座から出ていきます。ここでは、この通知が何を運ぶのか、あなたが何を返すのか、証拠を構成するフィールド、そして沈黙がどこで金銭に変わるのかを、正確に解説します。

Google Play のチャージバック審査とは実際に何なのか

チャージバックは返金リクエストではありません。顧客は自分の銀行やカードネットワークに行って請求に異議を申し立て、銀行が資金を引き戻します。Google Play はこれらの大半を自力で処理します。その一部については審査を開き、まずあなたに尋ねます。なぜなら、注文が提供されたかどうか、そして顧客がそのうちどれだけを消費したかという、Google が持たない情報をあなたが握っているからです。その審査こそが ReviewRefund API の背後にあるフローです。

ここは Android の返金システムの中で、あなたの証拠が結果を変える唯一の場所です。その他のあらゆる Google Play の返金経路は、あなた抜きで進みます。顧客は購入から 48 時間以内にセルフサービスで返金でき、サポートも返金を認められ、承認されていない購入は自動返金され、すべて Google が決定します。チャージバック審査は例外であり、あなたが実際に参加できる唯一の返金の対話として扱う価値があります。

これは Apple の証拠ウィンドウの Android 版です

2 つのストア、開発者に証拠を求める 2 つのフロー、そのすべてがこれで全部です。Apple は CONSUMPTION_REQUEST を送り、Send Consumption Information で応答する 12 時間を与えます。Google Play は PendingRefundReviewNotification を送り、orders.reviewrefund で応答する 24 時間を与えます。仕組みは異なりますが、教訓はまったく同じです。ストアが顧客が何を使ったかを尋ねるとき、正確な答えこそが、売上を守るか手放すかの分かれ目です。

実務上、ひとつの違いが重要です。Apple の消費ペイロードは 5 つの数値フィールドだけで、それ以外はありません。Google Play の証拠はより豊かです。消費割合に加えて、個々の使用イベントのリストを送れます。各イベントにはタイムスタンプ、アカウント識別子、さらには IP アドレスと大まかな位置情報まで付けられます。Google Play は提供内容を説明する余地をより多く与えており、それはより説得力を持たせる余地が多いということです。

24 時間のカウントダウンと、通知があなたに届く仕組み

審査は Real Time Developer Notification として、あなたの Cloud Pub/Sub トピックに届きます。サブスクリプションや購入のイベントを届けるのと同じチャネルです。メッセージは base64 でエンコードされたペイロードで、その中に pendingRefundReviewNotification オブジェクトが入っています。カウントダウンは、あなたがたまたまそれを読んだときではなく、その通知が公開されたときに始まります。ですから、1 日に一度しかポーリングしない消費者は、紛争を取りこぼす消費者です。

PendingRefundReviewNotification をフィールドごとに

この通知は小さなものです。どの注文が審査中かを伝え、あなたが引用して返さなければならないトークンを渡し、理由を明示します。ここでは、それが運ぶすべてのフィールドを示します。

保留中の審査を開くのはチャージバックだけです

保留中の審査の refundReason は常に CHARGEBACK で、整数 7 として届きます。Google Play の世界には他の返金理由も存在しますが、それらはこのフローを通じてあなたに届きません。あなたに発言権がないからです。PendingRefundReviewNotification を見たなら、銀行が請求を取り消し、Google Play がそれに反論するかどうかを決めているということです。それが唯一のトリガーです。

ReviewRefund API を通じてあなたが返すもの

あなたは orders.reviewrefund への 1 回の POST で応答します。完全なパスは POST https://androidpublisher.googleapis.com/androidpublisher/v3/applications/{packageName}/orders/{orderId}:reviewrefund で、https://www.googleapis.com/auth/androidpublisher スコープで認可されます。これはあなたの Play Developer API 連携がすでに使っているのと同じ OAuth スコープです。成功すると、空のボディと HTTP 200 が返ります。

ボディこそが、あなたの主張が置かれる場所です。通知からの pendingRefundToken をそのまま返し、返金の希望を述べ、消費の証拠を添えます。

あなたの返金の希望は勧告であって、判定ではありません

refundPreference フィールドは 3 つの値のいずれかを取り、それは Google Play への助言であって、最終決定ではありません。結果は依然として Google が握ります。しかしそれは、Google が自力では見られないデータに裏打ちされた助言なので、重みを持ちます。

DECLINE を裏付ける証拠フィールド

むき出しの DECLINE は、証明のない主張です。消費フィールドがその証明です。consumptionPercentageMilliunits はミリ単位の整数で、100000 は顧客が購入したものの 100% を消費したことを、50000 は半分を表します。consumptionUsageEvents は任意の配列で、各イベントは obfuscatedAccountId、obfuscatedProfileId、consumptionTime、ipAddress、consumptionItemDescription、そして大まかな location を運べます。sampleContentProvided は、有料コンテンツの無料サンプルを顧客に提供した場合のための真偽値です。これらは合わせて、Google Play 自身のスキーマで、製品が提供され使用されたことを語ります。

最初の呼び出しが、あなたの唯一の呼び出しです

Google Play は、ある通知に対してあなたが行う最初の ReviewRefund 呼び出しを記録し、それ以降の呼び出しをすべて無視しますが、それでも OK ステータスを返します。下書きも修正もありません。もし最初の応答が、パイプラインの準備が整っていなかったために証拠のない慌ただしい NEUTRAL であれば、それが記録に残る応答となり、完全な消費履歴を伴う後の呼び出しは黙って破棄されます。何かを送る前に、完全な答えを組み立ててください。

この審査があなたに金銭面で課すもの

何年もの間、負けた Google Play のチャージバックは、開発者に売上とわずかなもの以外の損失を与えませんでした。Google Play が下流の手数料を負担していたからです。それは 2026 年 8 月 3 日に終わります。その日より後に行われた注文については、Google Play はチャージバックのコストを開発者と分担し、開発者の負担分は購入価格から Play のサービス手数料を差し引いた額に、金融機関が課す関連チャージバック手数料を加えたものです。Google Play はサービス手数料の部分を引き続き負担します。銀行手数料は、あなたの側の帳簿に乗る新たな重みです。

返金は決して本当の数字ではありません

紛争は顧客の支払いを返しますが、その支払いは決してあなたの唯一のコストではありませんでした。生成された動画、一括のモデル API 呼び出し、クリエイターへの支払い、あなたが用意したストレージ、そのすべての金は注文が提供された瞬間にあなたの口座から出ていき、そのどれもチャージバックとともに戻ってはきません。さらにその上に銀行のチャージバック手数料が加わります。あなたはプロバイダーの請求を支払い、売上を返金し、紛争手数料を負担する。防御する証拠を持っていた 1 件の注文に対して、3 つのコストを払うのです。

Google が戦っている規模

Google Play は、2025 年に US$3.4B の不正と悪用をブロックし、2026 年を通じて不正検出を強化していると述べています。このコスト分担の変更は、同じ取り組みの一部です。開発者に証拠をシステムへ供給する理由を与え、システムがより多くの不正な紛争に反論する。ReviewRefund API は、あなたの証拠がそこに入る手段です。空の応答は、フレンドリーフラウドのチャージバックをあなたの負担で通してしまうことへの一票です。

通知が届く前に準備しておく方法

24 時間のウィンドウは問題ではありません。問題は、あなたが必要とする証拠が紛争より前に存在していなければならないこと、つまりトークンが現れた後に再構成するのではなく、購入と消費の時点で取得されていなければならないことです。通知が届いてからデータ収集を始めるチームは、すでに負けています。

購入時に身元を結び付ける

すべての購入で setObfuscatedAccountId を使って obfuscatedAccountId を設定し、通知のアカウント id があなたのシステム内のユーザーへまっすぐにひも付くようにします。それはハッシュのままにし、64 文字以下とし、決して平文のメールアドレスやその他の個人データにしないでください。平文の識別子は購入をブロックさせるからです。そのリンクがなければ、pendingRefundToken を実際の使用履歴につなげられず、あなたの DECLINE には裏付けが何もありません。

消費が起きたその場で記録する

有料の注文が何を、いつ、誰に提供したかを、必要に応じて consumptionPercentageMilliunits と consumptionUsageEvents に変換できる形で記録してください。

• 消費の一つひとつの単位にタイムスタンプを付け、各イベントの consumptionTime が推定ではなく実際のものになるようにします。
• 購入に対して提供を追跡し、推測ではなく自信を持って消費割合を述べられるようにします。
• アカウントとプロファイルの識別子を使用記録の隣に保持し、トークンが届いたときにイベントが 1 回のクエリで組み上がるようにします。
• 持っているなら、リクエストの IP と大まかな位置情報を取得します。Google Play はどちらもイベントフィールドとして受け付けるからです。

ウィンドウ内で自動的に応答する

24 時間のウィンドウは機械にとっては余裕ですが、目を覚まして注意を払っていなければならない人間にとっては過酷です。応答は自動であるべきです。通知が入り、アカウントが照会され、消費が組み立てられ、1 回の ReviewRefund 呼び出しが出る、そのすべてが人を介さずに進む。それこそが RefundHalt があなたのために動かす部分です。私たちは PendingRefundReviewNotification を待ち受け、注文をそのアカウントについてすでに追跡している使用データと突き合わせ、ウィンドウ内で返金の希望と実際の消費の証拠を添えて orders.reviewrefund に応答します。トークンが糸で、証拠が主張です。その両方を用意しておけば、あなたが参加できる唯一の返金の対話は、勝てる対話になります。