連続的な返金の悪用はあなたに二重の損失を与える。ストアが用意した反撃の方法を紹介します
何度も繰り返し返金を求める顧客は偶然ではありません。返金の悪用は金額を返させるだけでなく、すでに費やした計算リソースまで奪います。そして両ストアは、そのパターンを結びつけるための本人性シグナル、Apple の appAccountToken と Google の難読化アカウント ID を用意しています。

要点
- 開発者が返金の悪用に対して証拠を提出できる返金フローは 2 つだけです。Apple の CONSUMPTION_REQUEST は 12 時間の猶予、Google Play の Review Refund API を通じたチャージバック審査は 24 時間の猶予があります。
- Apple の appAccountToken は、あなたが生成して購入に付与する UUID です。StoreKit がそれを生成された取引に紐付けるため、あなたのサーバーはすべての返金を、その購入を行った正確なアカウントまで遡ることができます。
- Google Play の難読化アカウント ID は、上限 64 文字のハッシュ化された文字列で、Google 自身がこれを使って、短時間に多数の端末が同一アカウントで購入するといった異常な活動を検出します。
- Google の難読化アカウント ID に平文の個人データを保存すると購入がブロックされるため、このフィールドは暗号化された値または一方向ハッシュでなければならず、生のメールアドレスであってはなりません。
- Google Play の voidedReason フィールドは、friendly_fraud と fraud を通常のリモース返金(remorse)とは別の理由として示します。これにより、繰り返す悪用者を自動的な返金して忘れる経路ではなく、審査キューに振り分けられます。
- Google は 2022 年に不正および悪用にあたる取引を 20 億ドル以上ブロックしたと述べています。そのシステムを支える本人性フィールドは、すべての購入で入力して初めて機能します。
- アクセス権を保持したまま返金された購入はすべて、すでに返したお金の上で払い続ける計算、ストレージ、API のコストです。そして連続的な返金者は、その請求額を意図的に増幅させます。
一件の返金は事業を営むうえでのコストです。同じアカウントが毎回買ったものを使い切ったうえで 4 回目の返金をするなら、それは返金の悪用であり、それはすべての購入があなたの管理する本人性を帯びている場合にのみ見えるパターンです。Apple も Google もその本人性を用意しており、返金やチャージバックが判断される前に、その本人性をストアの前に差し出すための狭い猶予を与えてくれます。その猶予を逃すか、あるいは本人性を一度も付与しなければ、連続的な返金者は初めて不満を抱いた顧客とまったく同じに見えます。以下では、その両者をどう見分けるか、そしてその違いが金銭でどれだけの価値を持つかを説明します。
なぜ返金の悪用は返金の問題ではなく本人性の問題なのか
返金はストアが判断します。顧客が申請するのを止めることはできませんし、ほとんどのフローではストアが承認するのを止めることもできません。あなたにできるのは、あるアカウントが以前にも同じことをしたかどうか、そして買った内容が実際に提供され使われたかどうかを判断することです。そのどちらも本人性についての問いです。すなわち、この取引の背後にいるのはあなたのどのユーザーか、そしてその履歴はどうか、ということです。もしあなたの購入が、自分のユーザー記録まで遡れる安定した識別子を帯びていなければ、そのどちらにも答えられず、すべての返金は文脈のないまま届きます。
それこそが本当の欠落です。返金の仕組みはポリシーによって固定されています。しかしそこに持ち込む証拠を組み立てるのは完全にあなた次第であり、それは返金の瞬間ではなく購入の瞬間から始まります。
証拠が結果を変える 2 つの猶予枠
あなたが送るものが判断を動かせるフローは、正確に 2 つだけです。顧客が消耗型アイテムまたは自動更新サブスクリプションの返金を求めると Apple の CONSUMPTION_REQUEST が発火し、あなたには 12 時間の回答時間があります。ユーザーが銀行に対して請求に異議を申し立てると Google Play のチャージバック審査が発火し、あなたには Review Refund API を通じて対応する 24 時間があります。その他のあらゆる返金、48 時間の Play セルフサービス返金、サポートによる返金、未承認購入の自動返金は、あなたの関与なしに判断されます。
これら 2 つの証拠経路は、取引がすでにあなたの識別子を帯びているとき、はるかに強力になります。Apple の消費情報には、アカウントの履歴や支出額に加えて appAccountToken を含めることができ、Google の審査は購入以来ずっと観察してきた難読化アカウント ID を頼りにできます。識別子のないアカウントは、提出すべき履歴のないアカウントです。
2 つの本人性フィールドを並べて見る
Apple と Google は同じ問題をほぼ同じ方法で、異なる名前と異なる規則で解決しました。どちらも、自分のユーザー記録を指し示す値を購入に刻印できるようにしています。どちらもデフォルトでは有効になっていません。どちらも購入時に設定しなければ無価値です。
Apple:appAccountToken
appAccountToken は、購入が始まるときにあなたが生成して渡す UUID です。StoreKit がそれを生成された取引に関連付け、それはあなたのサーバーが検証する取引データや、CONSUMPTION_REQUEST の際に返送する消費情報の中に現れます。それはあなた自身の値なので、メールアドレスや氏名を一切介さずに、ストアの取引をあなたのデータベース上のアカウントへ直接対応付けます。それは本物の UUID でなければならず、それ以外は拒否されます。Apple は後に Set App Account Token エンドポイントを追加し、過去の取引にトークンを付与または更新できるようにしました。これにはオファーコードの引き換えなど、アプリの外で行われた購入も含まれます。
Google Play:難読化アカウント ID
Google の対応物は setObfuscatedAccountId で、購入するアカウントに紐付く任意の文字列です。Google 自身のドキュメントはその目的について率直です。Google Play はこれを使って、短時間に多数の端末が同一アカウントで購入するといった異常な活動を検出し、一部の不正な取引を完了前にブロックします。それは 64 文字までに制限されており、平文の個人データを含んではなりません。そこに生のメールアドレスを保存すると Google は購入をそのままブロックします。このフィールドは暗号化された値または一方向ハッシュを期待しているためです。1 つのアカウントが複数のプロフィールを持つアプリのために、同種のフィールド setObfuscatedProfileId も存在します。
| フィールド | ストア | 種類と上限 | 設定者 | デフォルト | ストアがそれで行うこと |
|---|---|---|---|---|---|
| appAccountToken | Apple | UUID | あなた、購入時に | 未設定 | 取引をあなたのユーザーに紐付け、取引データと消費データで返す |
| obfuscatedAccountId | Google Play | ハッシュ文字列、最大 64 文字 | あなた、購入時に | 未設定 | 異常な活動を検出し、完了前に一部の不正をブロックする |
連続的な悪用者からの返金が実際にいくらかかるのか
返金そのものは請求額の中で最も小さな部分です。ストアが返金を承認すると、あなたは売上を返し、その分は帳簿に見えます。返金の行に現れないのは、いまや無料になった商品を提供するために費やしたすべてです。
実際の作業を引き起こす消耗型アイテムを思い浮かべてください。画像生成、モデル提供元への一括 API 呼び出し、動画の書き出し、クリエイターへの支払いなどです。顧客が使った瞬間に、あなたはその計算に対して支払っています。返金は価格を取り戻しますが、提供元への請求書は取り戻しません。連続的な返金者とは、内容が返金後も残ることを学んだ人であり、だからこそ彼らはそのループをもう一度回します。購入し、消費し、返金し、繰り返す。そのたびにあなたは提供コストを二度目に負担します。
さらにストア自身のコスト転嫁があります。2026 年 8 月 3 日から、その日付以降に行われた注文について、Google Play は購入価格と銀行のチャージバック手数料を開発者に移します。かつては主に Google の問題だったチャージバックが、あなたの売上に手数料を加えたものになり、繰り返し請求する者はそのたびにその数字を押し上げます。本人性フィールドこそが、24 時間の猶予枠の中で、不当な異議に反論するための証拠を Review Refund API に供給できるようにするものです。
Google はその規模を率直に述べています。2022 年に不正および悪用にあたる取引を 20 億ドル以上ブロックしたと言っています。その数字が存在するのは、それらのシグナル、その中には難読化アカウント ID も含まれますが、それらが入力されていたからです。空の本人性フィールドで購入を出荷するアプリは、その保護から自ら降りているのです。

