開発者が購入データを活用して返金リクエストに対応する方法

返金リクエストへの対応方法を解説するガイドの多くは、通知が来た時点から話を始めます。Appleから通知が来て、Googleから通知が来て、「こう返信すればいい」という内容です。それはそれでいいのですが、通知が届く頃には、有効な作業はすでに済んでいるか、すでに手遅れになっています。なぜなら、ある購入について何を言えるかは、それが発生した時点で何を記録しておいたかにかかっているからです。

そのため、この記事ではもっと前の段階、つまりチェックアウトの時点から話を始めます。返金リクエストが届いたときにどの購入データが重要になるのか、それをどこに保存しておくのか、そしてそれがストアが実際に重視する回答へとどうつながるのかを見ていきます。これまで購入に識別子を紐付けたことがない場合は、まず appAccountTokenと返金対策に関する記事をお読みください。以下の内容はすべて、トランザクションIDを特定の人物に結び付けられることを前提としています。

重要なポイント

• AppleとGoogleはどちらも返金の判断を自社で行いますが、現在はいずれもまず購入データの提供を求めてきます。Appleは12時間、Googleは24時間の猶予を与えてくれます。

• ストアが求めているのは詳細なログではなく、大まかな事実です。配信されたか、どれくらい使用されたか、サンプルを提供したか、そしてあなたの希望はどうかという点です。

• 購入ごとに保存しておく必要があるのは4つの情報です。誰が購入したか、いつ配信されたか、いつ使用されたか、そしてこのアカウントに対して過去に返金を行ったことがあるかです。

• Appleによると、返金リクエストの大半は購入から30日以内に届くとされています。データは少なくともその期間、現実的には90日間は保持しておきましょう。

• 返信を始めたアプリでは返金率がおよそ3分の1減少しますが、それも記録として示せるものがある場合に限られます。

ストアが実際に求めているもの

Appleのリクエストは小規模です。顧客がアプリ内購入の返金を申請すると、CONSUMPTION_REQUESTが届き、 Send Consumption Informationエンドポイントを通じて5つのフィールドで返信します。顧客がデータ共有に同意したか、購入が配信されたか、消費された割合(ミリユニット単位、つまり100,000がすべて使用済みという意味です)、無料サンプルやトライアルを先に利用していたか、そしてあなたの返金に関する希望です。Appleは以前、十数個のフィールドを求めていましたが、そのほとんどを削除しました。これは、Apple自身が顧客の履行履歴をすでに十分把握していると判断した結果だと私は見ています。

Googleの仕組みはチャージバック向けで、少し情報量が多くなります。返金審査保留通知がトークンとともにReal-time Developer Notificationsを通じて届きます。そのトークンを使って、 orders.reviewrefundに対し、同様のサンプルコンテンツフラグ、DECLINE・APPROVE・NEUTRALのいずれかの希望、任意項目としての消費率、そしてタイムスタンプ付きの利用イベントを最大1,000件までPOSTします。これは、Googleが2026年8月3日以降の注文に対するチャージバックについて開発者に課金するようになった今、より重要な意味を持ちます。

どちらのストアも、あなたの分析データのエクスポートを求めているわけではありません。求めているのは配信、消費、サンプル提供、希望であり、それ以外に保存しているすべての情報は、これらを正確かつ迅速に記入するために存在しているのです。

返金対応のための購入履歴:何を、どれくらいの期間保持すべきか

最低限必要なものは以下です。

チェックアウト時の識別子です。AppleではappAccountToken、GoogleではobfuscatedAccountIdです。これがなければ、返金リクエストにはトランザクションが記載されているだけで、それが誰のものかまったく分かりません。Appleのエンジニアは、ユーザーごとに少なくとも1つのoriginalTransactionIdを保持しておくことも推奨しています。これがあれば、 Get Transaction Historyを呼び出すことで、そのアプリがまだインストールされているかどうかに関わらず、その顧客の購入履歴をすべて取得できます。

配信記録です。コインを付与した、あるいはレベルを解除した時刻と結果を記録します。配信に失敗した場合は、そのとおりに記録してください。これは返金を承認してほしいと思うべき唯一のケースであり、それを偽って報告すると、後で必要になる信頼性を損なうことになります。

消費イベントです。すべてのタップを記録する必要はなく、購入が使用されたことを意味するイベントだけで構いません。例えばコインの使用、チャプターの開封、エクスポートの実行などです。Googleは最大1,000件まで受け付けます。Appleは割合だけを求めますが、記録していないものから割合を算出することはできません。

製品ごとのサンプルフラグです。この顧客はトライアル、プレビュー、無料プランを利用したでしょうか。どちらのストアでもYes/Noで答える項目ですが、見落とされがちです。

