Apple の返金リクエストにはすべて理由が付くようになり、consumptionRequestReason がそれを読み取る手段です

Apple は返金リクエストがあなたのサーバーに届く仕組みを変えましたが、多くの開発者はまったく気づきませんでした。WWDC24 で発表された App Store Server Notifications 2.11 のアップデート以降、すべての CONSUMPTION_REQUEST 通知は consumptionRequestReason というフィールドを含んでいます。それは顧客自身が述べた返金希望の理由です。一つのプレーンな文字列、五つの取り得る値が、あなたがすでに十二時間かけて答えることになっている同じペイロードの中に届けられます。

Apple の返金リクエスト理由は、それ自体では何も決めません。それがするのは、あなたが五つのまったく異なる状況のどれにいるのかを教えることです。そうすれば、承認すべき返金と争うべき返金に同じ汎用的な消費データを送るのをやめられます。ここでは、このフィールドが何か、Apple が送りうる正確な値、それぞれが何を示すか、そしてあなたが返す希望と証拠をどう変えるべきかを説明します。

consumptionRequestReason とは実際に何か

consumptionRequestReason は、CONSUMPTION_REQUEST 通知の data オブジェクト内の文字列フィールドです。Apple は WWDC24 の返金フローの変更とあわせて、App Store Server Notifications バージョン 2.11 でこれを追加しました。それ以前は、リクエストは署名済みトランザクションとともに届き、動機については何もありませんでした。あなたは手探りで答えていました。いまや顧客が述べた理由がリクエストとともに届きます。

「述べた」という語をよく読んでください。これは顧客が Apple に申請したときに選んだ理由であって、Apple が検証した事実ではありません。UNINTENDED_PURCHASE はその購入が使われなかったことを証明せず、UNSATISFIED_WITH_PURCHASE は製品が壊れていたことを証明しません。この値はレンズであって、判決ではありません。あなたはなお、自社の提供と利用の記録と突き合わせます。

それはあなたがすでに処理している通知に乗って届く

CONSUMPTION_REQUEST は、Apple が開発者に証拠を求める唯一のフローです。その Google Play における対応物は、orders.reviewrefund を通じたチャージバック審査です。一つが届いたら、あなたは Send Consumption Information を呼び出して答えるのに 12 時間あります。それはトランザクション消費エンドポイントへの PUT です。consumptionRequestReason はいまや同じ通知の一部なので、新たに購読するものは何もありません。すでに CONSUMPTION_REQUEST を解析しているなら、この理由はおそらくあなたが無視してきた一つのフィールドにすぎません。

五つの理由、そしてそれぞれが何を告げているか

Apple はちょうど五つの値を文書化しています。リクエストごとに一つ届きます。ここに全一覧と、実務でそれぞれをどう読むかを示します。

UNINTENDED_PURCHASE は誤タップの区分

これは、子供が 10,000 枚のコインを買った後に親が選ぶ理由であり、あるいは確認を押し間違えた大人が選ぶ理由です。それは一度も開かれず使われなかった購入と相関します。だからこそあなた自身のデータが重要なのです。記録がその消耗型アイテムを完全に提供し大量に消費したと示すなら、非意図的な購入という主張と使い切られた残高は一致せず、その食い違いは consumptionPercentage を通じて報告する価値があります。

FULFILLMENT_ISSUE は矛先をあなたに戻す

FULFILLMENT_ISSUE は、顧客ではなく部分的にあなたのアプリに関する唯一の理由です。それは、支払ったものを受け取れなかった、または使えなかったと彼らが言っていることを意味します。反射的に異議を唱える前に、提供ログを引き出してください。自社のサーバーが権利が一度も有効化されなかった、またはクレジットが一度も付与されなかったと示すなら、顧客は正しく、DECLINE は誤った希望です。本物の提供失敗と争うことは対応枠を浪費し、顧客を銀行へ向かわせかねません。そこではチャージバックの代償が本来の返金より高くつきます。

UNSATISFIED_WITH_PURCHASE は証拠が決めるところ

これはありふれた買い手の後悔であり、あなたの消費データが最も働く理由です。製品は機能しました。顧客はその一部または全部を使い、いまお金を返してほしいと言っています。高い consumptionPercentage、正直な DELIVERED の deliveryStatus、そして DECLINE または GRANT_PRORATED の refundPreference が、Apple があなたに示すよう求めている主張です。数字を送るのであって、議論を送るのではありません。

