想像してみてください。顧客が年間プランを購入し、1週間使用した後、Appleに返金を依頼します。あなたがそれに気づくのは、支払いの受取額が少なくなったときです。誰にも何も聞かれなかった、そう思えるかもしれません。
実際には、Appleは多くの場合に確認を行っています。AppleはあなたのサーバーにCONSUMPTION_REQUESTというメッセージを送信し、顧客が購入したものを実際にどのように利用したかを知りたがっています。あなたのサーバーがそれをリッスンしていなければ、Appleはあなたの関与なしに決定を下します。このガイドでは、開発者向けのApp Store返金プロセスをステップごとに解説し、よく詰まりやすいポイントを指摘します。iOSにおける返金対策をより広く知りたい方は、 RefundSensorのApp Store返金対策ページでも解説されています。
簡単な回答
CONSUMPTION_REQUEST通知は、顧客が返金をリクエストした際に、Appleが利用状況の詳細を尋ねる仕組みです。顧客がデータ共有に同意していた場合、あなたのサーバーは12時間以内にSend Consumption Information Axz`PIを呼び出し、配信状況と利用状況を報告する必要があります。Appleはその情報を考慮して最終的な判断を下します。返金を承認したり、結果を保証したりすることはできません。
Apple CONSUMPTION_REQUESTとは?
CONSUMPTION_REQUESTは、App Store Server Notifications V2における通知タイプの一つです。顧客が返金リクエストを開始するたびにAppleから送信され、消費型アイテム、非消費型アイテム、非更新型サブスクリプション、自動更新型サブスクリプションなど、すべての製品タイプが対象となります。
これは命令ではなく、質問だと考えてください。Appleは誰かに返金するよう指示しているわけではありません。あなたが知っている情報を尋ねているのです。最終的な決定を下すのはあくまでAppleであり、あなたの回答はAppleが検討する要素の一つに過ぎません。
Appleの返金ワークフローの仕組み
ここでは2つのことが起こりますが、混同されがちです。通知を受け取ることは自動的に行われます。一方、利用状況情報を送り返すのは、あなたのサーバーがそれを実行した場合のみです。
顧客がAppleに返金を依頼します。
Appleがあなたの V2通知URLにCONSUMPTION_REQUESTを送信します。
あなたのサーバーが、その顧客が利用状況データの共有に同意したかどうかを確認します。
同意していた場合、あなたのサーバーは12時間以内に利用状況の詳細を送信します。
Appleが判断を下します。返金が承認された場合、REFUND通知が続きます。
ステップバイステップの実装ガイド
最初から最後までのセットアップ手順は以下のとおりです。
通知URLを追加します。 App Store Connectで、あなたのサーバーのHTTPS URLを入力し、Version 2を選択します。
素早く応答します。 200から206の間のステータスで応答してください。40xや50xを返すと、Appleは再試行します。
署名を確認します。 V2のペイロードには署名が付いています。内部の内容を読む前に検証してください。
顧客を特定します。 トランザクションを自社データベース内のユーザーと照合します。
同意を確認します。 同意がなければ返信はしません。
APIを呼び出します。 App Store Connectで発行されたIn-App Purchaseキーで認証したApp Store Server APIリクエストでデータを送信します。
ログを記録します。 何を、いつ送信したかを記録しておきます。
開発者としてApple返金リクエストに対応する方法
まずは必ず同意から始めてください。そのあとで、実際に何が起きたのかをAppleに伝えます。ここで価値を生むのは具体的で誠実なデータですので、内容を誇張しないようにしてください。
2つのケースを見てみましょう。
あるプレイヤーがコインパックを購入し、1日のうちにほとんどを使い切りました。この大量の利用状況を報告してください。Appleに返金を拒否するよう求めるのは妥当な選択です。
ある定期購入者が1年分の料金を支払いましたが、あなたのサーバーがダウンしており、コンテンツが一度も読み込まれませんでした。この場合は配信されなかったことを報告してください。ここでは、返金を承認することが誠実な対応かもしれません。
あなたの返金に関する希望はあくまで提案です。Appleはそれに従う義務はありません。
Apple Send Consumption Information APIの解説
Send Consumption Informationエンドポイントは、トランザクションID(/inApps/v2/transactions/consumption/{transactionId})に紐づいたPUTリクエストです。CONSUMPTION_REQUESTが届いた後に呼び出し、Appleは12時間以内の返信を求めます。
リクエストボディは、5つのフィールドを持つ ConsumptionRequestオブジェクトです。
customerConsented: 顧客がデータ共有に同意したかどうかです。trueである必要があり、そうでない場合、AppleはHTTP 400エラーでこの呼び出しを拒否します。
deliveryStatus: アプリが正常に動作する購入内容を配信したかどうかです。
sampleContentProvided: 事前に無料サンプルやトライアルを提供したかどうかです。
consumptionPercentage: ミリ単位での利用量です。
refundPreference: あなたが希望する結果です。
いくつかの点でつまずきやすいルールがあります。deliveryStatusがDELIVEREDでない場合は、consumptionPercentageを0に設定してください。そうしないとリクエストは失敗します。GRANT_PRORATEDを指定した自動更新型サブスクリプションの場合、consumptionPercentageは省略してください。Appleが自動的に算出します。そして同意の取得はあなたの責任です。Appleは、これにApp Tracking Transparencyのプロンプトを使用しないようにとも述べています。
App Store Server Notifications V2の統合
App Store Server Notifications V2は、Appleがあなたのサーバーに通知を送る仕組みです。TLS 1.2以降をサポートする、安全なHTTPS URLが必要です。
CONSUMPTION_REQUESTは数多くの通知タイプの一つに過ぎません。REFUNDやREFUND_REVERSEDなどの他のタイプは、ケースがどのように終了したかを伝えます。返金処理のコードが更新処理のコードと混在しないよう、各タイプに専用のハンドラーを用意しましょう。App Store Connect側の実際の動きを見てみたいですか? Refund SensorのApple設定ガイドで、キーと通知URLについて解説しています。
避けるべきよくある間違い
通知を受け取るだけで終わってしまう。 CONSUMPTION_REQUESTは、あなたのサーバーがデータを送り返すまで何も起こしません。
同意を無視してしまう。 顧客からの同意がなければ、返信はできません。
12時間の期限を守れない。 これらの通知は夜間や週末にも届きます。キューを使用し、アラートを設定しておきましょう。
整合性のない組み合わせを送信してしまう。 配信されなかった購入に対して利用率を設定すると失敗します。
署名確認を省略してしまう。 まず検証し、そのうえで信頼してください。
応答が遅い。 成功コードを速やかに返し、重い処理はバックグラウンドで行ってください。そうしないとAppleは再試行を続けます。
ユーザーを特定する手段がない。 トランザクションを顧客に結びつけられなければ、報告できる実質的な情報はありません。
App Store返金ワークフローを自動化する方法
12時間の制限時間を手作業で見張りたい人はいません。App Store返金ワークフローを自動化したいなら、作業を小さなステップに分割しましょう。
通知を受け取り、即座に成功コードを返します。
イベントをキューに入れます。
ワーカーがそれを検証し、ユーザーを特定し、同意を確認します。
ワーカーは保存された利用状況データからリクエストを構築し、APIを呼び出します。
結果を記録し、失敗した場合は誰かに通知します。
これにより、一貫した回答、明確な監査証跡が得られ、誰も午前3時に起きている必要がなくなります。これを自分で構築することも、RefundSensorのようなサービスにパイプラインを任せることもできます。
開発者のためのベストプラクティス
セッション数、使用されたクレジット、開かれたコンテンツなど、実際の利用状況データを保存してください。保持していないデータを報告することはできません。
利用規約やオンボーディングに明確な同意ステップを設け、同意がいつ与えられたかを記録してください。
返金ルールを一度文書化し、コードに組み込んでください。その場ごとに判断するのではなく、ルールに従いましょう。
本番公開前に、サンドボックス通知でテストしてください。
あとで購入者を特定できるように、すべての購入にアカウントトークンを付与してください。その方法については、こちらの appAccountTokenガイドで解説しています。
月に一度、返金結果を見直してください。不自然な急増は、機能の不具合やわかりにくいペイウォールを示している場合があります。
まとめ
Appleの返金ワークフローは、大きく2つの要素に分けられます。AppleがCONSUMPTION_REQUESTを送信し、あなたがそれに応答するかどうかを選択します。顧客が同意していた場合は、12時間以内にSend Consumption Information APIを通じて誠実なデータを送信してください。最終的な判断を下すのはやはりAppleです。
最初のステップとしておすすめなのは、V2通知URLが稼働していること、そしてあなたのサーバーがトランザクションをユーザーと照合できることを確認することです。この2点を確認しておくだけで、後々の多くの問題を防ぐことができます。
よくある質問
顧客が返金を依頼した際にAppleが送信するV2メッセージで、利用状況の詳細情報の提供を求めるものです。
Appleは通知から12時間以内の返信を求めています。
はい、必要です。同意がない場合は返信しないでください。customerConsentedがtrue以外に設定されたリクエストは拒否されます。
必ずしもそうとは限りません。Appleはそのデータを判断材料として使用しますが、最終的な決定を行うのはApple自身です。
消費型アイテム、非消費型アイテム、非更新型サブスクリプション、自動更新型サブスクリプションです。
