Apple返金リクエストを追跡し、期限内に対応する方法

ほとんどのチームにAppleの返金を追跡しているかと聞けば、「はい」と答えるでしょう。では何を保存しているのかと聞くと、実際には返金1件につき1行、事後に書き込まれた日付と金額だけ、ということが判明します。

それはログであって、追跡ではありません。返金があったことは分かります。しかし、その過程でAppleから何か問い合わせがあったのか、誰かが回答したのか、その回答が受理されたのか、その顧客のアクセス権が実態と一致しているのかは分かりません。

このギャップが重要なのは、このプロセスの一部には期限があるからです。Appleはあるステップに12時間の猶予を設けており、それを過ぎると再開はできません。追跡の仕組みではなく全体像を知りたい場合は、モバイルアプリ収益を失わずにApp Storeの返金を管理する方法に関するガイドをご覧ください。本記事では、何を記録し、いつ行動すべきかを扱います。

主なポイント

• 返金の最終判断はAppleが下します。開発者がリクエストを承認・却下することはありません。

• 返金リクエストは複数の異なる状態を経ます。最後の状態だけを保存すると、有用な情報の大半が失われます。

• 一部の返金ワークフローでは、同意を得たうえで、12時間以内に消費情報を送信する機会が与えられます。

• 回答を送信することと、それが受理されることは別物です。試行ではなく結果を追跡してください。

• 返金の結果がエンタイトルメントのロジックと収益記録に反映されなければ、追跡は完了していません。

• 自動化が主に防ぐのは、イベントの見落としと期限切れです。Appleの判断には影響しません。

Apple返金リクエストの追跡とは

Apple返金リクエストの追跡とは、最初の通知から、それを締めくくるエンタイトルメントの更新まで、返金リクエストが自社側で経るすべての状態を追いかけることです。返金の記録ではなく、プロセスの記録です。

これらの状態が重要なのは、それぞれが本当に異なるイベントであるにもかかわらず、チームがしばしば一つにまとめてしまうからです。

自社のプロダクトに関係するのは最後の行だけです。その上にあるすべては、最後の行を正しく処理できるかどうかを左右します。「返金承認」しか保存していないチームは、なぜ顧客がまだアクセス権を持っているのか、Appleが問い合わせたときに誰かが回答したのかを説明できません。

開発者はどのようにApple返金リクエストを追跡するのか

開発者は、Appleのサーバーサイド通知システムと自社のトランザクション記録を通じて、Appleの返金アクティビティを追跡します。正確な経路は、イベントの種類と、Appleが情報提供を求めているかどうかによって異なります。イベントは、 App Store Server Notificationsで設定したURLに、バックエンドが検証・処理する署名付きペイロードとして届きます。

ハンドラーで区別しておくべき返金関連イベントは2種類あります。一方は何かを求めてくるもの、もう一方は何が起きたかを伝えるものです。

求めてくる側は、 AppleのCONSUMPTION_REQUEST通知です。Appleが返金リクエストを評価する間に、購入に関する情報を求めていることを意味します。これは返金ではなく、常に届くとは限らないという前提でハンドラーを書いておくべきです。

伝える側は結果をカバーします。承認されればREFUND、却下されればREFUND_DECLINED、Appleが以前に認めた返金を取り消した場合はREFUND_REVERSEDです。3つ目は、ほとんどのハンドラーが忘れているものです。

この両方の土台にあるのが自社のトランザクションストアで、これがあって初めてどれも読み解けるようになります。通知はAppleの識別子を参照するため、照合する購入記録がなければ、何にも紐づけられないイベントを抱えることになります。

開発者が追跡すべき情報は何か

情報の出所で分けて考えましょう。権威ある情報源は片側だけだからです。

Appleからトランザクションペイロードで届くもの:トランザクション識別子とオリジナルトランザクション識別子、プロダクト識別子、購入日、そして返金されたトランザクションについては取り消し日と取り消し理由です。この理由フィールドは、アプリ内の問題による返金とそれ以外の理由による返金を区別するもので、見た目以上に役立ちます。

アカウントトークンはその中間に位置します。購入時に自社で生成して付与し、Appleがペイロードで返してくるため、トランザクションから特定のユーザーへとたどれます。