ストアが判断する前に繰り返す返金者を捕まえる方法
すべての購入にあなたが所有する本人性でタグを付ける
すべての StoreKit 購入に appAccountToken を、すべての Play Billing 購入に setObfuscatedAccountId を設定し、どちらも自分のユーザー記録から生成します。Apple では、アカウントに対応付けた本物の UUID を使います。Google では、アカウントキーをハッシュ化し、平文で個人データが送られないようにします。これは購入時に行ってください。Google では、これが後から取り戻せない唯一の手順だからです。
その本人性をキーにした台帳を保つ
すべての購入、提供、消費イベント、返金を、その識別子に対して記録します。CONSUMPTION_REQUEST やチャージバック審査が届いたとき、そのアカウントの完全な履歴は、過去の返金も含めて、たった一度の照会で手に入ります。Apple の消費情報には、まさにこのための明示的なフィールドがあります。consumptionStatus、deliveryStatus、playTime、accountTenure、lifetimeDollarsPurchased、そしてあなたの refundPreference です。
voidedReason を読み、悪用者を別の経路に振り分ける
Google の購入が無効化されると、voidedReason フィールドがその理由を教えてくれます。friendly_fraud と fraud は通常のリモース返金(remorse)とは別の値です。それらは審査キューとより厳格なポリシーに振り分け、初回の返金と同じ自動経路には流さないでください。Google 自身の指針は多段階の警告モデルです。初回の違反者には警告し、繰り返す者にはより断固とした対応を取り、それでも続けるアカウントには購入を無効化します。
毎回、猶予枠の中で回答する
証拠は 2 つの猶予枠の中でしか意味を持ちません。CONSUMPTION_REQUEST への応答を自動化し、12 時間の十分内側で発火させ、チャージバック審査を自動化し、24 時間の内側で発火させます。遅れて提出した完璧な履歴は、ストアが決して読まない履歴です。
| 捕まえたいシグナル | それが存在する場所 | それを表面化させるフィールドまたはフロー |
|---|---|---|
| 同一アカウント、多数の端末、短い時間窓 | Google Play | 難読化アカウント ID の異常活動検出 |
| このアカウントは以前に返金している | あなたの台帳 | appAccountToken または難読化アカウント ID をキーにした履歴 |
| 内容は提供され消費された | Apple | 消費情報内の deliveryStatus と consumptionStatus |
| 異議は実は第一者による不正である | Google Play | voidedReason の値 friendly_fraud |
ストアがあなたのためにすること、しないこと
この分業を正確に押さえておく価値があります。ストアが悪用に対処してくれると思い込みがちですが、対処しないとき、ストアはたいていそれを教えてくれないからです。Google は難読化アカウント ID を積極的に使い、購入が完了する前に一部の不正をブロックし、そのシステムはプラットフォーム層で大きな割合を捕らえます。Apple はすべての返金を自ら判断し、あなたの消費情報を入力として扱いますが、決して票としては扱いません。どちらのストアも、あなたのために悪用者リストを維持したり、返金された消耗型アイテムをあなたの残高から差し引いたり、あなたに代わって繰り返す返金者に断りを入れたりはしません。本人性は、周縁ではストアが対処するものであり、それ以外のすべての場所ではあなたが対処するものです。
これこそ RefundHalt がすべてを購入の本人性でキー付けする理由です。同じアカウントの返金、チャージバック審査、消費リクエストは 1 つの履歴に解決されるため、連続的な返金者は、あなたがすでに支払った 4 枚目の請求書の後ではなく、彼らが初めて繰り返した時点でパターンとして浮かび上がります。
よくある質問
- アプリにおける返金の悪用とは何ですか?
- 返金の悪用とは、顧客が買ったものを受け取って使ったあとに繰り返し返金を求め、内容や便益を保持したまま金額を取り戻すことです。アプリストアでは通常、同じアカウントが消耗型アイテムやサブスクリプションを何度も返金する形か、あるいは正当な請求に銀行で異議を申し立てる第一者不正(friendly fraud)として現れます。
- アプリ内購入を特定のユーザーに結びつけるにはどうすればよいですか?
- Apple では、UUID を生成し、購入開始時にそれを appAccountToken として渡します。StoreKit がそれを取引に紐付け、取引データと消費データで返します。Google Play では、アカウントに紐付くハッシュ値で setObfuscatedAccountId を呼び出します。どちらも個人データを露出させずに、ストアの取引をあなた自身のユーザー記録へ対応付けます。
- Apple や Google は、あるアカウントが繰り返す返金者だと教えてくれますか?
- 直接には教えてくれません。Google は難読化アカウント ID を使って異常な活動を検出し、購入前に一部の不正をブロックします。Apple は消費リクエストの際にアカウント履歴を提出させてくれますが、どちらのストアも繰り返す返金者のリストを渡してはくれません。それは、本人性フィールドをキーにした自分自身の台帳から、あなたが自分で作り上げるものです。
- アカウント ID を設定すると、なぜ Google は私の購入をブロックするのですか?
- 難読化アカウント ID は平文の個人データを含んではならないからです。生のメールアドレスのようなものをそこに保存すると、Google Play は購入をブロックします。暗号化された値または一方向ハッシュを使い、64 文字の上限内に収めてください。
- 消費リクエストを通じて返金に反論すれば悪用を止められますか?
- 軽減はできます。CONSUMPTION_REQUEST は、ストアが判断する前にあなたの証拠がストアに届く 2 つのフローのうちの 1 つであり、アカウント履歴に加えて提供と消費のデータが、Apple が返品の悪用や第一者不正を見分けるのを助けます。ただしそれはブロックではありません。Apple は依然として自ら判断し、反論できないフローを通じて届く悪用は影響を受けません。
出典と参考資料
- Apple: appAccountToken (App Store Server API)
- Apple: ConsumptionRequest (App Store Server API)
- Android: BillingFlowParams.Builder.setObfuscatedAccountId
- Android: Fight fraud and abuse (Play Billing security)
- Google Play Developer API: Voided Purchases
- Google Play Billing: Provide refund and chargeback suggestions (Review Refund API)
- Android Developers Blog: Play Commerce prevented over $2 billion in fraudulent and abusive transactions in 2022
- Google Play Console Help: Updates to refund protection and chargeback cost responsibility
RefundHalt
App Store と Google Play の返金を自動処理
続きを読む
The refunds you cannot contest: what Apple and Google decide without asking you
Only two refund flows ever ask for your evidence: Apple's consumption request and Google Play's chargeback review. Everything else, the 48-hour Play refund, support refunds, voided purchases, unacknowledged trials, is decided without you. Here is the full map, what you can prevent, and what you can only record.
Apple's CONSUMPTION_REQUEST, explained: the 12 hours that decide your refund
When a customer asks Apple for a refund, Apple asks you first. Here's exactly what the CONSUMPTION_REQUEST notification contains, what Apple expects back, how to answer one end to end, and why most developers silently forfeit.