Appleの返金12時間ウィンドウ:多くの開発者がデフォルトで返金を失ってしまう理由

簡単に言うと: 顧客がアプリ内購入やサブスクリプションの返金をAppleに申請すると、App StoreはあなたのサーバーにCONSUMPTION_REQUEST通知を送信し、Send Consumption Informationエンドポイントを通じて消費データを送信するまで約12時間の猶予を与えます。Appleはその判断にこのデータを考慮します。期限内に対応しないと、Appleはあなたの情報なしで判断を下し、正当性のない返金であってもデフォルトで承認されることがよくあります。この対応を自動化すれば、毎回すべてのリクエストがウィンドウ内で確実に処理されます。

要点まとめ

決済のインフラはAppleが握っています。ユーザーがあなたのアプリでサブスクリプションやアプリ内購入を行うと、Appleが代金を回収し、手数料を差し引き、返金処理も担当します。長年、開発者は返金の判断に一切関与できませんでした。

その状況は変わりました。現在Appleは、顧客が購入したものをどのように使用したかを示す構造化されたエビデンス「消費情報」の送信を開発者に認めており、これを返金の判断材料としています。返金の承認・却下を開発者自身が決めることはできず、最終判断はあくまでAppleが行います。しかし、何も応答しなければAppleが判断材料を得られない一方、しっかりとした応答をすればコンテキストを提供できます。

問題はタイミングと一貫性です。返金ウィンドウは短く、Appleの返金対応時間には限りがあり、しかもいつ開くか予測できません。ある程度の件数を手動でこなすのは不可能です。これこそが自動化によって解決できる問題です。

Appleの返金フローの実際の仕組み

一連の流れは次のとおりです。

1. 顧客が返金をリクエストする。 顧客は reportaproblem.apple.comにアクセスし、購入内容を選択し、理由を選んで送信します。

2. Appleがあなたのサーバーに通知する。 対象となる購入について、App StoreはApp Store Server Notifications V2を通じてCONSUMPTION_REQUEST通知を送信します。このペイロードには、購入内容を特定する署名付きトランザクションデータが含まれています。

3. 消費データで応答する。 元のトランザクションIDと、提供状況・利用状況・同意状況・返金に関する希望を記述した構造化されたConsumptionRequestボディを使って、Send Consumption Informationを呼び出します。

4. Appleが判断を下す。 Appleの返金判断システムは、提供されたデータと顧客の履歴やその他の要因を総合的に評価し、判断を下します。

5. 結果が通知される。 REFUND通知は返金が承認されたことを意味し、REFUND_DECLINED通知(StoreKit API経由で開始されたリクエストの場合)は却下されたことを意味します。

CONSUMPTION_REQUESTに含まれる情報と、返送する内容

通知自体には署名付きトランザクション情報と、顧客が申告した理由(consumptionRequestReason)が含まれています。実質的な作業はあなたの応答部分で発生します。Appleは以下のようなフィールドを含む構造化されたConsumptionRequestを定義しています。

以下は、画像から再構成したテーブルです。

Appleへの推奨:undeclared(未申告)、prefer grant(承認を推奨)、prefer decline(却下を推奨)のいずれかです。

それぞれのフィールドが一つのシグナルです。空欄のままにすると、その分のコンテキストは決してAppleに伝わりません。すべてのフィールドと許容値については、「What Is a CONSUMPTION_REQUEST Notification? A Field-by-Field Breakdown」で詳しく解説しています。

12時間のウィンドウ

本番環境では、CONSUMPTION_REQUESTへの対応時間は約12時間です。このconsumption_requestの期限は非常に重要で、これを逃すと情報を提供する機会を失い、Appleはすでに持っている情報だけで判断を下します。

問題はAppleの返金対応ウィンドウの長さではなく、いつ開くかという点です。返金リクエストは営業時間を待ってはくれません。返金ウィンドウは深夜、週末、休日にも開く可能性があり、常に誰かが待機していない限り、手動のレビュー体制ではカバーしきれません。これこそが、開発者が異議を申し立てられたはずの返金を失う最も一般的な理由です。応答の内容が悪かったのではなく、応答そのものがなかったのです。詳しくは「The 12-Hour Window: Why Most Developers Lose Refunds by Default」で解説しています。