それ以外はすべて自社で維持するものです。内部ユーザー識別子、通知タイプと受信日時、回答が必要だったかどうか、何を送信し何が返ってきたか、その時点のサブスクリプション状態、処理後のエンタイトルメント状態、そして返金が計上されたレポート期間です。

この2つのタイムスタンプは、実は一式の中で最も有用なフィールドです。Appleのイベントと自社のアクションの間の時間差こそ、追跡が機能しているかどうかを測る唯一の正直な指標です。

App Storeの返金を追跡する手順

1. 返金関連イベントを受信する

イベントは設定したサーバーエンドポイントに届きます。設定が誤っていたり障害が起きていたりしても、返金はそのまま進み、こちらにはエラーも出ないまま、単に何も知らされないだけです。

2. 通知を検証する

ペイロードに基づいて行動する前に、Appleの証明書チェーンに対して署名を検証し、バンドルIDを確認してください。受信したものを何でも信頼するエンドポイントは、第三者が書き込めるエンドポイントです。

3. 関連するトランザクションを特定する

デコードしたペイロードの識別子を購入記録と照合し、ユーザーアカウントを特定します。購入時にアカウントトークンを付与していれば、これは調査ではなく単なるルックアップです。

4. Appleが情報提供を求めているか確認する

通知タイプで分岐させます。消費リクエストには回答パスが必要です。結果通知には状態の更新が必要です。両者を同じように扱うと、回答期限を逃すことになります。

5. サポートされている消費情報を集める

自社の記録から値を取り出します。購入が提供されたか、サンプルコンテンツが提供されたか、どれだけ消費されたか。Appleの Send Consumption Informationのドキュメントに、フィールドと有効な値が定められています。その前に、必ず同意を確認してください。Appleはデータ共有に有効な顧客の同意を求めており、その取得は開発者の責任で、同意のないリクエストは即座に拒否されます。

6. 定められた期限内に送信する

Appleの現行ドキュメントでは、通知から12時間以内の回答が求められています。正確な値を送信し、成功したと思い込むのではなく、呼び出しが成功したことを確認してください。

7. 最終結果を追跡する

どの結果通知がいつ届いたかを記録します。障害中にパイプラインがイベントを取りこぼした場合、AppleのサーバーAPIで返金履歴を取得して欠落分を復旧できます。通知だけを信頼するのではなく、定期的な照合として実行する価値があります。

8. エンタイトルメントとアクセス権を更新する

返金が承認されたら剥奪し、返金が取り消されたら復元し、トランザクションの一部だけが取り消される按分のケースにも対応します。顧客が再びアプリを開くかどうかにかかわらず状態が正しくなるよう、サーバーサイドのイベントから駆動してください。

9. 収益記録と照合する

返金を正しい期間とプロダクトに紐づけます。これがないと、エンジニアリングと財務が同じ月について異なるバージョンを持つことになります。

Apple返金リクエストへの対応方法

対応とは、Appleが求めたときに、同意を得たうえで、期限内に消費情報を送信することです。何かを承認したり却下したりする形での対応はありません。それは開発者にはできないからです。判断を下すのはAppleです。

送信する内容は、自社の記録から取り出した、その購入で実際に起きたことを記述するものであるべきです。推定値や、望む結果に寄せて調整した数値ではありません。不誠実であるということに加え、それは正確に共有するという前提で同意を得たデータだからです。

ここに、ほとんどの追跡設定が見落としている運用上のポイントがあります。回答を送信することと、それが受理されることは別の状態です。呼び出しはバリデーションに失敗してエラーを返すことがあり、誰も結果を確認していなければ、失敗した送信はログ上で成功した送信とまったく同じに見えます。試行した事実だけでなく、レスポンスのステータスを保存してください。

Appleが返金を判断した後はどうなるか

Appleは結果を通知として送り、Apple側で請求を取り消します。そこから先の作業はこちらに移ります。

押さえておくべき区別があります。Appleが返金を承認したことは一つのイベントであり、自社システムがそれを正しく反映することは別のイベントです。Apple側の処理はこちらが何をしようと完了します。こちら側の処理が完了するのは、通知が届き、トランザクションと照合され、アカウントが特定され、そのアカウントのアクセス権が更新された場合だけです。

