Google Play の購入を三日以内に確認しないと Google が返金します。それがあなたにいくらの損失をもたらすか

顧客があなたの製品を購入し、決済が通り、三日後に Google Play が静かに返金し、あなたが届けたものを引き戻します。誰もその返金を求めていません。顧客が申請したわけでも、サポート担当者が承認したわけでもありません。それが発動したのは、あなたのサーバーが購入を処理したことを Google に一度も伝えなかったからです。Google Play の購入を三日以内に確認しないと、Google は毎回、購入者に返金し購入を取り消します。これは両ストアの中でも数少ない、完全にあなたの統合で防げる返金の一つであり、最も静かに売上を漏らす方法の一つです。

これは不正の問題でもポリシーの争いでもありません。ただの取りこぼしたコールバックです。修正は小さく、それを飛ばした代償は本物のお金なので、ルールを正確に知っておく価値があります。ルールが何であるか、なぜ購入が未確認のまま滑り抜けるのか、そして失われた売上一件が実際に何を持ち去るのかを。

三日ルールが実際に述べていること

Google の Play Billing のドキュメントはこの点で率直です。アプリが権利を付与し、購入が成功したとユーザーに伝えた後、購入が処理されたことを Google に通知しなければなりません。Google の言葉では、これは「購入が自動的に返金されず権利が取り消されないよう、三日以内に行わなければならない」とされています。一回限りの製品のページも一切和らげずに繰り返しています。「三日以内に購入を確認しないと、ユーザーは自動的に返金を受け、Google Play が購入を取り消します。」サブスクリプションも最初の購入について同じルールを持っています。

確認は形式ではなくシグナルです。それは権利がユーザーに届いたことを Google に伝えます。Google はそのシグナルの欠如を、行われなかった配信として扱い、顧客に代わって取引を巻き戻します。購入者から見れば、申請してもいない無料の返金のように見えます。あなたから見れば、消え去った売上のように見えます。

カウントダウンは PURCHASED から始まる。チェックアウトからではない

三日間のウィンドウは、ユーザーが購入をタップしたときには始まりません。購入状態が PURCHASED に遷移したときに始まります。購入は先に PENDING にとどまることがあり、現金払い、遅い銀行振込、あるいは親が子どもの依頼を承認する場合に起こります。Google は明確です。「三日間の確認ウィンドウは、購入状態が PENDING から PURCHASED に遷移したときにのみ始まります。」

これには二つの帰結があります。権利は状態が PURCHASED のときにだけ付与し、決して PENDING で付与しないこと。さもないと、完了しないかもしれない支払いに対して製品を配ってしまいます。そして PENDING の購入を確認してもいけません。BillingClient を構築するときに enablePendingPurchases() を呼び、遷移を待ち、そのときになって初めて頭の中で確認のカウントダウンを始めます。

確認するか消費するか、そしてどちらを負うのか

要件を満たす方法は二つあり、どちらを使うかは製品によります。どちらも三日間の期限をクリアします。違いは、それ以外に何をするかです。

消費型アイテムなら、消費します。安全なバックエンドでは purchases.products.consume、あるいは Play Billing Library のクライアント側 consumeAsync() です。消費は購入を確認すると同時に製品を再び購入可能にします。これはコイン、クレジット、一回限りの生成にまさに望むことです。非消費型アイテムやサブスクリプションなら、確認します。バックエンドで purchases.products.acknowledge または purchases.subscriptions.acknowledge、クライアント側で acknowledgePurchase() です。確認は期限をクリアしますが、製品を再購入可能にはしません。

更新はすでに処理済み、最初の購入はそうではない

確認を負うのはサブスクリプションの最初の購入だけです。Google は「サブスクリプションの更新を確認する必要はない」と明言し、更新には自ら ACKNOWLEDGEMENT_STATE_ACKNOWLEDGED の印を付けます。新しい購入は ACKNOWLEDGEMENT_STATE_PENDING で届き、あなたが処理するまであなたの責任のままです。確認する前に、二重確認しないよう、バックエンドで acknowledgementState を、クライアント側で isAcknowledged() を確認しましょう。

プリペイドプランは導火線が短い

プリペイドのサブスクリプションプランはウィンドウを狭めます。Google のルールはこうです。一週間以上のプリペイドプランは三日以内に確認しなければなりませんが、「一週間より短い期間のプリペイドプランは、プラン期間の半分以内に確認しなければならない」。三日間のプリペイドプランでは、三日ではなく一日半しかありません。短いプリペイドのチャージを売るなら、確認の経路は速く、サーバー主導でなければならず、ユーザーがアプリを再び開くことに頼ってはいけません。

そもそもなぜ購入が未確認のままになるのか

誰も確認を飛ばそうとしているわけではありません。確認するコードが間違った場所にあるから滑り抜けるのです。よくあるアンチパターンは、購入フローがフォアグラウンドに戻ったときにだけ確認するクライアントです。それは、購入を完了しアプリを使い続けるユーザーには機能します。それ以外の全員には失敗します。

