Testing In-App Purchases & Subscriptions in Closed Testing: Play Billing v7

Monetizing your Android application with in-app products (IAP) or auto-renewing recurring subscriptions requires integrating the Google Play Billing Library (version 7.0+). However, testing financial transactions during the closed testing phase is notoriously tricky—real credit cards cannot be charged, products must be activated in Play Console, and backend webhook handlers must be validated.

This tutorial provides an end-to-end blueprint for setting up sandbox testing, configuring License Testers, and verifying server-side Real-Time Developer Notifications (RTDN) before your public launch.

1. Google Play Billing Library v7 Key Features

Play Billing v7 introduces modern transaction APIs that deprecate older legacy SKU parameters:

• Multiple Base Plans & Offers: A single subscription product can now contain multiple base plans (e.g., Monthly, Annual) and promotional offers (e.g., $1 first month, 7-day free trial) managed dynamically from the Play Console.
• Prepaid Plans: Users can purchase fixed-duration access (e.g., 30 days) without recurring payment authorizations.
• Installment Subscriptions: Allows users to pay for a committed annual subscription in monthly installments.

2. Setting Up License Testers in Google Play Console

To test digital purchases without charging real bank accounts or paying transaction fees:

1. Navigate to Play Console > Setup > License Testing.
2. Add the Gmail addresses of your testers to the "License Testers" list.
3. Under License Response, select RESPOND_NORMALLY (or choose test error states like ITEM_ALREADY_OWNED to test edge-case error handling).
4. Under Subscription Test Track, configure how test subscriptions renew:
   • Daily renewal: Renews every 5 minutes in sandbox mode.
   • Monthly renewal: Renews every 5 minutes (allowing you to test 6 months of renewals in 30 minutes).

3. Testing Subscription Lifecycles in Sandbox

License testers can simulate every complex subscription event in minutes:

4. Server-Side Verification (RTDN & Google Cloud Pub/Sub)

Never rely exclusively on client-side confirmation to unlock premium digital goods. Attackers using modified APKs or root tools can easily forge client-side Purchase.isPurchased() responses.

The Secure Verification Architecture:

1. Client completes purchase and receives a purchaseToken from Google Play.
2. Client sends purchaseToken and productId to your secure backend (e.g. Supabase Edge Functions or Node.js server).
3. Server calls the Google Play Developer API (purchases.subscriptionsv2.get) using service account credentials to verify the token authenticity with Google's servers.
4. Your server acknowledges the purchase within 3 days using purchases.subscriptions.acknowledge. If an app fails to acknowledge a purchase, Google automatically refunds the customer.

5. Top 3 Play Billing Errors and How to Fix Them

Error 1: "The item you requested is not available for purchase"

Cause: The app is signed with a debug keystore, the Play Console product is in "Inactive" status, or the tester's Google account is not added to the Closed Testing track list.

Error 2: "Authentication is required. You need to sign in to your Google Account"

Cause: The device running the test does not have a valid, active Google account linked in Google Play Store settings, or Google Play Services is outdated.

Error 3: Subscriptions Auto-Canceling After 3 Days

Cause: You forgot to call BillingClient.acknowledgePurchase() on the client or server. Always acknowledge all valid consumable or non-consumable entitlements.