購入が成立し、顧客は商品を受け取りますが、3日後にはそれが消えてしまいます。顧客が申し出たわけでも、サポートチームの誰かが操作したわけでもなく、Google Playが課金を取り消し、権利を剥奪するのです。購入は静かに失敗していました。サーバーが処理済みであることをGoogleに伝えていなかったためです。
ルールはこれだけです。Google Playの購入は3日以内に確認（acknowledge）しなければ、Googleが自動的に返金し、取り消します。例外は一切ありません。どちらのストアでも売上が取り消される要因はいくつもありますが、その中でこれは完全に自社の実装の内側で発生する、数少ないケースのひとつであり、それゆえに最も静かに収益を失う原因のひとつでもあります。
不正チェックでもなければ、ポリシー上の判断でもありません。発火しなかったコールバックが原因です。修正自体は小さなものですが、それを怠って失う金額は決して小さくありません。だからこそ、このルールが正確に何を求めているのか、購入がなぜこのルールをすり抜けてしまうのか、そして消えた売上ひとつひとつが何を一緒に引き倒していくのかを、正確に知っておく価値があります。
Googleのドキュメントが実際に求めていること
Play Billingでは、アプリが権利を付与し、購入が完了したことをユーザーに伝えた後、その旨をGoogleに通知する必要があります。Googleのドキュメントはこれに明確な期限を定めています。この通知は「購入が自動的に返金され、権利が取り消されないように、3日以内に行う必要がある」とされています。単発商品（one-time product）に関するドキュメントも、まったく同じ内容を曖昧さなく繰り返しています。確認を怠れば、「ユーザーは自動的に返金を受け、Google Playは購入を取り消す」のです。サブスクリプションの初回購入にも、まったく同じルールが適用されます。
確認は単なる事務手続きではありません。商品が実際に届いたことをGoogleが知るための唯一の信号です。その信号がなければ、Googleは何も提供されなかったとみなし、あなたに相談することなく、購入者に対する取引全体を取り消します。購入者には予期しない返金が表示されます。あなたの帳簿からは、売上がひとつ消えているのです。
重要なポイント
売上を72時間確認せずに放置すると、取り消しは自動的に発生します。購入者への返金、権利の剥奪、いずれも誰にも相談なく行われます。これは購入者が引き起こしたことではありません。あなたのバックエンドが何も伝えなかったことが原因であり、同じバックエンドがそれを防ぐこともできるのです。
カウントダウンが始まるのは、購入状態がPURCHASEDに達した時点であり、決済の瞬間そのものは期限とは無関係です。PENDING状態にとどまっているものにはタイマーが付いておらず、まだ確認コールを送るべきではありません。
この義務を果たすには、2種類の呼び出しのいずれかを使います。消費型（consumable）商品にはpurchases.products.consumeを実行し、それ以外にはpurchases.products.acknowledgeまたはpurchases.subscriptions.acknowledgeを使います。Googleはどちらも、商品が届いた証拠として扱います。
サブスクリプションでこれが求められるのは、申し込み時のちょうど1回だけです。それ以降の課金サイクルはすべてGoogle自身が処理し、あなたのコードが何もしなくても確認済みとしてマークされます。
7日未満のプリペイドプランを販売している場合、許容時間はプランの期間の50%まで短縮されます。商品の期間が短いほど、導火線も短くなります。
購入者に戻るのは、商品の価格だけです。コンピューティング時間、モデルAPIの利用料、ストレージ費用、クリエイターへの支払いなど、提供時にすでにあなたのアカウントから出ていったお金は一切戻ってきません。実際の損害は、返金額の記録をはるかに超えています。
iOSではこのような仕組みはまったくありません。StoreKitは未完了のトランザクションを起動のたびに再提示し、課金を取り消すことなく、気長に待ち続けます。このリスクはGoogle Playだけに存在し、他のどこにもありません。
決済の瞬間が期限の起点ではない
「購入」をタップしただけでは、タイマーは始まりません。購入状態がまずPURCHASEDに遷移する必要があり、それ以前にPENDING状態にとどまる購入もあります。現金による支払い方法や、処理の遅い銀行振込、保護者の承認待ちリクエストなどがこれに該当します。Googleは次のように明言しています。「3日間の確認期間は、購入状態がPENDINGからPURCHASEDに遷移したときにのみ開始される」。
これはフローの構築において、2つのことを意味します。権利を付与するのは状態がPURCHASEDになってからであり、PENDINGの時点では決して付与してはいけません。そうしなければ、実際には受け取れないかもしれないお金に対して商品を渡してしまうことになります。同様に、PENDING状態の購入を確認してもいけません。まだ確認すべきものが存在しないからです。BillingClientを設定する際にenablePendingPurchases()を呼び出し、状態の遷移を待ち、PURCHASEDに達した時点でのみカウントを開始してください。
PENDINGは「まだ販売されていない」と読み替えてください。権利も確認も発生せず、売上として記帳するものも何もありません。PURCHASEDに切り替わった瞬間から、権利と3日間のカウントダウンの両方が、あなたの責任となります。
販売した商品に応じて正しいAPI呼び出しを選ぶ
期限を満たすAPIの方法は2つあり、どちらを使うかは販売した商品によって決まります。いずれの方法も要件を同等に満たします。両者の違いは、その後に商品に対して何が起こるかという点です。
消費型商品は消費（consume）されます。これはセキュアなバックエンド側でのpurchases.products.consume、またはクライアント側のPlay Billing Libraryが提供するconsumeAsync()によって行われます。消費には二重の役割があり、確認要件を満たすと同時に、その商品を再び購入可能な状態に戻します。コインやクレジット、顧客が繰り返し購入する可能性のある単発生成アイテムなどには、この方法が適しています。
非消費型商品とサブスクリプションは、代わりに確認（acknowledge）されます。これはpurchases.products.acknowledge、purchases.subscriptions.acknowledge、またはクライアント側のacknowledgePurchase()によって行われます。これにより期限は満たされますが、その商品が再購入可能になるわけではありません。
各商品タイプがどの呼び出しと期限に対応するかは、以下のとおりです。
消費型商品の場合は、purchases.products.consumeまたはconsumeAsync()を呼び出します。これにより商品は再び購入可能になり、期限はPURCHASEDから3日です。
非消費型商品の場合は、purchases.products.acknowledgeまたはacknowledgePurchase()を呼び出します。権利は確認されますが再購入にはならず、期限はPURCHASEDから3日です。
サブスクリプションの初回購入の場合は、purchases.subscriptions.acknowledgeまたはacknowledgePurchase()を呼び出します。これにより新しいサブスクリプションが確認され、期限はPURCHASEDから3日です。
サブスクリプションの更新の場合は、呼び出しは一切必要ありません。Googleが自動的に確認済みとマークするため、期限そのものが存在しません。
1週間未満のプリペイドプランの場合は、同じ確認呼び出しを使用しますが、期限はプラン期間の半分に短縮されます。
この義務は最初の支払いで終わる
サブスクリプションの更新には、確認は一切必要ありません。Googleは明確にこう述べています。「サブスクリプションの更新を確認する必要はない」とし、それぞれを自動的に確認済みとマークします。確認待ちの状態で届き、処理するまであなたの手元に残るのは、サブスクリプションの最初の購入だけです。何か操作を行う前に、サーバー側で確認状態を確認するか、クライアント側でisAcknowledged()を使用してください。そうすることで、確認コールを重複して送信することを防げます。
短期プリペイドプランではより短い期限
1週間以上のプリペイドプランは、通常の3日ルールに従います。それより短いプランは異なります。Googleのドキュメントには、「期間が1週間未満のプランは、プラン期間の半分以内に確認しなければならない」と記載されています。3日間のプリペイドプランであれば、与えられるのは1.5日間であり、通常の期間全体ではありません。短期のプリペイドチャージが商品カタログに含まれている場合、確認処理は迅速かつサーバー主導である必要があり、顧客がアプリを再度開くことに依存してはいけません。
確認コールが見失われがちな場所
このステップを意図的に飛ばす人はいません。確認処理が間違ったトリガーに結び付けられているために、見失われてしまうのです。よくあるアンチパターンは、購入フローがフォアグラウンドに戻ったときにのみ確認を行うクライアントです。これは、購入を完了した直後もアプリを使い続ける顧客にはうまく機能しますが、それ以外の誰にも機能しません。
開発者はこの問題に絶えず遭遇しています。Google自身の開発者コミュニティのスレッドは毎回同じ筋書きをたどります。ユーザーが購入から3日後に自動的に返金されたという報告、あるいは支払いが3日目になると自動的に取り消され続ける理由を知りたいという訴えです。原因の診断はほとんど変わりません。確認コールが、実際には起こらないユーザーの操作に結び付けられていたために、単純に発火しなかったのです。
無料トライアルと、二度とアプリを開かない顧客
この問題の最も厄介なパターンは、無料トライアルや、誰かがあなたのアプリを最後に閉じる直前の瞬間に行われた購入です。確認が次回のアプリ起動を待っていて、その次回の起動が二度と来ない場合、購入は期限切れになるだけです。Googleは3日目にそれを返金し、取り消します。有料転換に向かっていたはずのトライアルでは、本来課金できたはずの最初の支払いを失い、それと同時に顧客の権利も静かに消え去ります。どちらもサポートの問い合わせには現れません。両方とも、探しに行けば「無効化された購入」として現れるだけです。
次回のアプリ起動に依存する確認は、顧客が3日間アプリから離れるたびに失っている売上です。トライアルやワンタップ購入は、まさに顧客がアプリから離れがちなタイミングなのです。
確認漏れによる返金の本当のコスト
返金額の記録は、実際に失ったものを過小に表しています。Googleが売上を取り消し、あなたは価格を返金します。誰もが目にするのはその数字です。しかし、それは全体のコストではありません。
誰かが購入した瞬間に実際の処理が始まる消費型商品を例に考えてみましょう。画像生成のバッチ処理、モデルプロバイダーのAPI呼び出し、動画のエクスポート、クリエイターへの支払いなどです。あなたはその利用時点で、コンピューティング、APIコール、ストレージ、支払いに対してすでにお金を払っています。返金は顧客に対して販売価格を戻すだけであり、プロバイダーからの請求書をあなたに戻してはくれません。実際のコストはすでに出ていき、それに対して何も戻ってこないのです。
サブスクリプションとトライアルの場合、損失は回収できなかった最初の課金と、始まる前に終わった顧客関係です。そして、リスクはこれから高まろうとしています。2026年8月3日以降、Google Playはその日以降に発生した注文について、チャージバックの購入金額と銀行手数料を開発者側に転嫁するようになります。これにより、回避可能な漏れは今すぐ、後回しにせずに塞いでおく価値があります。確認漏れによる返金はチャージバックではありませんが、同じ教訓を教えてくれます。すでに使ったお金は、自動的に自分の手元に残るお金ではないということです。
確認ステップを、見逃しようのない形で組み込む
信頼できるパターンは、アプリをクリティカルパスから完全に外すことです。誰かが画面を再度開くかどうかではなく、通知によって駆動される形で、バックエンド側で処理してください。
リアルタイム・デベロッパー通知（real-time developer notifications）を購読します。単発商品の購入イベントやサブスクリプションの購入イベントは、アプリが実行中かどうかにかかわらず、Googleが売上を記録した瞬間にあなたのサーバーに届きます。
Play Developer APIを通じて購入トークンを検証し、状態がPENDINGではなくPURCHASEDになっていることを確認します。
その顧客のアカウントに紐づけて、権利を自社のシステムに記録します。
遅延なく消費または確認を行います。消費型商品は消費し、非消費型商品とサブスクリプションの初回購入は確認します。呼び出しが二重に送信されないよう、まず確認状態を読み取ってください。
クライアント側のバックフィル処理も維持してください。onResume()内でqueryPurchasesAsync()を呼び出すことで、アプリが閉じている間に確定した購入を取り込めます。これは主経路ではなく、保険として扱ってください。
ここで重要なのは、確認がユーザーの操作という保証できないものではなく、Googleから渡されるイベントを起点として発火することです。一度だけ購入して二度と戻ってこない顧客であっても、購入が成立した瞬間にサーバー側が既に処理を済ませているため、完全にカバーされます。
それでも漏れたものに対する最後の備え
パイプラインがどれほどしっかり構築されていても、その下にはなお安全網が必要です。GoogleのVoided Purchases APIは、返金、取り消し、チャージバックに終わった注文を列挙し、その原因が「開発者によって確認されなかったため、開発者側の記録に存在しない可能性がある」購入であった特定のケースを明確に示します。これを一定のリズムで照会すれば、Googleが裏側で静かに取り消していた注文のアクセス権を剥奪できます。ただし境界には注意してください。取得できるのは直近30日分だけであり、だからこそこれは四半期ごとに気が向いたときに対応するものではなく、スケジュール化されたジョブとして運用すべきです。
iOSは、そもそもこのような仕組みではない
App Storeに話を移すと、こうした仕組みはまったく当てはまりません。Appleにも独自の完了ステップ、つまりトランザクションの完了（finishing a transaction）がありますが、それを怠った場合のペナルティは正反対の方向に働きます。未完了のトランザクションはAppleのキューにとどまり続けます。アプリを起動するたびに、またオブザーバーが接続されるたびに再び現れ、顧客が支払った商品を届けるための機会を何度も与えてくれます。Appleはそれに対して取り消しを行いません。72時間で発動する返金のトリガーのようなものは、このプラットフォームには存在しません。
だからこそ、ひとつの考え方を両方のストアにそのまま当てはめることはできません。Androidが与えてくれるのはカウントダウンと、それを逃せば消えてしまう売上です。iOSが与えてくれるのは、繰り返される通知と、それに応答するための無制限の時間です。iOSの習慣をAndroidのコードベースに持ち込めば、やがてチームの誰も説明できない、取り消された注文の山を前にすることになります。
このギャップを塞ぐのが、まさにRefund Sensorの役割です。確認はストアからの通知を受け取った瞬間にそのまま発火し、同時にVoided Purchases APIに対する常時の照合処理が、Googleが裏側で既に取り消していた注文のアクセス権を取り除きます。見逃しかねないカウントダウンは、確認しようと考える前にすでにチェックが済んだ項目へと変わります。
これらのルールが記載されている場所
よくある質問
サーバーが確認コールを期限内に送信しなかったためです。購入がPURCHASEDに達してから3日間、確認されない状態が続くと、Googleは自動的に売上を取り消し、権利を剥奪します。これは顧客が何かをしたからでも、Googleが課すペナルティでもありません。確認コールが送られていなかったことが原因であり、ストアからの通知を起点にサーバー側で確認を行えば、この問題は完全に解消します。
どちらも3日間のタイマーを止めますが、商品を異なる状態に置きます。消費（purchases.products.consumeまたはconsumeAsync()）は消費型商品向けです。期限を満たすと同時に、その商品を再び販売可能な状態に戻します。確認（purchases.products.acknowledge、purchases.subscriptions.acknowledge、またはacknowledgePurchase()）は非消費型商品とサブスクリプション向けです。権利を確認しますが、商品を再購入可能にはしません。
いいえ、必要なのは最初の購入だけです。Googleは更新を確認することを求めておらず、自動的に確認済みとしてマークします。確認待ちの状態で届き、処理するまであなたの責任として残るのは、サブスクリプションの初回購入だけです。
いいえ、PURCHASEDになるまで待ってください。現金払いや保護者の承認待ちリクエストのようなPENDING状態の購入では、3日間のタイマーはまだ始まっていません。状態が実際にPENDINGからPURCHASEDに移ってから、権利を付与し、確認を送信してください。
ありません。AndroidとiOSが同じように動作すると思い込む前に、これは知っておく価値があります。未完了のStoreKitトランザクションは、完了するまでアプリを起動するたびに再配信されるだけです。Appleは自動的に返金することは決してありません。3日間の自動返金はGoogle Play特有の仕組みであり、2つのプラットフォームは異なる対応が必要です。
返金そのものを取り消すことはできません。できるのは、照合（reconcile）することです。Voided Purchases APIは、過去30日間に返金または取り消しとなった購入を表示し、特に確認されなかったことが原因で無効化されたものにフラグを付けてくれるため、付与していた権利を取り消すことができます。今後については、ストアからの通知を起点に確認を行うことが、次の購入を取りこぼさないための方法です。