そのアカウントでの過去の返金履歴です。Appleはどのみち返金履歴を自ら考慮しますが、自社のルール判断のためにも必要になります。

保持期間について、Appleは返金リクエストの大半が30日以内に届くと述べ、それに応じて消費データを保存するよう勧めています。私たちは90日間保持していますが、それはGoogleのチャージバックがさらに遅れて届く場合があることと、ストレージが安価である一方、記憶を頼りに主張するのは得策ではないためです。

購入履歴が返金対応にどう役立つか

これが整っていれば、リクエスト対応はもはや判断の問題ではなく、単なる検索作業になります。

配信済みで完全に消費され、サンプルもなく、過去の返金もない場合はDECLINEに該当します。配信済みだがほとんど使われておらず、1日以内にリクエストされた場合は、GRANT_FULLを選んでもコストはほとんどなく、拒否する方がむしろ印象が悪くなります。配信が自社側の問題で失敗していた場合は、承認してバグを修正しましょう。数週間にわたって部分的に使用された場合は、Appleにはこれに対応するGRANT_PRORATEDがあり、Googleでは消費率が同じ役割を果たします。

数字がそれを裏付けています。サブスクリプション型オーディオアプリのDipseaは2024年後半にAppleのリクエストへの返信を始め、約2週間で返金率が3%から1.9%に下がりました。チャージバックについては、AppchargeがPocketGamerに対し、証拠なしの異議申し立てが勝つ確率は20〜30%、証拠に基づくものは80%以上であると述べています。Refund Sensorを利用する800以上のアプリ全体では、対象となるリクエストの77%が成功裏に対応されており、負けたケースのほとんどは何も記録がなかったものでした。

購入履歴があってもできないことは、本来勝つべきではない議論に勝たせることです。顧客のデータがアプリを1回しか開いていないことを示しているなら、誠実な答えは返金を承認することです。

期限内に返金リクエストを処理する方法

両ストアにおける返金リクエストの処理プロセスには時間的な制約があるため、これは判断というより仕組みの問題です。通知は、あなたが登録しておいたエンドポイントに届きます。署名を検証し、トランザクションIDを取得し、ユーザーの配信・消費データを確認し、割合を算出し、あらかじめ定めておいたルールから希望を選択して送信します。何を、いつ送ったかを記録し、結果を待ちます。Appleの場合、結果はREFUNDまたはREFUND_DECLINEDの通知として届きます。REFUNDとなった場合は、同じ時間内にアクセス権を取り消しましょう。コンテンツを保持し続けたまま返金を受けた顧客は、同じことを繰り返す傾向があるためです。

つまずきやすい点が2つあります。1つは同意です。customerConsentedがtrueでない限りAppleは送信を受け付けないため、利用データを共有する許可は、最初のリクエストが届く前に利用規約に含めておく必要があります。もう1つはタイミングです。時間の制限は週末だからといって止まることはなく、意外と多くのリクエストが深夜に届きます。返金リクエスト管理の大部分は、常に何かが対応できる状態にしておくことです。運用面についてさらに詳しく知りたい方は、 Appleの返金リクエスト管理ガイドをご覧ください。

開発者向けの返金処理ソフトウェアか、自前のコードか

バックエンドチームがあれば、上記のパイプラインの構築は1週間程度の作業で済みますが、その後は継続的な運用業務となり、コストがかかるのはこの運用の部分です。

RevenueCatやAdaptyを利用している場合、どちらもSDKがすでに収集している利用データを使ってAppleの消費リクエストに回答でき、AdaptyはGoogleの審査にも対応しています。いずれにせよアプリにSDKを組み込んでいるなら、妥当な選択肢です。

Refund SensorはSDKなしで同じことを実現します。App Store Connect APIキーと通知用URLを接続するだけで、リクエストを受信し、期限内に回答を送信し、ケースごとのタイムラインを保持します。設定は数分で完了し、料金は一律です。詳細は Refund Sensorのサイトをご覧ください。

何を選ぶにしても、何も選ばないという選択を含めて、データ層の管理はあなた自身の責任です。開発者向けの返金処理ソフトウェアがどんなものであっても、あなたが記録していない配信記録を作り出すことはできません。

まとめ

返金対策は対応の問題として語られることが多いですが、実際にはその前段階にある記録の問題です。ストアが尋ねてくるのは4つの限定的な質問にすぎませんが、それに答えられるかどうかは、誰かが返金を望むよりずっと前、チェックアウトと配信の時点で下した判断にかかっています。

識別子を紐付け、配信と消費をタイムスタンプ付きで記録し、サンプルにフラグを立て、それらすべてを90日間保持しましょう。これが整っていれば、返金リクエストの処理方法は単なるルールとcronジョブになり、返金率はおのずと改善していく傾向があります。