アプリ内課金とレシート検証

なぜアプリは決済結果を信用できないのか

アプリ内課金（In-App Purchase）の出発点は、「アプリ自身は決済を処理しない」という制約です。クレジットカード情報を扱うのはApp StoreとGoogle Playであり、アプリが受け取るのは「この購入が成立した」という署名付きの証跡（レシート／購入トークン）だけです。ここで重要なのは、この証跡を端末上のコードが評価して権限を付与してはいけない、という点です。端末はユーザーの支配下にあり、ジェイルブレイクや改造クライアント、中間者的なプロキシによって「購入成功」という応答を偽造できます。したがって購入の真偽を確定できるのは、ストアのサーバーに問い合わせるか、ストアが署名した証跡をサーバー側で検証したときだけです。この非対称性が、アプリ内課金設計のすべての土台になります。

商品タイプと状態モデル

課金商品は3種類に大別され、それぞれ「所有」の意味と状態管理の重さが異なります。

横にスクロール

消耗型で最も事故が起きやすいのは二重付与です。付与処理と「消費確定（iOSのfinishTransaction／AndroidのconsumeAsync）」の間でアプリが落ちると、再起動時に同じトランザクションが再送されます。これは異常ではなく、ストアが「消費確定されるまで購入を保持し続ける」仕様の帰結です。したがって付与はトランザクションIDを冪等キーにして「未処理なら付与、処理済みなら黙ってスキップ」と設計し、付与のコミット後に消費確定する順序を守ります。非消耗型は所有が一度きりである一方、機種変更や再インストールで権利を取り戻す復元フローが必須になります。

サブスクリプションのライフサイクル

自動更新サブスクリプションは、単なる「有効／無効」の二値ではなく、複数の状態を遷移する存在として扱う必要があります。ユーザーが操作しなくても、時間の経過と課金結果に応じてサーバー側の状態が勝手に変わっていくのが本質です。

[購入] → active(有効)
   ├─ 期限到来 & 課金成功 → active(自動更新)
   ├─ 期限到来 & 課金失敗 → billing_retry / grace_period(猶予)
   │        ├─ 猶予中に回収成功 → active
   │        └─ 猶予切れ         → expired(失効)
   ├─ ユーザー解約         → active のまま期限まで → expired
   └─ 払い戻し(refund)     → revoked(即時失効)

ここで見落としやすいのが猶予期間（grace period）と課金リトライ（billing retry）です。カードの一時的な残高不足などで更新に失敗しても、ストアは即座に失効させず一定期間リトライします。この間、ユーザーにサービスを継続提供するか止めるかはアプリ側のポリシー判断であり、状態を正しく区別できていないと「支払っているのに使えない」あるいは「失効したのに使えたまま」という不整合が生じます。有効期限（expiry date）はクライアントが計算するのではなく、ストアが返す値をサーバーが権威データとして保持します。

サーバー側レシート検証：2つのモデル

検証方式はプラットフォームで設計思想が分かれます。要点は「端末が申告するデータではなく、ストアが署名・保証するデータを、サーバーが独立に確かめる」ことです。

iOSは歴史的に、端末が受け取ったレシートblobをAppleの検証エンドポイントに丸ごと送る方式でしたが、StoreKit 2以降は各トランザクションがJWS（JSON Web Signature）として署名され、Appleの証明書チェーン（x5cヘッダの証明書鎖）をサーバーが検証すれば、Appleへ問い合わせずとも真正性を確認できます。加えてトランザクションIDをキーにApp Store Server APIへ問い合わせれば、失効や払い戻しを含む最新の権威状態を取得できます。Androidは購入トークン自体が不透明で、それ単体では何も分かりません。サーバーがGoogle Play Developer APIにトークンを渡して初めて、購入が有効か・acknowledgeされたか・サブスクの期限がいつかが返ります。

払い戻し通知と不正対策

購入時点の検証だけでは不十分です。購入は成立しても、その後に払い戻し（refund）やチャージバック、家族共有の解除、サブスクの解約が起こり、権利が遡って消えることがあるからです。これらのイベントはユーザーがアプリを開かないまま発生するため、アプリからのポーリングでは取りこぼします。そこで両プラットフォームは、状態変化をサーバーへ能動的に push するサーバー間通知を提供します。iOSのApp Store Server Notifications V2、AndroidのReal-time Developer Notifications（Cloud Pub/Sub経由）がそれで、更新成功・失効・払い戻し・返金・値上げ同意などの種別を含むイベントをWebhookで受け取り、サーバーの購読状態を更新するのが正しい運用です。

不正対策として実務で効くのは次の軸です。

• サーバー間検証を正本にする。前述のとおり、端末の申告ではなくストアAPI／署名検証の結果で権限を付与・剥奪する。
• 冪等性で二重付与を防ぐ。トランザクションIDや購入トークンを一意キーにして、同一購入の再送を安全に無視する。
• 通知で失効を即時反映する。払い戻し・チャージバック通知を受けたら該当ユーザーの権利を revoke し、共有アカウントでの継続利用を断つ。
• 異常検知を併用する。同一レシートが多数アカウントで使い回される、返金率が突出して高いといったパターンを監視し、リセラー詐欺やレシート共有を検出する。

まとめ

アプリ内課金は、アプリが決済結果を信用できないという一点から設計が決まります。端末が受け取るのは署名付きの証跡に過ぎず、権限付与の正本はサーバーがストアの署名やAPIで検証した状態に置きます。消耗型は冪等な付与と消費確定、非消耗型は復元、サブスクリプションは自動更新・猶予期間・払い戻しを含むライフサイクルの追跡という、タイプごとの状態モデルを正しく持つことが要です。そして購入時の検証だけで終わらせず、App Store Server NotificationsやReal-time Developer Notificationsによるサーバー間通知で失効・返金を即時に反映することが、売上の取りこぼしと不正の両方を防ぐ近道になります。課金権限を安全に扱う土台は、/mobile-development/mobile-app-signing-provisioning/ の署名・配布の信頼モデルや、/mobile-development/mobile-app-sandbox-permissions/ の権限・セキュリティの原則と地続きです。オフライン時の一時的な機能提供とサーバー正本の整合は /mobile-development/mobile-offline-first-sync/ の同期設計、失効通知の受信は /mobile-development/mobile-push-notification-architecture/ と併せて理解すると全体像がつながります。