flutter-in-app-purchases について
Flutter アプリのアプリ内購入を実装する開発者向けのスキルです。ストア取引、検証、権利状態を非同期の照合プロセスとして扱い、冪等性、復元、アカウント境界を重視します。
主な機能
- 01ストアカタログ、取引、権利の区別
- 02完了取引の冪等な検証
- 03商品種別に応じた承認または消費
- 04復元、更新、アカウント切り替えへの対応
- 05フェイクとストアサンドボックスによるテスト
活用シーン
- 01保留中取引の完了後に権利を付与
- 02重複取引と承認復旧のテスト
- 03サブスクリプション変更と購入復元の検証
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/flutter-in-app-purchasesを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/purchase-lifecycle-and-entitlements.mdstore-testing-and-release.mdsubscriptions-and-restoration.md詳細
Flutter アプリ内購入
ストア課金は、ボタンのコールバックではなく、非同期の照合システムとしてモデル化してください。移行が明示的に依頼されていない限り、プロジェクトで現在使用しているストアパッケージ、サブスクリプションサービス、バックエンド、アカウントモデル、状態管理を維持してください。
明示的な許可なく、商品を作成したり、価格を変更したり、ビルドをアップロードしたり、稼働中のストア設定を変更したりしないでください。
事前確認
編集する前に、pubspec.yaml、SDK の制約、サポート対象のプラットフォーム、ストアパッケージとネイティブ設定、商品識別子、購入リスナーの所有者、権利付与の信頼できる情報源、バックエンドでの検証、認証、永続化、テスト、フレーバー、サンドボックスの設定を確認してください。フローを編集する前に、消費型、非消費型、サブスクリプションを区別してください。
次の3つの概念を明確に分けてください。
- ストアカタログ：商品、ローカライズされた価格、購入可否、オファー、ストアのメタデータです。
- トランザクション：保留中、購入済み、復元済み、キャンセル済み、失敗、消費済み、確認済み、またはストアがサポートするその他の完了状態です。
- 権利付与：アプリケーションがアカウントまたはデバイスに現在付与している、商品に応じた機能です。
ボタンのタップ、クライアントによる申告、未検証のペイロード、または保留中のトランザクションを根拠に、権利を付与してはいけません。検証済みの完了トランザクションを冪等に処理した後、商品タイプに応じてストアが要求する確認、消費、または完了処理を行ってください。
参照資料の条件付き読み込み
- リスナーの所有者、検証、冪等性、保留中のトランザクション、確認、消費、アカウントへの紐付けについては、購入ライフサイクルと権利付与を読んでください。
- 更新、猶予期間と保留状態、有効期限、復元または照合フロー、アップグレード、ダウングレード、アカウント切り替えについては、サブスクリプションと復元を読んでください。
- サンドボックスアカウント、商品の準備状況、中断されたフロー、プラットフォームのマトリックス、リリース時の証跡については、ストアのテストとリリースを読んでください。
境界
flutter-authenticationはアカウントへのサインインとセッションのライフサイクルを担当します。このスキルは、検証済みのトランザクションを正しいアカウントに紐付け、アカウント切り替え時の権利漏えいを防ぎます。flutter-networkingは汎用的な通信を担当します。このスキルはストアと権利付与に関するプロトコルのセマンティクスを担当します。flutter-persistenceは永続的なローカルストレージを担当します。キャッシュされた権利状態では鮮度を明示し、信頼できる失効情報を決して覆さないでください。flutter-securityは広範な脅威レビューを担当します。このスキルでは、信頼できる検証を必須とし、購入トークンの露出を最小限に抑えます。flutter-product-analyticsでは購入ファネルのイベントを監視できますが、権利付与の信頼できる情報源になってはいけません。flutter-build-releaseは署名済みアプリケーション成果物とアップロードを担当します。ストアへの公開は、引き続き明示的な外部アクションとします。
検証
決定論的な状態マシンテストにはフェイクを使用し、エンドツーエンドの証拠にはサンドボックスまたはテスト用トラックを使用します。成功、キャンセル、失敗、再起動後の保留中の完了、重複、配信後・確認前の復旧、復元、アカウント切り替え、オフライン時の照合、サブスクリプション状態の変化、利用できない商品を網羅します。
サンドボックス対応の準備では、シナリオのチェックリストだけで終わらせないでください。設定を変更する前に、アプリケーションとバンドルの識別子、フレーバーと環境、Android と Apple の署名、エンタイトルメントまたはマニフェスト、既存のストア商品、テストアカウント、バックエンドのルーティングを明示的に確認するよう求めます。前提条件、操作と中断箇所、想定されるストアとエンタイトルメントの状態、確認または完了の結果、観測可能な合否の証拠を含む、具体的で再現可能なケースを提示します。対象となるフローには、中断された購入を少なくとも1件、復元または照合のケースを少なくとも1件含めます。
どのストア、商品タイプ、アカウントモード、プラットフォーム、バックエンド経路を検証したかを明記します。購入シートの表示成功やクライアントコールバックだけでは、検証、エンタイトルメントの配信、確認、デバイス間での復元、更新処理が証明されたことにはなりません。