返金を認めるかどうかを決めるのはAppleです。ポリシーがあなたに委ねているのは、その決定の周辺で起こるすべてのことであり、避けられたはずの損失の大半はそこで生じています。
こうした話をよく耳にします。3月にあるユーザーがAppleに返金を申請します。Appleはそれを承認します。開発者のサーバーはそのことを一切知りません。6月になっても、そのユーザーはアプリの有料版を使い続けています。四半期末に財務チームがチェックを行うまで誰も気づかず、気づいたとしても何が起きたのかを把握するまでに時間がかかります。返金の記録は支払いレポートの中にあり、アクセス権の記録はアプリ自身のデータベースの中にあります。この2つが互いにやり取りすることはありません。
多くの開発者はこのようにしてApp Storeの返金ポリシーを学びます。ポリシーを読んでではなく、数か月後に、ポリシーが何をカバーしていなかったかを思い知らされる形で。
ポリシーに明記されていない部分はここです。Appleが支払いを取り消すことと、あなたのアプリがアクセス権を取り消すことは、別々の出来事です。前者はAppleが担い、後者はあなたが担います。この2つの間にあるギャップこそ、開発者が毎月気づかないうちにお金を失っている場所です。この記事の大部分は、そのギャップを埋める方法についてのものです。
そこでこの記事では、開発者の視点からポリシーを見ていきます。Appleが管理していること、あなたの責任になること、そして返金が成立した後にあなたのシステムが何をすべきかです。ポリシーそのものよりも実務的な側面を知りたい場合は、 モバイルアプリの収益を失わずにApp Storeの返金を管理する方法に関するガイドで詳しく解説しています。
主なポイント
● 返金の決定はすべてAppleが行います。App Store Connectには返金を承認したり却下したりするボタンはありません。その選択はそもそも開発者に与えられたものではないからです。
● 顧客の居住地によって結果が変わることがあります。返金の対象条件と手続きは、Appleの メディアサービス利用規約に基づき、国や地域によって異なります。
● Appleは返金に関する通知をあなたのサーバーに送ることがあり、リクエストの審査中に購入がどのように利用されたかについての情報を求めることがあります。
● 回答できる時間は12時間で、しかも顧客がその情報の共有に同意している場合に限られます。
● Appleが承認した返金と、あなたのデータベースが記録する返金は、2つの別々の出来事です。その間の隙間からお金が漏れていきます。
● 自動化によって、あなた側のプロセスをより速く、より一貫したものにできます。Appleの決定には何の影響も与えません。
App Storeの返金ポリシーとは何か
簡単に言えば、Appleが顧客の返金リクエストをどう処理するかについてのルール一式と、開発者側に課される技術的な作業のリストです。
返金を承認するかどうかを決めるのはAppleです。あなたに発言権はありません。リクエストを承認することも、却下することもできません。App Store Connectには開発者がこれに票を投じる画面はありません。できるのはせいぜい、プロセスの途中のいくつかの時点でAppleに情報を送ることだけで、これについてはこの後すぐに説明します。顧客が実際にどのようにリクエストを送信するかを知りたい場合は、Appleの アプリやコンテンツの返金をリクエストするためのガイドに手順が記載されています。
私たちは通常、チーム向けにポリシーを4つの部分に分けて説明しています。4つのうち本当にあなたの問題になるのは2つだけだからです。
1つ目は返金の対象条件です。リクエストはあなたではなく、Appleに直接届きます。対象条件は顧客の国や地域によって変わることがあり、そのルールは Apple メディアサービス利用規約に定められています。ですから、あるユーザーから「自分の返金は通ったのに友人の返金は通らなかったのはなぜか」と聞かれても、簡単な答えはありません。それぞれがどこに住んでいるかによって決まります。
2つ目は決定そのものです。これは完全にAppleの判断です。あなたは決定が下された後に初めて知ることになります。
3つ目はあなたの責任です。これは法的なものではなく技術的なもので、ほぼ毎回のように人を驚かせる点です。通知を受け取れるサーバーを運用すること。Appleから求められたときに情報を提供すること。きれいな記録を保つこと。これが仕事のすべてです。
4つ目は決定後にエンタイトルメント(利用権)がどうなるかで、これこそが実際にお金がかかる部分です。Appleが支払いを取り消しても、それだけであなた自身のデータベースが変わることはありません。返金を受けたのに有料アクセスを永久に保持している顧客がいるとしたら、それはAppleのポリシーの欠陥ではありません。あなたのシステムの作り方にあるギャップです。
私たちにとってどの部分が最も重要かは、おそらく想像がつくでしょう。
Apple App Storeの返金プロセスは開発者にとってどう動くのか
顧客が始め、Appleが終わらせます。あなたはその中間のどこかにいます。
顧客がAppleを通じて返金をリクエストする
↓
Appleがリクエストを審査する
↓
あなたのサーバーに返金関連の通知が届く場合がある
↓
該当する場合、補足情報を提供する
↓
Appleが決定を下す
↓
結果が通知として届く
↓
エンタイトルメントとアクセス権が更新される
ここで注意すべき点が2つあります。Appleは顧客に対し、おおむね24〜48時間以内に回答すると案内しており、このタイムラインはあなたのタイムラインとは無関係です。リクエストが保留中の間にサポートチームが何を約束するかには注意してください。また、上記の各ステップは、あなたのサーバーが実際にセットアップされ、到達可能である場合にのみ機能します。自社のサーバーがそうなっていなかったと気づくチームは少なくありません。エンドポイントがダウンしていても、返金は実行されます。ただ、あなたがそれを知ることがないだけです。
App Storeの返金ルールは開発者にとって何を意味するのか
ポリシーの文言を取り払うと、ルールはエンジニアリングチーム向けの短く、あまり華やかではないチェックリストになります。
● 実際に検索できるトランザクション記録。 返金通知はAppleのトランザクション識別子を参照します。購入時にそれを保存していなければ、通知はほとんど役に立ちません。また、各トランザクションとユーザーアカウントを確実に紐づけておく必要があります。Appleのペイロードが識別するのは購入であって、購入した人ではないからです。
● 正しく動作し、署名を検証する通知エンドポイント。 返金イベントは App Store Server Notificationsを通じて届き、ペイロードには署名が付いています。その署名を毎回検証してください。送られてきたものを何でも信用するエンドポイントは、URLの付いたセキュリティリスクです。
● 事前に用意された同意フロー。 Appleが消費情報を求めてきた場合、回答が許されるのは顧客がすでにそのデータの共有に同意している場合だけです。その責任はあなたにあります。Appleの Send Consumption Informationのドキュメントはこの点を明確にしており、同意なしに送られた回答は拒否されます。また、リクエストが届いた後にさかのぼって同意を取得することもできません。購入時に同意を得ていたか、そうでなければその件は見送るかのどちらかです。
● 双方向に機能するエンタイトルメントロジック。 返金は取り消されることがあります。Appleは購入の一部だけを返す一部返金も認めています。全額、一部、取り消しの3つすべてをコードで処理する必要があります。
● 財務チームが実際に使える形で結果を残す場所。 アプリのデータベースの中にしか存在しない返金は、支払いレポートと照合できません。多くのチームは四半期末の締めでこれに気づきますが、それが良い日になることはめったにありません。
Appleの返金ポリシーは開発者にどう影響するのか
誰もが返金額に注目します。しかし、それは通常この話の中で最も小さな数字です。
サブスクリプション期間が返金されると、すでに計上していた収益が取り戻され、ほとんどの場合、顧客との関係もそこで終わります。見込んでいた更新はいつの間にか来なくなります。1回限りの購入はもっと単純ですが、それでも返金は販売後に発生するため、総額ベースで構築されたレポートは返金が差し引かれるまで数字を過大に示すことになります。
この記事全体で覚えておいてほしい区別はこれです。Appleが承認した返金と、あなたのシステムが実際に記録した返金は、2つの別々の出来事です。Apple側の処理は、誰が見ていようがいまいが、Apple自身のスケジュールで進みます。あなた側の処理は、通知ハンドラーが起動し、トランザクションが一致し、アカウントが見つかり、アクセス権が更新された場合にのみ起こります。このどれか1つでも欠ければ仕事は半分しか終わっておらず、外から見てもどちらの半分が終わっていないのかは誰にも分かりません。
このギャップには名前があります。返金リーケージ(refund leakage)です。返金を受け取ったうえで、支払った分のすべてを保持し続けている顧客のことです。彼らがそれを報告することはありません。彼らから見れば、何も問題がないからです。数か月後の照合作業で発覚するか、あるいは永遠に発覚しないかのどちらかです。
他のすべての問題も、この同じギャップから生じます。照合すべき返金記録がないままチケットに対応するサポート担当者。取り消しが数字に反映されないために顧客生涯価値を過大に示す分析。振り返るための返金履歴がないため、ある製品が他よりはるかに多くの返金を引き起こしていても誰も気づかないこと。
Appleの返金がリクエストされたとき開発者は何をすべきか
ステップは7つです。作業の大半は、リクエストが届くよりずっと前に行われます。
1. 通知を受信し、検証する
返金イベントは、署名付きのJWSペイロードとしてエンドポイントに届きます。Appleの証明書チェーンに対して署名を検証してください。バンドルIDを確認してください。そのうえで初めて、中身に基づいて処理を行います。これは基本的な衛生管理ですが、いまだに省略するチームがあります。渡されたものを何でも受け入れるエンドポイントは、誰かに悪用される可能性のあるエンドポイントです。
2. トランザクションとアカウントを特定する
ペイロードからトランザクション識別子を取り出し、購入記録と照合します。購入時に安定したアカウントトークンを付与していれば、これは1回の検索で済みます。付与していなければ、時間に追われながら推測することになります。
3. 購入についてすでに分かっていることを確認する
自社のシステムが何を記録しているかを把握するまで、Appleに有用な情報を伝えることはできません。コンテンツは配信されたか。期待どおりに動作したか。顧客は実際にどれだけ利用したか。これらに自社の記録から答えられないなら、それが最初の本当の問題であり、返金はその次です。
4. Appleから求められ、同意がある場合に消費情報を送信する
AppleからのCONSUMPTION_REQUEST通知は、購入がどのように利用されたかについての情報を回答できることを意味しますが、それは2つの条件が満たされている場合に限られます。顧客が有効な同意を与えていること、そしてAppleが定める12時間の期限内であることです。Appleの現在のドキュメントでは、この通知はすべての製品タイプの返金リクエストに関連付けられていますが、必ず届くものと想定せずにハンドラーを構築してください。送信する内容は、大まかな推測ではなく、自社の記録から直接取ったものであるべきです。
5. 最終的な結果を追跡する
結果は通知として届きます。REFUNDは返金が承認されたことを、REFUND_DECLINEDは承認されなかったことを、REFUND_REVERSEDはAppleがすでに承認した返金を取り消したことを意味します。3つの結果をすべて保存してください。取り消しのケースはチームが最も忘れがちなもので、取り消しを見逃すと、正当に所有しているものから支払い済みの顧客を締め出してしまうことになります。
6. エンタイトルメントとアクセス権を更新する
返金が承認されたらアクセス権を取り消します。返金が取り消されたら復元します。一部だけが返金される部分返金のケースにも対応します。そして、これをサーバーサイドのイベントに基づいて実行し、顧客が再びアプリを開くかどうかにかかわらず、アクセス権が正しい状態に保たれるようにします。
7. 収益およびサブスクリプションのレポートと照合する
返金を正しい期間と正しい製品に対応させます。このステップを省略すると、財務とエンジニアリングが同じ月の2つの異なるバージョンを見ることになります。その会議に出席したことがある人なら、避ける価値があることを知っているはずです。
手作業でのApp Store返金管理が難しくなる理由
これは不注意の問題ではありません。24時間体制で誰かが起きていて注意を払っていることに依存するプロセスに、制約が合っていないだけです。
返金リクエストは、顧客が送信したときにいつでも届きます。日曜の朝。午前2時。祝日。回答期限は誰のスケジュールのためにも止まりません。各リクエストには、トランザクションの検索、アカウントの照合、同意の確認、利用状況の数値、エンタイトルメントの更新が必要です。順調な日なら5分程度の作業です。しかし、時間に追われ、繰り返しが多く、正しく行われたときにはまったく目に見えません。午前4時に正しく処理された返金に感謝する人はいません。
件数が増えればさらに難しくなります。複数のアプリを運用し、トランザクションデータがあるシステムに、アカウントデータが別のシステムにある場合も同様です。そして、ハンドラーを理解していたエンジニアが別のチームに異動します。追跡用のスプレッドシートはrefunds_OLD_final_v2のような名前になり、いつの間にか誰も開かなくなります。財務チームは四半期末の締めでギャップを見つけますが、それは誰かが何かできた時点からおよそ3か月が過ぎた後です。
開発者がApp Storeの返金をより確実に管理するには
手動での監視は次のようなものです。誰かがダッシュボードを開き、トランザクションを検索し、記録を更新して、次に進む。件数が少ないうちは問題なく機能し、それこそが罠です。大きな音を立てて壊れることはなく、ゆっくりと薄れていきます。機能しなくなる瞬間が1つに定まらないため、誰も間に合ううちに気づけないのです。
自動化は、機械的なステップを人の手から取り除きます。通知の受信と検証、トランザクションとアカウントの照合、回答データの組み立て、回答期限の追跡、結果の記録、エンタイトルメントの同期です。
自動化にできないのは、Appleの判断を変えることです。自動化によって返金が起こりにくくなることはなく、一部のツールが何をほのめかそうと、決定に影響を与えることもできません。変わるのは、あなた側のプロセスが一貫して期限内に行われるかどうかだけです。それだけでも、修正する価値のある意味のあることです。
この作業はApp Store返金管理というカテゴリーに属し、この分野のツールが何をカバーすべきかは率直に述べておく価値があります。通知の処理、トランザクションとユーザーの照合、同意とタイミングを尊重した回答ワークフロー、後から参照できる返金履歴、そして全額・一部・取り消しの返金に対応するエンタイトルメントの更新です。
RefundSensorはこの部分の仕事をカバーします。App StoreとGoogle Playの返金イベントを自動化されたワークフローに接続するので、誰かが手作業で通知を見張らなくても回答はストアの期限内に送信され、件数が増えても返金記録は正確に保たれます。Appleの決定を変えることはありません。それができるものは何もないからです。変わるのは、各返金があなたのチームにその後どれだけの作業を残すかです。
これらのルールが記載されている場所
上記のすべての背景には、Appleの3つの情報源があります。何かを構築する前にご自身で読み、時々見直してください。この分野はすでに何度も変更されています。
アプリやコンテンツの返金をリクエストする — 顧客が目にするポリシーです。リクエストの送信方法、24〜48時間の回答期間、地域ごとの対象条件に関するAppleの注記を扱っています。
Send Consumption Information — 開発者向けの回答ワークフローです。同意の要件、12時間の期限、リクエストのフィールドを扱っています。消費情報の処理に手を付ける前に、全文を読んでおく価値があります。
App Store Server Notifications — 返金イベントがバックエンドに届く仕組みです。署名付きペイロードの形式と、CONSUMPTION_REQUEST、REFUND、REFUND_DECLINED、REFUND_REVERSEDを含む通知タイプを扱っています。
返金イベントをまだ手作業で確認しているなら
手動での監視は、機能しなくなるその時まではうまく機能し、その失敗はたいてい静かに起こります。誰も見なかった通知。午前3時に閉じた期限。四半期まるごとアクセス権を保持し続けた返金済みの顧客。
心当たりがあるなら、RefundSensorが返金ワークフローを手作業の追跡から切り離します。ストアのイベント、回答期限、そして結果があなたの記録とエンタイトルメントロジックの両方に確実に届くようにすることまでを担います。
よくある質問
Appleが顧客の返金リクエストをどう処理するかについてのルール一式と、その周辺で開発者側に課される技術的な作業のことです。結果を決めるのはAppleです。開発者はその周辺の配管を担当します。通知を受信すること、求められたときに同意の範囲内で消費情報を送信すること、そして決定が返ってきた後にアクセス権と記録を更新することです。
できません。仮にそうしたくても、その手段はありません。すべてのリクエストについて最終的な判断を下すのはAppleです。現在の消費情報エンドポイントでは希望する結果を伝えることはできますが、それは複数ある入力の1つであって指示ではありません。Appleはそれと異なる決定を下すこともあります。
顧客がAppleにリクエストを送ります。Appleがそれを審査し、消費情報を求めてあなたのサーバーに連絡することがあります。同意がある場合は、Appleが定める期限内に回答します。Appleが決定を下し、その結果を独立した通知として送信します。あなたのシステムは、その決定に合わせて顧客のエンタイトルメントと記録を更新します。
はい。ただし、限られた1つの方法だけです。CONSUMPTION_REQUEST通知が届いたとき、Appleは購入がどのように利用されたかについての情報を求めています。回答には有効な顧客の同意が必要で、正確でなければならず、Appleの期限内に送信する必要があります。回答は審査の参考情報になりますが、結果を決めるものではありません。
Appleが返金リクエストを審査している間に、購入に関する情報をあなたのサーバーに求めるApp Store Server Notificationです。返金そのものではなく、決定でもありません。回答の猶予は12時間で、顧客がそのデータの共有に同意している場合に限られます。
2つの形で影響します。直接的には、返金された期間の収益が取り消されます。間接的には、たいてい顧客との関係がそこで終わるため、見込んでいた更新が発生しなくなります。総更新額に基づくレポートは返金が差し引かれるまで収益を過大に示し、顧客生涯価値にも同じ誤差が引き継がれます。
やるべきことが3つ、注意すべきことが2つあります。トランザクションと顧客に対して結果を記録すること。該当するエンタイトルメントを取り消すこと。返金を正しい期間の収益レポートに反映すること。そのうえで、トランザクションの一部だけが返金される部分返金のケースに対応し、Appleが後から返金を取り消す可能性があるため、復元の経路も用意しておきます。
機械的な部分は、完全に自動化できます。通知の検証、トランザクションとアカウントの照合、回答期限の追跡、エンタイトルメントの更新、返金履歴の保持。これらはすべて、自動化できる程度に予測可能です。人が担うべきなのは、同意フローの設計と、返金パターンを実際に読み解くことです。そこには製品についての本当の情報が含まれているからです。