この2つが食い違うと、返金を受けたのに支払った分をすべて保持したままの顧客が生まれます。顧客側からは何も問題がないので、誰も報告しません。数か月後の照合で判明するか、あるいは判明しないまま終わります。

サブスクリプションには特に注意が必要です。返金された期間は通常、サブスクリプションを継続させるのではなく終了させるため、状態にそれが反映されていなければなりません。サポートにもこの記録が必要です。担当者が誰かにダッシュボードの確認を頼まなくても、何が起きたかを把握できるようにするためです。

手作業によるApple返金追跡が困難になる理由

不注意のせいではありません。作業の性質が、人の稼働時間と単純に合わないのです。

返金リクエストは顧客が送信したときにいつでも届き、回答期限は夜間も週末も進み続けます。各イベントには、ルックアップ、アカウントの照合、同意の確認、利用量の数値、送信、エンタイトルメントの更新が必要です。小さな作業ですが、時間に縛られ、繰り返しが多く、うまくいっているときは目に見えません。

そして規模が大きくなると様相が変わります。複数のアプリ、あるシステムにはトランザクションデータ、別のシステムにはアカウントデータ。誰もバックフィルしないため過去の返金データは薄いまま、エンタイトルメントの不整合はフラグも立たずに蓄積し、財務が四半期末に差異を発見します。回答期限が意味を持っていた時点はとうに過ぎています。

Apple返金追跡は自動化できるか

できます。そしてほぼすべてのステップが決定論的であるため、大部分は自動化すべきです。

自動化できるのは、返金イベントの監視と検証、届いた各リクエストの記録、トランザクションとアカウントの照合、通知タイプによる分岐、自社記録からの消費データの組み立て、回答期限と送信結果の追跡、エンタイトルメント状態の更新、そして返金履歴を照会可能な状態に保つことです。

できないのは、Appleに影響を与えることです。自動化しても返金が減るわけではなく、判断をどちらかに動かすこともできません。変わるのは、自社側のプロセスが一貫して、期限内に実行されるかどうかです。

RefundSensorがApple返金管理をどう支援するか

App Storeの返金管理はこの作業が属するカテゴリーであり、RefundSensorはその開発者側のために作られています。Appleの返金ワークフローを監視し、サポートされている回答ステップを自動化し、返金イベント、結果、記録を複数のダッシュボードに散らばらせるのではなく一か所に集約します。

実際には、誰かが通知を見張っていなくてもストアの期限内に回答が行われ、件数が増えても返金記録は正確なまま保たれます。

Appleの判断を変えることはできませんし、それはどのApple返金管理ソフトウェアにもできません。変わるのは、各リクエストがどれだけの手作業を残すかです。

これらのルールはどこに文書化されているか

上記の技術的な記述の裏付けとなるAppleの情報源は3つあります。直接読み、定期的に確認し直してください。この領域は一度ならず変更されています。

アプリまたはコンテンツの返金をリクエストする — 顧客向けのプロセスです。リクエストの発生源、顧客が案内される24〜48時間の更新目安、そして対象資格が国や地域によって異なるというAppleの注記を理解するのに役立ちます。

Send Consumption Information — 開発者側の回答ワークフローです。同意要件、12時間の期限、リクエストフィールドが記載されています。回答処理を構築する前に必ず読んでください。

App Store Server Notifications — 返金イベントがバックエンドに届く仕組み、署名付きペイロードの形式、そしてCONSUMPTION_REQUEST、REFUND、REFUND_DECLINED、REFUND_REVERSEDを含む通知タイプについて記載されています。

返金イベントをまだ人手で見張っているなら

手作業の追跡は、午前2時に通知が届き、誰かがダッシュボードを開く前に期限が閉じるその日まではもちます。この失敗は静かに起きるからこそ、高くつきます。

これが自社の状況に当てはまるなら、 RefundSensorがAppleの返金ワークフローの開発者側を担います。イベントを監視し、回答を期限内に収め、結果を記録とエンタイトルメントロジックに確実に反映させます。