開発者は絶えずこれにぶつかります。Google 自身の開発者コミュニティのスレッドは毎回同じように読めます。「私のアプリで購入した後、三日後にユーザーが自動で返金された」や「なぜ支払いが三日後に自動で返金されるのか」といった言い回しの変種です。答えはほとんど常に同じです。アプリが発火できる状態に一度もなかったため、確認の呼び出しが一度も発火しなかったのです。

無料トライアルと二度と戻ってこないユーザー

最悪の形は、無料トライアル、あるいはユーザーがアプリを永久に閉じる直前の購入です。確認が次のアプリ起動に依存していて、次のアプリ起動がなければ、購入は期限切れになります。三日目に Google は返金し取り消します。有料サブスクリプションに転換したはずのトライアルなら、あなたは決して回収できなかった最初の請求を失い、加えて静かに消えた顧客の権利も失います。どちらの出来事もサポートチケットとしては現れません。あなたが探しに行かなければならない無効化された購入として現れます。

未確認による返金が実際にいくらかかるか

返金の一行は損失を過小に見せます。Google が売上を取り消すとき、あなたは価格を返します。それが目に見える数字です。それが請求の全部ではありません。

購入された瞬間に本物の作業を引き起こす消費型アイテムを考えてみてください。まとまった画像生成、モデルプロバイダーの API への一連の呼び出し、動画のエクスポート、クリエイターへの支払い。あなたはその計算資源、それらの API 呼び出し、そのストレージ、それらの支払いを使用時に支払いました。返金は販売価格を顧客に返します。それはプロバイダーの請求書をあなたに返しません。あなたは本物のコストを届け、その見返りに何も得られませんでした。

サブスクリプションとトライアルの場合、損失は決して回収しない最初の請求と、始まる前に終わった顧客関係です。そして 2026 年 8 月 3 日から、Google Play はその日以降に発注された注文について、チャージバックの購入価格と銀行手数料を開発者に転嫁します。これは、避けられる売上漏れをすべて、後回しにせず今すぐ塞ぐ価値があるものにします。未確認による返金はチャージバックではありませんが、同じ教訓です。すでに費やしたお金は、自動的に手元に残るお金ではありません。

Google Play の購入をサーバー側で確認する方法

信頼できるパターンは、アプリをクリティカルパスから外すことです。バックエンドで、通知に駆動されて行い、ユーザーが画面を開き直すことに駆動されないようにします。

• Real-time developer notifications をリッスンします。ONE_TIME_PRODUCT の購入や SUBSCRIPTION_PURCHASED イベントは、アプリが開いているかどうかに関わらず、Google が知った瞬間に購入が存在することをサーバーに伝えます。
• Play Developer API に対して購入トークンを検証し、状態が PENDING ではなく PURCHASED であることを確認します。
• ユーザーをキーとして、自分の記録の中で権利を付与します。
• ただちに確認または消費します。消費型アイテムは消費し、非消費型アイテムと最初のサブスクリプションは確認します。二度確認しないよう、先に acknowledgementState を確認します。
• クライアント側でも埋め合わせます。onResume() で queryPurchasesAsync() を呼び、アプリが閉じている間に完了した購入も処理されるようにします。これはセーフティネットであり、主経路ではありません。

要点は、確認は Google があなたに送るイベントから発火するのであって、あてにできないユーザーの操作から発火するのではない、ということです。購入して二度と戻ってこないユーザーは完全にカバーされます。あなたのサーバーが購入が着地した瞬間に動いたからです。

滑り抜けたものを拾う照合の網

きれいなパイプラインでも、チェックから恩恵を受けます。Voided Purchases API は返金、取り消し、チャージバックされた購入を一覧にし、理由が購入が「開発者によって一度も確認されず、したがって開発者の記録に存在しないかもしれない」というケースを名指しします。それをポーリングすれば、Google がすでに巻き戻したものに対して付与した権利を取り消せます。制限に注意してください。この API は過去 30 日間の無効化された購入しか返さないので、照合は四半期に一度ではなく、スケジュールに沿って実行しなければなりません。

Apple には対応する仕組みがなく、それが重要だ

これは特に Google Play の問題です。Apple の StoreKit にも完了ステップ、つまりトランザクションの完了がありますが、失敗時には逆のことをします。StoreKit トランザクションを完了しないと、Apple はそれをキューに保持し、アプリが起動するたび、あるいはオブザーバーがアタッチするたびに再配信するので、権利を付与する別の機会が得られます。Apple は完了していないトランザクションを返金しません。App Store には三日間の自動返金はありません。

だからメンタルモデルはプラットフォーム固有のままでなければなりません。Google Play では、処理されていない購入は起きるのを待っている返金であり、あなたが競争している期限です。App Store では、処理されていない購入は起きるのを待っている再配信であり、カウントダウンはまったくありません。Apple の前提を Android に持ち込むことこそ、チームが説明のつかない未確認返金の壁を抱え込む原因です。

だからこそ RefundHalt は、ストアの通知が届いた瞬間に Google Play の購入を自動的に確認し、Voided Purchases API と照合して、Google が後に巻き戻した購入に対して付与された権利が有効なまま残らないようにします。三日ルールは、負けうるレースであることをやめ、すでに済んだステップになります。