Play Billing Skills

45 RevenueCat skills for Android billing: Play Billing Library, subscriptions, RTDN and the RevenueCat SDK, setup to recovery.

  • 60 ★ on the repository
  • Last commit
  • Apache-2.0
Skill

Minimal access

Why this level

  • The skills give instructions on payments and Play Developer API credentials but run nothing themselves.
All reasons and checks

revenuecat/play-billing-skills

Install

In your terminal, with SkillFoxx CLI

npx skillfoxx add skills/play-billing-skills

Detects the agents on your machine, shows the access level and pins the version.

Other ways to install

Access and checks

How we review

Minimal accessThe tool runs nothing and makes no network calls.

  • The skills give instructions on payments and Play Developer API credentials but run nothing themselves.

This is third-party code. Review the repository files before installing.

What it does

Play Billing Skills turns two RevenueCat guides (on Google Play Billing and the RevenueCat Android SDK) into 45 agent recipes. Each skill covers one task and walks the agent through API calls, response codes, purchase verification and common production pitfalls. Topics include `integrating-pbl`, `rtdn`, `payment-recovery`, `plan-changes`, `price-changes`, `subscription-states` and `security`. The skills split into two collections. `google-play/` holds recipes for working directly with `BillingClient`, the Play Developer API and your own verification backend. `revenuecat/` solves the same tasks through the RevenueCat SDK, REST API and webhooks. There are skills for migrating between Play Billing Library 7, 8 and 9.

Who it is for. Android developers adding subscriptions and one-time purchases through Google Play or RevenueCat who want an agent to know the billing details.

Good fit when

  • You must set up RTDN and handle a failed renewal so the user gets a grace period.
  • A Play Billing Library migration from 7 or 8 to 9 is coming.
  • You must choose between a direct integration and RevenueCat: `revenuecat-vs-raw-billing` compares them.
  • The server needs to verify purchases and guard against fraud.

Not a fit when

  • You work on iOS: the set covers Android only.
  • You need a replacement for Google and RevenueCat docs: the skills complement them.
  • You need dashboard configuration: the skills do not replace it.

Example request

Set up RTDN and handling of a failed renewal so the user gets a grace period before losing access.

Limitations

The set covers Android only and complements the official Google Play and RevenueCat docs, with no replacement for them or for dashboard settings. API identifiers are tied to versions: the `purchases-android` 11.x SDK and Play Billing Library up to 9 are referenced. In Claude Code skills fire automatically from their description, while in Android Studio Agent and Gemini CLI their behaviour is not independently verified. Claude Code needs a flat `~/.claude/skills/<slug>/` folder, so skills are linked by the `install-skills.sh` script.

How to disable. Delete the skill symlinks from `~/.claude/skills/` and the cloned `~/play-billing-skills` folder. Rerunning the install script skips links that already exist.

FAQ

How do I install the skills in Claude Code?

Clone the repository into `~/play-billing-skills` and run `scripts/install-skills.sh`. The script links skills into a flat folder, and `--only google-play` installs one collection.

How do the `google-play` and `revenuecat` collections differ?

`google-play` fits direct work with `BillingClient` and your own verification backend. `revenuecat` handles the same tasks through the RevenueCat SDK, REST API and webhooks.

How do I use the skills in Cursor or Codex?

Automatic triggering exists only in Claude Code. In Cursor add a rule under `.cursor/rules/` pointing at the folder, and in Codex or Gemini CLI add a pointer in `AGENTS.md` or `GEMINI.md`.

Where do I start if unsure which layer I need?

Open `revenuecat/revenuecat-vs-raw-billing`. The skill sets side by side what each layer handles and what stays with you.

Do I need both collections?

No. Several names appear in both because the task is the same while the implementation differs. Install the one matching your architecture.

Discussion

No questions or reviews yet.

Skills
Official

The RevenueCat plugin runs subscriptions from your agent: projects, products, offerings, revenue data and mobile SDK skills

PluginBroad access79Repository stars
Official

Official set of 30 skills from the Android team: Jetpack Compose, AGP 9 upgrade, R8, Perfetto profiling, Navigation 3, CameraX, Google Play policies

SkillExtended access10.5KRepository stars

A single binary that drives Google Play Console: releases and rollouts, subscriptions, reviews and crashes, every command answering in JSON

CLIBroad access294Repository stars

Awesome Android Agent Skills

awesome-android-agent-skills

Skills for modern Android development for Copilot, Claude, Gemini and Cursor: Kotlin, Jetpack Compose, architecture, Hilt, Room

SkillMinimal access1KRepository stars

A Claude Code skill that builds Expo mobile apps with onboarding, paid subscriptions, AdMob ads, analytics and localization.

SkillExtended access114Repository stars

21 skills for Android and KMP in Claude Code, Codex and Copilot CLI: Compose, coroutines, Flow, networking, storage, Gradle

PluginMinimal access173Repository stars

README in short

Each skill traces back to one section of the RevenueCat source guides, so terms and recommendations match their publications. Skills cross reference each other by name: a migration names its prerequisite and a fix names its diagnostic.

README badge

Original SKILL.md

---
name: rtdn
description: Use this skill when setting up Real Time Developer Notifications (RTDN) for Google Play. Covers the full pipeline from Cloud Pub/Sub configuration through message parsing and processing all 18 subscription notification types (codes 1 to 13, 17 to 20, and 22).
license: Apache-2.0; see LICENSE
metadata:
  author: RevenueCat
  source: google-play-handbook chapter 10
  keywords:
  - android
  - play-billing
  - rtdn
  - cloud-pubsub
  - webhooks
  - notification-types
---

# Real Time Developer Notifications (RTDN)

RTDN pushes subscription and purchase state changes from Google Play to your backend within seconds. Use it as the primary signal for entitlement updates; polling the Play Developer API on a schedule is a fallback, not a substitute.

## Phase 1: Understand

Pin down the following before you write code:

- **What triggers a notification.** Google Play publishes a message to a Cloud Pub/Sub topic you own every time a subscription changes state, a purchase is voided, or (if enabled in the RTDN settings) a one time product is purchased or a pending one is canceled.
- **What the notification contains.** A `DeveloperNotification` JSON object with `packageName`, `eventTimeMillis`, and exactly one of `subscriptionNotification`, `oneTimeProductNotification`, `voidedPurchaseNotification`, `pendingRefundReviewNotification`, or `testNotification`. Subscription, one time product, and voided purchase notifications carry a `purchaseToken` (a pending refund review carries `orderId` and `pendingRefundToken` instead), not the full purchase state.
- **Who owns what.** You own the Pub/Sub topic and subscription in your own Google Cloud project. Google Play only has publish rights.
- **Delivery semantics.** Cloud Pub/Sub guarantees at least once delivery and does not guarantee ordering. Duplicates and out of order messages are normal.
- **The golden rule.** RTDNs are signals, not sources of truth. For every notification, call `purchases.subscriptionsv2.get` or `purchases.products.get` and update entitlements from the API response, not the notification type.

Decide push vs pull:

| Strategy | Pick when |
|----------|-----------|
| Push subscription | You have a public HTTPS endpoint and want a webhook style integration with retries handled by Pub/Sub |
| Pull subscription | Your backend has no public URL, needs batch processing, or wants fine grained control over consumption rate |

Push is the simpler default. You can swap strategies later without changing the Play Console configuration.

## Phase 2: Plan

Write the plan before provisioning anything.

### Infrastructure checklist

Report a problem