同意要件は絶対に省略できません

ここはほとんどの人がつまずくポイントであり、単なる技術的な問題ではなく法的な問題でもあります。

AppleのCONSUMPTION_REQUESTは、顧客がデータ共有に同意したかどうかを伝えてはくれません。これは意図的な仕様であり、Appleはサーバー側ではなくアプリ側で、消費データを送信する前に同意を取得・確認することを想定しています。API呼び出しではcustomerConsentedをtrueに設定する必要があり、有効な同意を取得しておく責任は開発者であるあなた自身にあります。なぜなら、ユーザーから収集したデータを共有するのはあなただからです。

これを誤ると、送信が拒否されるだけでなく、GDPRやDPDPのコンプライアンス違反というリスクも生じます。何かを自動化する前に、アプリの利用規約と購入フローの中で同意を適切に処理してください。具体的にどこで、どのように対応すべきかは「Customer Consent & the Consumption API: What Apple Actually Requires」で詳しく解説しています。

これを自動化するために実際に必要なこと

理屈の上では、応答の自動化は週末で終わる程度のプロジェクトに聞こえます。通知を受け取り、フィールドを埋め、エンドポイントを呼び出すだけです。しかし本番環境では、これは常時稼働するインフラストラクチャであり、実際に何が必要になるかを理解しているかどうかが、「自分たちで構築する」か「やめておく」かの分かれ目になります。

信頼できる自社製の応答システムを構築するには、Appleの署名付き通知を受信・検証し、リクエストが届いた瞬間に各顧客の正確かつ最新の利用状況や請求データを取得し、そのデータをAppleが定めるConsumptionRequestの正確な値にマッピングし、誰も見ていない状態でも、時間帯を問わず約12時間のApple返金対応ウィンドウ内に送信する必要があります。さらに、期限を確実に守るためのリトライ処理、失敗時のハンドリング、監査可能なログ、障害を検知するための監視、そしてAppleがペイロードやフィールドを変更するたびに発生する継続的なメンテナンスも必要です。これらはどれもあなたのプロダクトそのものではありません。すべては、アプリの機能とは無関係なワークフローのために、あなたが半永久的に保有し続けることになるインフラです。(通知レイヤーについては「Setting Up App Store Server Notifications V2」でさらに詳しく解説しています。)

これが、多くのチームが最終的に行き着く計算です。仕組み自体は理解できるものの、コンプライアンスに準拠し、期限を確実に守る応答システムを構築・維持し続けることは、アプリ自体には何のメリットももたらさない恒久的なコストになります。これはまさに、マネージドサービスが担うべき、差別化にならない「配管」のような作業です。

それを実現するのがRefundSensorです。App Store Connectの設定に、1つのwebhook URLだけで組み込むことができ、SDKも不要、コード変更も不要、アプリの再申請も不要です。その上で、Appleの返金ウィンドウ内にすべてのCONSUMPTION_REQUESTへ自動で応答し、あなたのデータからフィールドをマッピングし、リトライと監視を処理し、Appleの変更に常に対応し続け、すべての結果を1つのdashboardに記録します。Apple返金自動化ソフトウェアを探しているチームにとって、これにより返金応答インフラ全体を自社で構築・維持する必要がなくなります。

実際に応答することで返金は減るのか

減ります。ただし結果はケースバイケースで、最終判断は常にAppleが行います。正確な消費データを送信することで、Appleのシステムはより多くのコンテキストを得られます。一貫して応答している開発者は、リクエストを放置している開発者に比べて、承認される返金の件数が概して少なくなる傾向があります。エビデンスが実際にそれを裏付ける場合に「prefer decline(却下を推奨)」を選択することも、Appleが考慮する材料の一つになります。

したがって、Appleの返金対応時間内に応答することで、consumption_requestの期限までにあなたの情報がAppleに確実に届くようになります。結果を保証するものではありませんが、応答漏れが原因であなたの情報が考慮されなかった、という事態を防ぐことができます。

自動化にできること、できないこと

その限界について、正直に理解しておく必要があります。

• 特定の返金が却下されることを保証することはできません。最終判断は常にAppleが行います。

• CONSUMPTION_REQUESTが発生しない返金には異議を申し立てることができません。すべての返金でCONSUMPTION_REQUESTが発生するわけではないためです。

