# Revenuecat Testing

Use when testing RevenueCat purchases/subscriptions, setting up sandbox testing...

- Repository: https://github.com/evanca/flutter-ai-rules (668 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-10-30
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add evanca/flutter-ai-rules --skill revenuecat-testing -g -a claude-code -y`
Codex: `npx skills add evanca/flutter-ai-rules --skill revenuecat-testing -g -a codex -y`
Cursor: `npx skills add evanca/flutter-ai-rules --skill revenuecat-testing -g -a cursor -y`
Gemini CLI: `npx skills add evanca/flutter-ai-rules --skill revenuecat-testing -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add evanca/flutter-ai-rules`

## Description

Use when testing RevenueCat purchases/subscriptions, setting up sandbox testing, debugging a purchase/restore/trial, verifying entitlements or events, checking an app is ready for a RevenueCat experiment, or writing an IAP QA plan.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# RevenueCat Testing

Help a developer systematically verify their RevenueCat integration works before shipping, turning "I added RevenueCat, does it actually work?" into a concrete, checkable QA plan. The full use-case matrix, methods, platform differences, and the verifiable signal for each case live in `references/use_cases.md`. Read it for exact event names and preconditions; this file is the operating guide.

**The organizing principle:** every RevenueCat behavior has a **verifiable signal**, a specific dashboard event (`INITIAL_PURCHASE`, `TRANSFER`, `EXPIRATION`, `PRODUCT_CHANGE`, `CANCELLATION`), a `period_type` value, or a CustomerInfo/debug-log state. A test isn't "did the app not crash"; it's "did the expected event appear in the customer's history with the right fields." Always tie a test to its signal, or it isn't really testing anything.

## How to use this skill

1. **Get the setup facts**: platform(s) (iOS / Android / cross-platform / web billing), SDK (native, RN, Flutter, etc.), whether they've enabled debug logs and sandbox accounts yet, and what specifically they're trying to verify or why they think something is broken.
2. **Establish prerequisites first**, most "purchases don't work" reports are config problems visible before any purchase:
   - Debug logs on *before* `configure()` (iOS `Purchases.logLevel = .debug`; Android `setLogLevel(LogLevel.DEBUG)`), and check for **"Invalid Product Identifiers"** and error-level logs. Fix those before touching purchase flows.
   - Sandbox environment set up; multiple sandbox test IDs ready if any account-switching is in scope.
   - Point them at the debug overlay (`debugRevenueCatOverlay()` / `DebugRevenueCatBottomSheet`) to preview offerings and run test purchases quickly.
3. **Map their goal to use cases** from the reference and produce the plan (below).

The rest: https://github.com/evanca/flutter-ai-rules/blob/HEAD/skills/revenuecat-testing/SKILL.md