Google Play Billing for Android apps that sell digital features

A paid feature in an Android app can be a subscription, an extra capability, digital content, or cloud software access. If users can buy that digital good or service inside an app distributed on Google Play, Google’s Payments policy generally requires Google Play’s billing system for the purchase unless a specific policy allowance applies. The part that trips up product teams is often not the checkout screen. It is deciding what each SKU sells, where the customer can use it, and whether a regional program changes the default.

This guide gives you a practical way to classify an offer before implementation. It does not replace Google Play’s current Payments policy or program terms. Check the official policy for your app’s category, countries, and exact purchase flow before you submit.

Start with the thing the customer buysCopy Anchor Link

Write down each in-app purchase as a customer-facing item, not as an internal product name. A SKU called “Pro” may grant access to software features, stored data, a course, or a physical service. Those are different policy questions. Describe the entitlement in one sentence: what the buyer receives and where they can use it.

Google Play’s policy says its billing system is required for in-app purchases of digital goods and services distributed on Google Play, unless otherwise permitted. Its examples include virtual items, subscriptions, app functionality and content, and cloud software and services. A fitness subscription, an ad-free app tier, a premium feature, and extra cloud storage therefore deserve careful review if they can be purchased in the Play-distributed app.

Do not assume that a product is physical just because it has a physical-world use. A workout plan delivered as in-app digital content differs from a gym membership or a personal training appointment. Classify the thing being purchased and the way it is fulfilled, then compare that description with the official policy.

Separate digital purchases from physical transactionsCopy Anchor Link

Google’s help page distinguishes digital goods and services from physical goods and physical services. Purchases such as groceries, clothing, transportation, airfare, and food delivery are examples that are not supported by Google Play’s billing system. The same page says payment of a credit card or utility bill is not supported through Play Billing.

Mixed catalogs need a SKU-level review. For an item combining digital and physical components, Google says Play Billing must be used for SKUs that include more digital goods or services than physical goods or services, and for SKUs marketed to users as digital goods or services. Do not decide based only on the company’s overall business model or the category of the app. One app can contain different purchase flows that need different classifications.

A simple review table can make the ambiguity visible:

Use the table to route questions to the right reviewer, not to decide exceptions by shorthand. If an offer combines entitlements, describe the components and check the current policy wording for the exact SKU.

Check whether the app sells access or only uses an existing accountCopy Anchor Link

A consumption-only app lets users access digital goods or services purchased elsewhere but does not enable them to purchase access from within the app. Google says a Play app may be consumption-only even when it is part of a paid service. A user might sign in and view content that was bought through another channel.

The key detail is the complete in-app journey. A sign-in screen on its own does not establish that the app is consumption-only. Look at links, buttons, prompts, and language throughout the product. Google says apps may not lead users in the app to a payment method other than Google Play billing unless an applicable policy section or program allows it. That restriction includes links that can lead to an alternate payment method and language that encourages a user to purchase digital items outside the app.

Google distinguishes this from communications outside the app: its help page says developers can use email and other off-app channels to discuss alternate purchase options. For consumption-only apps, the page also describes cases where additional purchasing information may be shown without a direct link. Read the exact policy conditions rather than treating these examples as blanket permission for every app.

Treat exceptions as a separate policy checkCopy Anchor Link

Some transactions and programs are treated differently, and they are not one general “alternative billing” exception. Google’s policy page lists categories that do not require Play Billing in certain situations, such as a qualifying one-to-one online paid service that is between two individuals and is not available for replay in a Play-distributed app. It also describes consumption-only apps, in-app gift cards, earned or awarded reward points, and certain services that cannot be consumed in the app.

Regional programs add their own eligibility and implementation requirements. The policy page describes alternative billing options in certain regions, and external offers programs for users in the European Economic Area subject to program terms. It also describes requirements for certain U.S. options while a court order remains in effect. Availability, enrollment, disclosures, and user experience can depend on the applicable program. Do not infer that a program is available to your app because a similar app uses it.

If your case seems to fit an exception, record the exact policy section, program, market, and customer journey you believe applies. Then verify the current terms and eligibility. Keep that evidence with the release decision so the implementation does not rely on a remembered summary.

Map the decision before you build checkoutCopy Anchor Link

Before adding a payment screen or choosing an SDK, answer these questions for every purchase:

1. What does the buyer receive: digital functionality, digital content, a cloud service, a physical good, a physical service, or a combination?
2. Can the customer purchase that entitlement from inside the Play-distributed app?
3. Can the entitlement be accessed or consumed inside the app?
4. Does the app contain a link, button, or message that directs the user to another payment method?
5. Is there a specific policy allowance or regional program that applies to this offer and market?
6. What evidence supports that classification, and who reviewed it?

If the first answer is “digital” and the purchase is enabled inside the Play app, treat Play Billing as the default until you confirm an applicable allowance. If the app only grants access to something purchased elsewhere, inspect the full experience against the consumption-only requirements. If the purchase is physical, do not route it through Play Billing just because it appears in an Android app. For a mixed bundle, examine each SKU and its marketing.

That decision work can change the architecture. You may need to maintain distinct product identifiers, entitlement checks, receipts, and customer support paths. Avoid designing one generic checkout route first and trying to classify purchases afterward. The payment method follows the actual goods, services, and policy terms.

Keep policy review separate from fee comparisonsCopy Anchor Link

This article focuses on when to use Play Billing, not what any provider charges. Fee schedules, regional programs, and contract terms can change, and a program’s headline rate does not establish that your app qualifies. Check Google’s own current terms for the program you intend to use. For iOS, our Apple EU payment options guide covers a separate storefront and policy context; do not carry assumptions from one platform into the other.

A reliable launch note should name the SKU, describe its entitlement, identify where it can be purchased and used, state the policy basis, and link to the current source the team reviewed. If anything remains uncertain, mark it unresolved and get the policy interpretation before finalizing the checkout flow.

Release checklistCopy Anchor Link

Before shipping a digital purchase in a Play-distributed app, confirm:

• The SKU description matches what the customer receives.
• Digital functionality, content, and cloud access have been reviewed as digital goods or services.
• Physical goods and services have not been classified as digital solely because they are ordered in the app.
• Mixed digital and physical SKUs have been checked individually.
• A consumption-only claim matches the full app journey, including links and purchase prompts.
• Any exception or regional program has been verified against current eligibility and implementation terms.
• The chosen payment flow matches the policy conclusion for this SKU and market.
• Support and entitlement handling have been considered alongside checkout.

SourcesCopy Anchor Link

• Understanding Google Play’s Payments policy — Play Console Help