簡単な答え: 顧客がアプリ内購入やサブスクリプションについてAppleに返金を求めると、App StoreはあなたのサーバーにCONSUMPTION_REQUEST通知を送信し、Send Consumption Informationエンドポイントを通じて消費情報を返信するための猶予として、およそ12時間を与えます。Appleはその判断においてこのデータを考慮します。期限内に応答しなければ、Appleはあなたの情報なしに判断を下すことになり、不当な返金リクエストもデフォルトで承認されることが少なくありません。この応答を自動化すれば、あらゆるリクエストに対して常に期限内に回答できるようになります。
要点まとめ
Appleは決済インフラを保有しています。ユーザーがあなたのアプリ内でサブスクリプションやアプリ内購入を行うと、Appleが代金を回収し、その一部を手数料として受け取り、返金処理も行います。長年、開発者は返金の判断に一切関与できませんでした。
その状況は変わりました。現在Appleは、顧客が購入したものをどのように利用したかを示す構造化された証拠である消費情報を送信できるようにし、それを返金の判断材料としています。返金を自分で承認したり却下したりできるわけではなく、最終判断は今もAppleが下します。しかし、何も応答しなければAppleには判断材料が何もない状態になり、適切に構成された応答はAppleに文脈を提供することになります。
課題となるのはタイミングと一貫性です。応答可能な時間は短く、しかもいつ発生するか予測できません。実際の運用規模で手作業に対応するのは不可能です。これこそがApple返金自動化が解決する課題です。
Appleの返金フローの実際の仕組み
一連の流れは次のとおりです。
顧客が返金をリクエストする。 顧客はreportaproblem.apple.comにアクセスし、購入内容を選択して理由を選び、申請を送信します。
Appleがサーバーに通知する。 対象となる購入について、App StoreはApp Store Server Notifications V2を通じてCONSUMPTION_REQUEST通知を送信します。ペイロードには、購入を特定する署名付きトランザクションデータが含まれています。この app store server notifications が自動化ワークフローの起点となります。
消費情報で応答する。 元のトランザクションIDと、配信状況・利用状況・同意・返金に関する希望を記述した構造化されたConsumptionRequestボディを添えてSend Consumption Informationを呼び出します。この send consumption information エンドポイントが、このプロセスにおける重要なAPIステップです。
Appleが判断する。 Appleの返金判断システムは、送信されたデータを顧客の履歴やその他の要因と併せて考慮したうえで、判断を下します。
結果が通知される。 REFUND通知は返金が承認されたことを、REFUND_DECLINED通知(StoreKit API経由で開始されたリクエストの場合)は承認されなかったことを意味します。
CONSUMPTION_REQUESTに含まれる情報と、それに対して送り返す情報
通知そのものには、署名付きトランザクション情報と顧客が申告した理由(consumptionRequestReason)が含まれています。実際に重要な作業が発生するのは、あなたの応答のほうです。Appleは、次のようなフィールドを含む構造化されたConsumptionRequestを定義しています。
フィールド | Appleに伝わる内容 |
customerConsented | 顧客がこのデータの共有に同意したかどうか。trueでなければAppleは送信を拒否します。 |
consumptionStatus | 購入したコンテンツが未消費、一部消費、または完全に消費されたかどうか。 |
deliveryStatus | アプリ内の価値やサービスが実際に提供されたかどうか。 |
accountTenure | 顧客がアカウントを保有している期間。 |
playTime | 顧客がアプリ内で費やした時間。 |
lifetimeDollarsPurchased | 顧客があなたのアプリ全体で支払った合計金額。 |
lifetimeDollarsRefunded | これまでに顧客へ返金された合計金額。 |
sampleContentProvided | 顧客が購入前にコンテンツを試すことができたかどうか。 |
userStatus | 顧客アカウントの現在のステータス(有効、停止中など)。 |
refundPreference | Appleへの推奨内容:未申告、承認を推奨、却下を推奨のいずれか。 |
各フィールドは一つのシグナルです。空欄のままにすると、Appleはその文脈を一切得られません。すべてのフィールドと使用できる値については、What Is a CONSUMPTION_REQUEST Notification? A Field-by-Field Breakdownで詳しく解説しています。apple refund api の導入を検討している開発者は、これらのフィールドが返金ワークフロー全体の中でどのように位置づけられるかも理解しておく必要があります。
12時間の応答期限
本番環境では、CONSUMPTION_REQUESTへの応答に約12時間の猶予があります。この期限を逃すと、情報を提供する機会を失い、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がペイロードやフィールドを変更するたびに必要となる継続的なメンテナンスも必要です。これらはどれもあなたのプロダクトそのものではありません。アプリの本来の機能とは無関係なワークフローのために、無期限に保有し続けることになるインフラです。(通知レイヤーについてはSetting Up App Store Server Notifications V2でさらに詳しく解説しています。)
結局のところ、多くのチームがたどり着く結論はこうです。仕組み自体を理解することはできても、コンプライアンスを満たし、期限を確実に守る応答システムを構築し、面倒を見続けることは、アプリ本体には何の利益ももたらさない恒常的なコストになるということです。これはまさに、マネージドサービスが本来担うべき、差別化にならない裏方の作業です。
それを実現するのがRefundSensorです。App Store Connectの設定に、1つのwebhook URLを設定するだけで接続できます。SDKも不要、コード変更も不要、アプリの再申請も不要です。そのうえで、すべてのCONSUMPTION_REQUESTをApple指定の期限内に自動で応答し、あなたのデータからフィールドをマッピングし、再試行と監視を処理し、Appleの仕様変更にも常に対応し、すべての結果を1つのdashboardに記録します。応答システムを自分で構築・維持することなく、しっかり作り込まれた応答システムと同じ成果が得られます。Apple返金自動化ソフトウェアを探しているチームにとって、これは社内でワークフローを維持する代わりとなるマネージドサービスの選択肢です。
応答することで実際に返金は減るのか
はい、減ります。ただし結果はケースによって異なり、最終判断は常にAppleが行います。正確な消費情報を送信することで、Appleのシステムはより多くの文脈を得られるようになり、一貫して応答している開発者は、リクエストに応答しない開発者と比べて、返金が承認される割合が一般的に低くなる傾向があります。証拠が本当に裏付けとなる場合に「却下を推奨(prefer decline)」を選択することも、Appleが考慮するもう一つの判断材料になります。これは、大規模にサブスクリプション返金ワークフローを管理する場面で特に重要になり得ます。
自動化にできること・できないこと
自動化の限界について、正直に理解しておきましょう。
できないこと: 特定の返金が却下されることを保証することはできません。最終判断は常にAppleが行います。
できないこと: CONSUMPTION_REQUESTが発生しない返金については争うことができません。すべての返金でCONSUMPTION_REQUESTが発生するわけではありません。
できること: 対象となるすべてのリクエストに対して、一貫した正確なデータで期限内に確実に応答できます。そのため、誰も通知に気づかなかったという理由だけで返金を失うことがなくなります。
最後のポイントこそが本質です。Appleの判断を覆しているのではなく、自分の意見を伝える機会を毎回確実に得られるようにしているのです。
詳細については、Apple公式の資料を最終的な拠り所としてください。
業界は15年をかけて、開発者が返金について発言できる権利を勝ち取ってきました。その権利は毎回きちんと使いましょう。RefundSensorは、AppleのCONSUMPTION_REQUEST通知に対して期限内に自動で応答し、AppleとGoogle Playの両方について、すべての結果を記録します。無料で始める
よくある質問
顧客が対象となるアプリ内購入またはサブスクリプションの返金をリクエストした際に、Appleがあなたのサーバーに送信するApp Store Server Notificationです。Appleが返金の判断で考慮する消費情報を返信するタイミングを知らせる合図となります。
本番環境では約12時間です。期限内に応答しない場合、Appleはあなたの情報なしに判断を下し、未応答のリクエストはデフォルトで承認されることが少なくありません。
いいえ、できません。却下を推奨するrefundPreferenceを送信することはできますが、最終判断は常にAppleが行います。自動化は、常に正確なデータを送信することで可能性を高めるものであり、拒否権を与えるものではありません。
はい、必要です。アプリ内で有効な同意を取得し、customerConsentedをtrueに設定する必要があります。Appleがこれを代わりに取得してくれることはなく、同意なしにデータを送信すると、あなた自身が責任を負うプライバシーコンプライアンス上のリスクが生じます。
いいえ、不要です。CONSUMPTION_REQUESTへの応答は、App Store Server NotificationsとConsumption APIを通じてサーバーサイドで行われます。RefundSensorを使えば、App Store Connectに1つのwebhook URLを貼り付けるだけで済み、SDKもコード変更も再申請も必要ありません。
Appleはあなたのデータなしで処理を進めます。文脈を提供できる唯一の機会を失い、不当なものを含め、返金が承認される可能性が高くなります。
