How to Set Up In-App Purchases on Google Play

Monetizing an Android app through in-app purchases requires coordinating two systems: the configuration inside Google Play Console and the billing integration inside your app's code. Getting both right is essential because a mismatch between what the console defines and what the app requests will result in purchase failures for users. This guide covers the console side in detail, with enough context on the code side to help you understand how the two connect.

Prerequisites before you begin

Before you can create any in-app products in Play Console, three things must be true: your app must have at least one approved release on any track (internal testing counts), your developer account must have an accepted payments profile, and your app must declare the billing permission in its manifest. Google enforces all three checks and will block product creation if any condition is unmet. The payments profile requirement in particular can delay new accounts by several days while Google verifies banking and identity information.

One-time products vs. subscriptions

Play Console separates in-app products into two categories. One-time products, sometimes called consumables or non-consumables depending on how your app handles them, are purchased once and either consumed (like currency) or permanently unlocked (like a feature upgrade). Subscriptions are recurring products with their own dedicated configuration screen that supports billing periods, free trials, introductory pricing, and multiple base plans within a single subscription product. For most apps, you will work with both types at different points in your monetization strategy.

Creating a one-time in-app product

Navigate to Monetize > Products > In-app products and click Create product. You will assign a product ID, which is a lowercase string that your app code will reference at purchase time and which cannot be changed after creation. Give the product a title and description that will appear on the purchase dialog shown to users. Then set the price: you can enter a price for your base country and let Google auto-convert to other currencies, or override prices per country manually. Once the form is complete, activate the product, because inactive products cannot be purchased, even in testing.

Creating a subscription product

Subscriptions are configured under Monetize > Products > Subscriptions. Each subscription has one or more base plans, and each base plan defines a billing period (weekly, monthly, annual, or a custom duration). Within a base plan, you can create offers such as a free trial or an introductory price that applies for the first one or two billing cycles. The architecture is intentionally layered: one subscription product ID can contain multiple base plans targeting different user segments, which is useful for offering a monthly and an annual option without creating separate products.

Key fields to configure carefully

• Product ID: permanent and referenced directly in code, so choose a clear, consistent naming convention before you start.
• Price: set in your local currency; Google applies exchange rates but manual overrides let you hit clean price points in major markets.
• Tax category: selecting the correct category affects how Google calculates and remits tax in applicable regions.
• Grace period (subscriptions only): gives users a short window to resolve payment failures before access is revoked.
• Resubscribe option: controls whether users can re-subscribe from the Play Store after canceling.

Testing purchases before going live

Google provides two mechanisms for testing without real charges. License testers are Google accounts you add in Play Console under Setup > License testing; these accounts can complete purchases in any release track and are refunded automatically. The second mechanism is the Google Play Billing Library's static test product IDs that simulate responses without hitting real purchase flows. Use license testers for full end-to-end integration testing and the static IDs only for unit-level logic tests, because the static IDs do not exercise server-side validation.

Validating purchases server-side

Every purchase your app processes should be verified against the Google Play Developer API from your server before granting access to the purchased content. The API returns a purchase state field that tells you whether the purchase is completed, pending, or canceled. Skipping server-side validation is a common mistake that leaves apps vulnerable to modified clients that generate fake purchase tokens. Google provides the products and subscriptions endpoints for one-time and subscription products respectively, both available through the Play Developer API.

Common setup mistakes to avoid

• Forgetting to activate a product after creating it, which makes purchases silently fail.
• Using the same product ID in multiple apps, since IDs are scoped per app.
• Not acknowledging purchases in code within three days, after which Google automatically refunds them.
• Setting a price below the minimum allowed in a given country.
• Skipping the payments profile setup and discovering the block only after publishing.