ダッシュボードに返金が表示されても、その理由はまったくわかりません。顧客は2週間アプリを使用した後、返金が発生し、それでもアクセス権はそのまま残っていました。あなたには決定権がありませんでした。これが、多くのiOSチームがApple返金プロセスと出会う典型的な形です。事後に、しかも状況を把握できないまま。
Appleがどのように返金を承認または却下するかを理解することは重要です。それが実際の収益を左右するからです。最終判断を下すのはAppleですが、開発者はその判断にデータを提供することができます。しかし、ほとんどのチームはそれを行っていません。防げるはずの損失を減らしたい場合は、まず Apple返金ガイドをご覧ください。その後、実際に判断がどのように下されるのかを読み進めてください。
これは、購入者として返金を受ける方法を説明するガイドではありません。Apple返金承認の仕組みがどのように機能するのか、そして開発者側から何に影響を与えられるのかを解説するものです。
重要なポイント
• App Storeでのすべての購入について、最終的な返金判断を下すのは開発者ではなくAppleです。
• Appleは、取引の詳細、購入履歴、返金履歴を考慮する「Refund Decisioning System（返金判断システム）」を運用しています。
• 対象となる購入については、AppleはCONSUMPTION_REQUESTを送信し、消費データで応答するための12時間を開発者に与えます。
• 期限内に応答しない場合、Appleはデフォルトで返金を承認することが多くなります。
• App Store Server Notificationsが結果を通知します。承認された場合はREFUND、却下された場合はREFUND_DECLINEDです。
• 開発者がコントロールできるのは、証拠の内容と応答の速さです。最終的な判断そのものはコントロールできません。
• 明確な請求内容、正常に機能する製品、迅速なサポートは、そもそも発生する返金リクエストの数を減らします。
ユーザーがApple返金をリクエストするとどうなるのか
顧客がApp Store返金をリクエストすると、そのリクエストは開発者ではなくAppleに送られます。顧客はApple独自の「問題を報告する」フローを使用し、Appleのシステムが審査を開始します。購入の種類が開発者からの入力を必要とするものでない限り、開発者はこのプロセスに関与しません。
受付処理はすべてAppleが行います。顧客は「購入するつもりはなかった」「アプリが動作しなかった」などの理由を選択します。Appleのシステムはその理由を記録し、アカウントや取引について既に把握している情報と照合を開始します。
例。あるユーザーが9.99ドルのコインパックを購入し、1時間プレイした後、誤って購入したと主張して返金を申請したとします。Appleはまずその申し立てを受け取ります。それを開発者が知ることになるかどうかは、製品の種類とAppleが持つシグナルによって決まります。
Appleが返金リクエストを審査する方法
Appleは、取引内容、顧客の購入履歴、過去の返金履歴を考慮する自動システムを通じて返金リクエストを審査します。Appleはこれを公式に「Refund Decisioning System」と説明しています。このシステムは、目の前の1件のリクエストだけでなく、パターン全体を見ています。
消費型の購入やその他一部の種類については、Appleは判断を下す前に開発者に入力を求めることがあります。そのリクエストはCONSUMPTION_REQUEST通知として届きます。その後、開発者にはAppleが申し立てを判断するのに役立つデータを送信するための短い期間が与えられます。
返金リクエストの段階 | Appleが行うこと | 開発者ができること |
顧客がリクエストを提出する | 理由を記録し、審査を開始する | まだ何もない、シグナルは送られない |
対象購入の確認 | 該当する場合はCONSUMPTION_REQUESTを送信する | サーバーで通知を受信する |
証拠提出の期間 | データの到着を最大12時間待つ | APIを通じて消費情報を送信する |
判断 | 履歴、証拠、理由を総合的に考慮する | 何もない、Appleが決定する |
結果の送信 | REFUNDまたはREFUND_DECLINEDを送信する | エンタイトルメントと記録を更新する |
開発者への要点 判断を下すのはAppleですが、CONSUMPTION_REQUESTはそれに影響を与えられる唯一のチャンスです。12時間の期限を逃せば、Appleに渡るのは顧客側の言い分だけになってしまいます。 |
Apple返金承認に影響を与える要因
Apple返金承認は、申告された理由、顧客の履歴、購入がどの程度使用されたか、そして開発者が裏付けとなるデータを送信したかどうかによって左右されます。単一の要因だけで結果が決まることはなく、Appleはこれらを総合的に考慮します。
Apple自身のガイダンスとCONSUMPTION_REQUESTの設計に基づくと、次のシグナルが重要です。
• 顧客が選択した返金理由。
• アカウントの購入・返金履歴。これにより返金を繰り返すユーザーが特定されます。
• 消費型アイテムを顧客がすでにどの程度使用したか。
• 購入前に無料サンプル、トライアル、または明確な機能説明が提供されていたかどうか。
• 開発者が12時間以内に送信する消費データ。
分析。アカウント履歴という要素があるからこそ、初めての購入者と返金を繰り返すユーザーとでは、同じ申し立てに対しても異なる結果になり得ます。これは公式に文書化されたルールではなく、システムの動きを読み解いた見解ですので、確約ではなく傾向として捉えてください。
App Store Server Notificationsが開発者をどう助けるか
App Store Server Notificationsは、返金を含む購入イベントについてAppleが開発者のサーバーに送るメッセージです。これにより、返金が発生したこと、それが承認されたかどうか、そしてその理由を知ることができます。これがなければ、返金はバックエンドから見えないままです。
バージョン2の通知は、それぞれがそのイベントに対応する取引のみを含むため、よりシンプルになっています。返金に関しては、Appleが入力を求める際のCONSUMPTION_REQUEST、返金が承認された際のREFUND、リクエストが却下された際のREFUND_DECLINEDが主な種類です。REFUNDのペイロードにはrevocationReasonとrevocationDateも含まれます。
通常の返金では、 アクセス権が有効なままチャージだけが静かに取り消されることがあります。だからこそ、これらの通知があって初めてサーバー側で対応が可能になるのです。
例。サーバーがrevocationReasonを含むREFUND通知を受信したとします。開発者は元の取引IDを確認し、エンタイトルメントを取り消し、記録を更新します。通知がなければ、これらは何一つ行われません。
開発者がコントロールできること・できないこと
開発者がコントロールできるのは、応答の速さと質、請求内容の明確さ、そして製品の使用体験です。開発者がコントロールできないのは、Appleの最終判断、顧客が申告する理由、そしてAppleの内部スコアリングです。この線引きを理解しておくことで、過度な期待を持たずに済みます。
開発者の対応 | Appleの審査 | 最終結果 |
期限内に消費データを送信する | アカウントのシグナルと合わせて考慮する | 根拠の弱い申し立ては却下される可能性がある |
何も送らない | 自身のシグナルのみを使用する | デフォルトで承認されることが多い |
明確なトライアルと請求条件 | サンプルコンテンツのフラグを確認する | 「許可していない」という申し立てが減る |
迅速なアプリ内サポート | Appleには直接見えない | Appleに届くリクエスト自体が減る |
Appleが返金を却下する主な理由
Appleは、申し立てが証拠と一致しない場合、顧客に返金の繰り返しパターンが見られる場合、あるいは購入が意図通りに使用されたことを示す明確な消費データがある場合に、返金を却下することがあります。StoreKitを通じて行われたリクエストについては、REFUND_DECLINED通知がこれらの結果を知らせます。
次のような場合、リクエストが却下される可能性が高くなります。
• 顧客がすでに消費型購入の大部分を使用済みである。
• アカウントに複数の購入にわたる返金の繰り返しが見られる。
• 開発者が、通常の想定される使用状況を示す明確な証拠を送信した。
• サンプルやトライアルが提供されていたため、「知らなかった」という主張の説得力が弱まる。
例。あるユーザーが、コインの大半を使用した後にコインパックの返金を申請したとします。開発者はその使用状況を示す消費データを送信します。この証拠により、Appleには却下する明確な根拠が生まれます。
開発者のベストプラクティス
ベストプラクティスはシンプルです。すべての返金シグナルを取得し、CONSUMPTION_REQUESTには実際のデータで迅速に応答し、そもそも人々が返金を求める理由を減らすことです。判断そのものを勝ち取ることはできませんが、入力する情報の質を形作ることはできます。
• App Store Server Notifications V2を設定し、CONSUMPTION_REQUEST、REFUND、REFUND_DECLINEDを処理する。
• 消費データの応答を自動化し、12時間の期限内に確実に送信されるようにする。
• appAccountTokenを使って購入をユーザーに紐付け、実際の利用状況で応答できるようにする。
• チェックアウト前に、請求条件とトライアルの詳細を明確にする。
• 返金が承認された場合はアクセス権を取り消す。Appleが代わりにエンタイトルメントを削除してくれるわけではありません。
取引量が多い場合、手作業での対応では間に合いません。 CONSUMPTION_REQUESTへの応答を自動化しているチームは、何もしないチームがデフォルトで手放してしまう収益を守っています。
開発者への要点 Appleの判断そのものはコントロールできませんが、Appleに開発者側の言い分を届けるかどうかはコントロールできます。迅速で根拠のある応答と明確な請求内容こそが、返金の結果を実際に動かすレバーです。 |
まとめ
すべてのApp Store返金を決定するのはAppleであり、それが変わることはありません。数字を変えるのは、Appleが入力を求めたときにサーバーがきちんと応答するかどうか、そして誰かが返金を求める前にどれだけ製品と請求が明確になっているかです。
返金のフローは、ただ判定を待つものではなく、データを与えて動かすシステムとして捉えてください。通知を取得し、CONSUMPTION_REQUESTに実際のデータで応答し、エンタイトルメントを常に同期させておきましょう。これを実践しているチームは、他のチームが気づかないうちに失っている収益を静かに守っています。
よくある質問
返金を決定するのは開発者ではなく、常にAppleです。
開発者には消費データを送信するための12時間の猶予があります。
対象となる返金リクエストについて、消費データの提供を求めるAppleからの通知です。
AppleはREFUNDまたはREFUND_DECLINEDのサーバー通知を送信します。
いいえ。開発者はAppleの判断材料となる消費データを提供することしかできません。
はい。購入の利用状況は、Appleが考慮する要因の一つです。
はい。Appleがサブスクリプションの返金を決定し、返金通知を送信します。
サーバー側で顧客のアクセス権限（エンタイトルメント）を取り消す必要があります。
