長らく、「Apple返金リクエストにはどう対応すればいいのか」という問いに対する正直な答えは、「対応できない」でした。Appleが決済を処理し、リクエストを受け取り、判断を下し、デベロッパーが最初にそれを知るのは支払額が減ったときでした。しかし、これは2021年以降は当てはまらなくなっています。それでも多くの人がいまだにそう思い込んでいます。
現在では、Appleは判断を下す前に、あなたのサーバーへ購入に関する情報を問い合わせ、回答を約12時間待ちます。CONSUMPTION_REQUESTに実際に含まれる内容についてはすでに別の記事で解説していますので、ここではペイロードを項目ごとに繰り返すことはしません。本記事では、CONSUMPTION_REQUESTが届いた後にどう対応すべきかを取り上げます。
重要なポイント
App Storeのすべての返金は、最終的にAppleが判断します。デベロッパーが送る情報によってこの事実は変わりませんが、判断時にAppleが把握している内容は変わります。
リクエストはCONSUMPTION_REQUEST通知として届き、消費型アイテムと自動更新サブスクリプションのみが対象です。
Send Consumption Informationエンドポイントを通じて返信できる時間は12時間で、現在は5つのフィールドが必要です。
返信内容は主に3つの事実、つまり配信されたかどうか、どの程度使用されたか、事前に無料体験があったかどうかで構成されます。それに加えて、あなたの希望も伝えます。
私たちの経験では、デベロッパーが失う返金のほとんどは、誰も返信しなかったケースです。
Apple App Storeの返金リクエストとは?
Apple App Storeの返金リクエストとは、顧客がアプリやアプリ内購入の代金の返金をAppleに求めることです。デベロッパーに求めるわけではありません。顧客はreportaproblem.apple.comにアクセスするか、アプリ内の返金申請シートを使い、短い選択肢から理由を選び、対象の購入を選択して送信します。Appleのサポートページでは、24〜48時間以内に回答があると案内されています。
購入が消費型アイテムまたは自動更新サブスクリプションだった場合、Appleはあなたのサーバーに問い合わせて把握している情報を求め、その回答を、Apple自身がはるかに詳しく把握している顧客自身の購入・返金履歴と組み合わせて判断を下します。顧客の名前は見えず、拒否権もありません。与えられるのは、事実を提示するための短い時間だけです。
デベロッパー向けApple返金プロセスの仕組み
デベロッパー向けのApple返金プロセスは4つの段階で進みますが、デベロッパーが関わるのはそのうち1つだけです。
顧客がAppleに返金を申請し、理由を選択します。
Appleが、App Store Connectに登録されたサーバーURLへCONSUMPTION_REQUESTを送信します。これは消費型アイテムと自動更新サブスクリプションの場合のみ発生します。
デベロッパーには、自社のデータを使ってSend Consumption Informationエンドポイントを呼び出す12時間の時間があります。
Appleが判断を下し、REFUND通知またはREFUND_DECLINED通知で結果を伝えます。
App Store Server Notifications用のサーバーURLを設定していない場合、2番目の段階は何も起こらずに終わります。Appleは顧客側の情報のみで判断を下し、あなたがそれを知るのは、売上レポートを見ていればそこから、ということになります。
顧客が返金を申請した後に何が起こるか
顧客が申請を送信して間もなく、あなたのエンドポイントにはnotificationTypeがCONSUMPTION_REQUESTとなっている署名付きJSONペイロードが届きます。内容には、署名付きトランザクション、プロダクトID、元のトランザクションID、そしてconsumptionRequestReasonが含まれます。この理由フィールドはAppleが2024年に追加したもので、WWDC24のApp Store server APIsに関するセッションで説明されています。取り得る値は5つで、UNINTENDED_PURCHASE、FULFILLMENT_ISSUE、UNSATISFIED_WITH_PURCHASE、LEGAL、OTHERです。
そこに欠けているのが「人物」の情報です。あなたの記録へつながる唯一の手がかりはトランザクションIDと、購入時にappAccountTokenを付与していた場合はそのトークンです。付与していなかった場合、このタイミングで「付与しておけばよかった」と思うことになります。
つまり、このレビューは実質的にルックアップ作業です。誰がこれを購入したのか、それは届けられたのか、そしてその後どのように使われたのか、という点を確認します。
Apple返金リクエストへの対応方法
「Apple返金リクエスト通知にどう対応すればいいか」を検索する人の多くは、APIリファレンスに行き着きます。ここでは手順を順番に紹介します。
1. ペイロードを検証する
Appleはすべての通知に署名を付けています。内容を信用する前に、必ず署名を検証してください。AppleのApp Store Server LibraryはJava、Python、Node、Swiftでこれを行えます。
2. 購入情報を特定する
トランザクションIDまたはappAccountTokenを使って、自社システム内で該当の購入を検索します。必要なのは、ユーザー情報、配信記録、そしてその後記録した利用状況です。
3. 理由を確認し、その内容を検証する
FULFILLMENT_ISSUEは、顧客が「支払った対価を受け取っていない」と主張していることを意味します。まず配信ログを確認しましょう。顧客の主張が正しければ、この返金は通すべきです。
UNINTENDED_PURCHASEは、たいてい子どもの操作や誤タップによるものです。
UNSATISFIED_WITH_PURCHASEでは、利用データが実際に重みを持ちます。「気に入らなかった」という主張も、使用率が2%の場合と100%の場合とでは見え方が大きく異なるからです。
4. 希望する対応を選択する
AppleはGRANT_FULL、GRANT_PRORATED、DECLINEのいずれかを受け付けます。自社データが裏付けるものを選びましょう。あくまで希望にすぎず、デベロッパーが拒否を求めたにもかかわらずAppleが返金を承認したケースは多数あります。
5. 送信する
Call theSend Consumption Informationエンドポイントを呼び出します。現在のリクエストボディには5つのフィールドがあります。customerConsented、deliveryStatus、consumptionPercentage、sampleContentProvided、refundPreferenceです。
消費量はミリ単位(milliunits)で表され、ここで戸惑う人が多いです。100000は完全に使用されたことを意味し、45200は45.2%を意味します。
また、customerConsentedはtrueである必要があるため、利用データを共有する許可は、最初のリクエストが届くはるか前に、利用規約に組み込んでおく必要があります。
6. 結果に基づいて対応する
REFUNDの場合は、コンテンツやエンタイトルメントを取り消します。できれば1時間以内に行いましょう。REFUND_DECLINEDの場合は何も変更しません。いずれの場合も、結果をそのケースに紐づけて記録してください。
例えば、誰かが午後11時に500コインパックを購入し、一晩で470コインを使い、翌朝UNSATISFIED_WITH_PURCHASEとして申請したとします。配信済み、94%消費、トライアルなし、希望はDECLINE。これで完全なApple返金リクエストへの返信になります。長文のエッセイは必要ありません。
対応する前にデベロッパーが確認すべき情報とは?
5つの項目があり、そのほとんどはすでにあなたのデータベースにあるはずです。
購入記録
日付、プロダクト、価格、そしてこのアカウントが過去に購入したことがあるかどうかです。自社の記録が乏しい場合、AppleのGet Transaction Historyエンドポイントに、起点となるトランザクションIDを一つ渡すことで、この顧客があなたのアプリで購入したすべての内容を取得できます。
配信
あなたのサーバーは実際にコインを渡したか、機能をアンロックしたか、サブスクリプションを開始したか、そしてそれはいつだったでしょうか。その処理が失敗していた場合、deliveryStatusはUNDELIVERED系の値となり、返金は当然のものです。自社のログに逆らってはいけません。
その後の利用状況
セッション数、開いたチャプター数、使用したコイン数など、あなたのプロダクトにとって「利用する」とは何を意味するかによります。Appleが求めるのはパーセンテージだけですが、その裏付けとなるイベントがなければ、自信を持って示せる数値は出せません。
事前に無料体験があったかどうか
無料トライアル、プレビューチャプター、無料プランなどが該当します。Appleはこれを直接尋ねており、「はい」であれば「何を買うのか分からなかった」という主張の説得力は弱まります。
自社側のアカウント情報
アカウントの作成からの経過期間、過去に返金した履歴があるか、未解決のサポートチケットがあるかどうかです。Appleはその履歴のうちApp Store側の部分を把握していますが、あなた側の部分を把握しているのはあなただけです。
これらすべては、AppleのトランザクションIDを自社システムのユーザーに結び付けられるかどうかにかかっており、そのためにappAccountTokenが存在します。これは私たちが最もよく目にするギャップです。設定の詳細を知りたい方は、appAccountTokenが返金対策にとって重要な理由について書いた記事もご覧ください。
Apple返金リクエストでデベロッパーがよく陥る間違い
通知が届かない
App Store ConnectにサーバーURLが設定されていない、あるいは設定されていても、3月に誰かが廃止したステージング環境を指している、というケースです。Appleは送信を続けますが、受け取る側には誰もいません。
返信が遅れる
12時間というのは、日曜午前2時にリクエストが届き、対応すべき担当者が寝ていて、その後ブランチに出かけ、ようやくSlackのメッセージをなんとなく認識する、という状況になるまでは十分な時間に思えます。業務時間を前提に組まれたプロセスは、構造上、一定数のリクエストを取りこぼします。
答えるべきデータがない
通知が届いても、配信ログも利用イベントもappAccountTokenもありません。Appleは顧客の主張だけで判断を下します。この失敗は何カ月も前、チェックアウトの時点で既に起きていたものです。
すべてにDECLINEを求める
すべてのリクエストに対してDECLINEを送る設定を見かけたことがあります。デベロッパー自身のログで配信失敗が判明しているケースですら、そうしていました。Appleはこうしたパターンを見抜くことができ、本当に主張すべき根拠があるリクエストにおける信頼性を損なってしまいます。
返金承認後に取り消しを忘れる
これは二重にコストがかかるミスです。お金は戻ってしまったうえに、顧客はまだコンテンツを保持しており、しかもそれに気づく人もいます。
本番環境でテストする
Appleはテスト通知用のエンドポイントとサンドボックスの返金リクエストを提供しています。不都合なタイミングで最初の本番リクエストが届く前に、両方を使ってテストしておきましょう。
Apple返金管理:手動か自動化か
Apple返金管理とは、あの12時間の時間枠をめぐるすべての作業を指します。リクエストの受信、データの特定、希望対応の選択、返信の送信、結果の記録、必要に応じた取り消しです。
手動対応
手動で行う場合、ログへのアクセス権とアラートを持つ1人が担当することになります。月に数件程度のリクエストであれば問題なく機能しますが、その担当者が1週間でも休みを取らないことが前提です。
週に20件程度になると、取りこぼしが出始めます。100件になると、それは1つの業務そのものになり、誰も望んでやりたい仕事ではありません。
自動化対応
自動化すれば、ルックアップと返信は、一度作成したルールに基づいて動作します。完全に消費された消費型アイテムにはDECLINE、配信に失敗したFULFILLMENT_ISSUEにはGRANT_FULL、そして不自然なものはすべて人の確認用にフラグが立てられます。
返信は数分で送信され、午後2時であっても午前2時であっても同じように確実に処理されます。
ただし注意点があります。自動化は、その裏にあるデータの質に左右されます。配信記録や利用記録が不十分なままでは、「unknown」という結果をより速く送るだけです。
Apple返金管理ソフトウェアはいつ検討すべきか?
正直なところ、最初から導入する必要はありません。月に2〜3件程度であれば、チェックリストと目立つアラートで対応できますし、いくつか手動で処理してみることで多くを学べます。
意味を持ち始めるのは、1人で時間枠内に処理しきれないペースでリクエストが届くようになったとき、あるいは誰も起きていない時間帯に届くようになったときです。複数のアプリを運営していたり、Apple App StoreとGoogle Playを並行して運用していて、3つのリストではなく1つのリストで管理したい場合にも役立ちます。
Apple返金管理ソフトウェアがその価値を発揮するのは、手動プロセスがリクエストを取りこぼし始めたときです。そのタイミングは分かりやすく、3件連続で対応を取り逃し、支払額を見て初めてそれに気づいた週がそれにあたります。
Apple返金対策ソフトウェア:デベロッパーが確認すべきポイント
Apple返金対策ソフトウェアを比較検討するなら、まず基盤の部分から確認しましょう。CONSUMPTION_REQUESTを自ら受信し、人の手を介さずに通常のケースへ返信できるでしょうか。深夜や週末も含めて、どのくらいの速さで対応できるでしょうか。正解は「数分」であり、実際のタイムスタンプを見せてもらうべきです。
エビデンス
配信データや利用データを取得・受信できるか、それとも通知内容に希望対応を添えてそのまま返すだけでしょうか。後者のタイプには、さほど価値がありません。
また、メールの解析ではなく、App Store Server APIとServer Notifications V2の上に構築されているべきです。
可視性
リクエストが届いたとき、返信が送られたとき、Appleが判断を下したときの通知。
リクエストごとのケース管理で、返信内容と結果が一か所にまとまっていること。
返金率、勝率、理由についての、アプリ別・プロダクト別のレポート。
誰が、あるいは何が、いつどの返信を送ったかの監査ログ。
自分でコントロールできるルールがあり、ロジックの変更にデプロイが不要であること。
料金
料金体系もさまざまです。月額固定、リクエスト単位、回収額に対する割合など、それぞれ異なる利用量に適しています。
どのソフトウェアにもできないことが1つあります。それは、返金リクエストの発生自体を止めることや、Appleの判断結果を保証することです。そうではないと主張する相手は、何かを売り込もうとしているだけです。
Apple返金リクエストへの対応におけるベストプラクティス
オンコール担当表の隣にこれを貼っておきましょう。
App Store Server Notifications V2用の本番サーバーURLを登録し、通知が途絶えた場合にアラートが出るようにします。
すべての購入にappAccountTokenを設定します。例外なくすべてです。
配信にはタイムスタンプと結果を記録し、さらに「利用した」ことを示す数少ない利用イベントも記録します。
利用データ共有への同意は、今のうちに利用規約に組み込んでおきます。
返信が「承認する」内容になる場合も含め、すべてのリクエストに12時間以内に返信します。
DECLINEを求めるのは、自社データがそれを裏付ける場合のみにします。Appleはパターンに気づきます。
REFUND通知を受け取ったら、その日のうちに必ずアクセスを取り消します。
月に一度、実際に返信できたリクエストの割合を確認します。この数値は、返金率に最も大きく影響します。
Apple返金管理ソフトウェアは導入する価値があるか?
リクエスト数が少ないうちは、おそらく必要ありません。1人が確実に対応できる件数を超えたり、業務時間外に届くようになったりすると、自動で返信するソフトウェアは通常、その費用に見合う価値を発揮します。
ここから持ち帰るべき習慣が1つあるとすれば、それは時間切れになる前に、すべてのリクエストに実際のデータで返信することです。サブスクリプション型オーディオアプリのDipseaは、返信を始めてから約2週間で返金率を3%から1.9%まで下げましたが、Appleに対してDECLINEを一度も求めていません。何も返信しないアプリは、どれだけ守れたはずの収益があったのかを、永遠に知ることができません。
よくある質問
顧客が、通常はreportaproblem.apple.comを通じて、アプリやアプリ内購入の返金をAppleに求めることです。Appleは顧客に対し、24〜48時間以内に回答すると案内しています。消費型アイテムやサブスクリプションの場合、Appleはまずデベロッパーに情報を求めます。
通知の署名を確認し、自社の記録から購入情報を特定し、配信状況と利用状況を確認し、希望する対応を選択し、12時間以内にAppleのSend Consumption Informationエンドポイントを呼び出します。そのうえで、Appleが下した決定に従って対応します。
できません。Appleに対して返金を拒否してほしいという希望を伝え、それを裏付けるデータを送ることは可能です。それでも最終的な判断を下すのはAppleであり、デベロッパーが拒否を希望した返金であっても、Appleが承認することは実際にあります。
次の5つの項目です。顧客がデータ共有に同意したかどうか、購入が配信されたかどうか、どの程度消費されたか、無料サンプルやトライアルを利用していたかどうか、そしてあなたの返金に関する希望です。これが現在のリクエストボディのすべての項目になります。
CONSUMPTION_REQUESTから12時間以内です。自社のデータを判断に反映させたい場合は、この時間内に返信するようAppleは案内しています。