LEGAL と OTHER

LEGAL は、顧客が法的または規制上の権利を援用したことを意味します。分別ある人でも意見は分かれますが、原則としてここは争う対応枠ではありません。承認して先へ進みましょう。OTHER は、述べられた理由が上記四つのどれにも当てはまらないときに Apple が使う総括項です。それ自体は何のシグナルも持たないので、OTHER は理由がまったくないリクエストとまったく同じように扱ってください。提供状況と利用証拠を先頭に立てるのです。

理由はあなたの返答をフィールドごとにどう変えるか

あなたは ConsumptionRequest ボディを付けて Send Consumption Information を呼び出すことで CONSUMPTION_REQUEST に返答します。理由はそのボディ内の三つのフィールドを形づくるはずです。

customerConsented は true でなければならない

Apple は、customerConsented が true であるとき、つまり顧客が消費データの共有に同意したときにのみ、その提出を受け付けます。その同意がない場合、理由が何であれ、あなたはそもそもデータを送れません。同意なし、証拠なし、そしてリクエストはあなたの数字なしに決定されます。

deliveryStatus と consumptionPercentage が事実を担う

deliveryStatus は、あなたが機能する購入を提供したかどうかを示します。それが DELIVERED 以外の何かであれば、Apple は consumptionPercentage が 0 であることを要求します。あなたが実際に提供したとき、consumptionPercentage は milliunits 単位で 0 から 100,000 までの整数であり、100,000 は顧客が購入全体を使ったことを意味します。この対はあなたの事実上の核であり、理由そのものではなく、FULFILLMENT_ISSUE や UNSATISFIED_WITH_PURCHASE の主張を担うべきものです。

refundPreference はあなたの唯一のレバー

refundPreference は、あなたが望むものを述べる場所です。Apple は三つの値を文書化しています。GRANT_FULL、GRANT_PRORATED、DECLINE です。理由を読み、自社のデータと比較検討し、そして選びます。ログに提供失敗がある FULFILLMENT_ISSUE は GRANT_FULL に傾きます。完全に消費された製品での UNSATISFIED_WITH_PURCHASE は DECLINE または GRANT_PRORATED に傾きます。LEGAL は GRANT_FULL に傾きます。

返金は実際にあなたにいくらの代償を課すか

理由フィールドが重要なのは、返金がその販売を帳簿から落とすだけであることはめったにないからです。すでに動いた消耗型アイテムについては、あなたはそれを果たすために支払いました。有料の推論 API を呼んだクレジットパック、GPU 時間を燃やした生成画像の一群、ストレージ請求に居座る保存済みのエクスポート、すでに送ったクリエイターへの支払い。これらのコストは、購入が取り消されても使われたままです。ストアは顧客のお金を返します。それはあなたの計算資源を返しません。

だからこそ理由は読む価値があるのです。ある顧客がそれぞれ有料 API 呼び出しを起こす 5,000 のクレジットを買い、そのうち 4,000 を使い、そして UNSATISFIED_WITH_PURCHASE で申請したとしましょう。あなたの deliveryStatus は DELIVERED、あなたの consumptionPercentage は 80,000 milliunits であり、DECLINE または GRANT_PRORATED の希望は、API の請求を自分でかぶることと、その大部分を取り戻すことの差になります。今度は理由を FULFILLMENT_ISSUE に切り替え、クレジットが一度も付与されなかったと示すログを添えると、正直で安上がりな一手は、顧客が銀行へエスカレートする前の GRANT_FULL です。

過剰反応せずに理由を読む

落とし穴は、理由を証拠として扱うことです。UNINTENDED_PURCHASE は製品が使われなかったという自白ではなく、LEGAL は常に本物の法的主張であるとは限りません。理由は状況を絞ります。それを解決するのはあなたの提供ログと消費記録です。それらが顧客と一致するときは、早く安く承認しましょう。それらが顧客と矛盾するときは、その矛盾を deliveryStatus と consumptionPercentage として表したものが、あなたが送れる最も強いものです。RefundHalt はすべての CONSUMPTION_REQUEST で consumptionRequestReason を読み取り、それをあなたの実際の利用データと自動的に組み合わせるので、それぞれの理由は 12 時間の対応枠の中でふさわしい返答を受けます。

この変更は小さく見落としやすいものですが、返金という対話をあなたに有利な方へ動かしました。Apple はいまや、あなたが答える前に理由を告げています。それを使いましょう。