• 対象となるすべてのリクエストに対し、Appleの返金対応ウィンドウ内で一貫した正確なデータをもって確実に応答できるため、通知に誰も気づかなかったという理由だけで返金を失うことがなくなります。

• Appleの返金リクエストに12時間以内で対応する方法を自動化し、consumption_requestの期限を逃すリスクを減らすことができます。

最後のポイントこそが最も重要です。Appleの判断を覆すのではなく、常に自分が発言する機会を確実に得られるようにすることなのです。

手動対応ではギャップを埋められない理由

これを手動で処理しようとするチームは、たいてい次の3つのいずれかに行き着きます。

• 「朝になったら確認する」というアプローチ — これでは深夜や週末に届くすべてのリクエスト、つまりかなりの割合を取りこぼしてしまいます。

• オンコール体制 — 24時間体制で12時間ウィンドウのタスクに責任を持つ担当者を置く方法です。過酷な仕事であるうえ、人間である以上ミスも起こり得ます。

• 「もう諦めた」というアプローチ — 対応を維持するのが不可能だったために応答を止めてしまった、静かなる多数派です。

共通しているのは、期限は機械のスピードで進むのに、応答は人間のスピードでしか行われないという点です。あなたが眠っている間も進み続ける時計に、規律だけで打ち勝つことはできません。手動でのアプローチは結局のところ、どのリクエストを取りこぼすかを選んでいるにすぎません。

これはプロダクトの問題ではなく、タイミングの問題です

重要な視点の転換はこうです。これらの返金を失うことは、あなたのアプリの何かを物語っているわけではありません。

優れたプロダクトを持ち、満足度の高いユーザーがいて、実質的な返金率が低くても、このウィンドウを通じて収益を失うことがあります。損失は返金が正当かどうかとは関係なく、誰かが応答できたかどうかで決まるからです。これは意外にも良い知らせです。プロダクトの問題を解決するのは難しいものですが、タイミングの問題には明快な解決策があります。それは、時間帯を問わず、即座に応答できる何かを常に用意しておくことです。

実際に解決する方法

機械のスピードで進むウィンドウを閉じることができるのは、機械のスピードで行われる応答だけです。自動化により、CONSUMPTION_REQUESTが届いた瞬間に、正確な消費データとあなたの返金に関する希望をもって、Appleのウィンドウ内で応答が行われます。それは日曜の午前3時であっても、火曜の午後3時であっても同じくらい確実です。

それを実現するのがRefundSensorです。すべての返金リクエストを検知し、ウィンドウ内で自動的に応答し、結果を追跡します。これにより、通知に誰も気づかなかったという理由で返金を失うことは二度となくなります。セットアップにかかる時間は約30分で、コード変更は不要です。また、「いつ開くかわからず、すぐに閉じる」という同じ問題を抱えるGoogle Playのchargeback-reviewウィンドウにも対応しています。(全体像については How to Automate Apple Refund Requestsおよび Google Play Refunds & Chargebacksをご覧ください。)

[プロダクトデータのプレースホルダー Refund Indexが公開されたら、ここに実際のRefundSensorの統計データを挿入してください。例:営業時間外に届くリクエストの割合、または保護された金額など。数値を創作しないでください。]

これはAppleを欺くためのものではありません。ただ、多くの開発者が気づかないまま放棄している「発言の機会」を、常に確実に得られるようにするためのものです。

公式情報源 {#official-sources}

Appleのタイミングやプロセスは変更される可能性があるため、最終的な情報源としては公式ドキュメントを参照してください。

• Send Consumption Information — Apple Developer

• CONSUMPTION_REQUEST notification type — Apple Developer

• Support customers and handle refunds — WWDC21

ウィンドウは、顧客の都合でいつでも開きます。それでも、そこにいてください。 RefundSensorは、すべてのApple返金リクエストに対して、12時間のウィンドウ内 午前3時、週末、祝日を含む 自動で応答し、すべての結果を記録します。セットアップにかかる時間は約30分で、コード変更は不要です。 無料で始める →

公開後に追加する内部リンク:Apple refund automation cornerstone・CONSUMPTION_REQUEST field-by-field・Google Play refunds cornerstone。