In-App Purchases and Subscriptions: App Store and Google Play Rules
If your app sells premium features, content or a subscription, Apple and Google set rules on how you take payment, what you must tell people before they pay, how they cancel, and how your system checks each purchase. This guide covers when the stores' billing is required, the types of products, subscription disclosures, cancellations and failed payments, and checking purchases on your own server. It draws on Apple's App Review Guidelines and developer documentation and Google Play's policies and billing documentation, checked on 3 November 2026.
- When the stores' billing is required
- Types of in-app products
- What a subscription must offer
- What to show before someone pays
- Managing and cancelling subscriptions
- Failed payments, grace periods and account hold
- Check every purchase on your server
- Users who also pay on your website
- A checklist
- Frequently asked questions
When the stores' billing is required
Apple's App Review Guidelines say in section 3.1.1: "If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase."
Google Play's Payments policy is similar: apps "requiring or accepting payment for access to in-app features or services, including any app functionality, digital content or goods" must use Google Play's billing system, apart from listed exceptions. It "must not be used" when payment is mainly for physical goods or services, such as "transportation services, cleaning services" or food delivery.
So a booking app for a cleaning company takes card payments through a normal payment provider, while a fitness app that sells premium workout videos uses in-app purchase. Both stores have regional exceptions and options for linking to other ways to pay, which differ by country and change often; check the current rules for the countries you sell in. The commission each store takes is covered in our guide to what it costs to build an app.
Types of in-app products
Apple's In-App Purchase page lists four types: "consumable, non-consumable, auto-renewable subscription, and non-renewing subscription". In practice:
- Consumable: used up and bought again, such as credits or in-game currency.
- Non-consumable: bought once and kept, such as removing ads or unlocking a full version.
- Auto-renewable subscription: renews each period until the user cancels.
- Non-renewing subscription: access for a fixed time that does not renew by itself.
Google Play has one-time products and subscriptions. Its subscriptions documentation explains that each subscription can have several base plans and offers, "for example, you can create an introductory offer for users who have never subscribed". Apple's guideline 3.1.1 adds two rules worth planning for: credits bought through in-app purchase "may not expire", and you should provide "a restore mechanism for any restorable in-app purchases", so people get their purchases back on a new phone.
What a subscription must offer
Both stores expect a subscription to keep giving something. Apple's guideline 3.1.2(a) says you "must provide ongoing value to the customer", the period "must last at least seven days", and the subscription must be "available across all of the user's devices".
Google Play's Subscriptions policy says subscriptions "must provide sustained or recurring value to users throughout the life of the subscription". Something that is really a one-time benefit, such as a lump of credits, must be "an in-app product instead of a subscription product".
What to show before someone pays
The screen that offers a subscription is often called a paywall. Apple's guideline 3.1.2(c) says that before asking someone to subscribe, "you should clearly describe what the user will get for the price".
Google's Subscriptions policy is more detailed. You must disclose "your offer terms, the cost of your subscription, the frequency of your billing cycle, the automatic renewal terms, whether a subscription is required to use the app", and users "should not have to perform any additional action to review the information". Its examples of violations include:
- annual subscriptions that show the price most prominently as a monthly cost;
- a missing or hard-to-see dismiss button, so people think they cannot use the app without subscribing;
- an offer that shows only the introductory price, not what will be charged afterwards.
For free trials, Google says you must explain "how and when a free trial will convert to a paid subscription, how much the paid subscription will cost, and how a user can cancel". Both stores prohibit tricking people into subscribing. Our guide to publishing to the App Store and Google Play covers the review itself.
Managing and cancelling subscriptions
Google's Subscriptions policy says your app must "clearly disclose how a user can manage or cancel their subscription" and include "an easy-to-use, online method to cancel". In the account settings, a link to Google Play's Subscription Center or direct access to your own cancellation process meets this. Google's general policy is that a cancelled subscription is not refunded for the current period, but access continues until it ends. Our guide to avoiding dark patterns covers cancellation roadblocks and other tricks regulators look for.
Apple's auto-renewable subscriptions page describes a showManageSubscriptions method that opens Apple's subscription management inside your app, so people can manage their subscription without leaving it.
Failed payments, grace periods and account hold
When a renewal fails, both stores try to recover the payment, and your app must handle the states in between.
- Apple: "When a subscription renewal fails, Apple attempts to recover it for 60 days." You can switch on Billing Grace Period in App Store Connect, with "a duration of 3, 16, or 28 days", during which the subscriber keeps access while Apple retries.
- Google Play: its subscription lifecycle documentation explains that recovery "can consist of a grace period followed by an account hold period". Both are on by default. During the grace period "the user should still have access"; when account hold begins, "you should block access", while still handling restorations if the user fixes the payment.
Show a clear message in the app when a payment has failed, with a way to update the payment method, rather than simply locking people out. Test these states before release with the stores' test tools; our guide to testing a mobile app explains how.
Check every purchase on your server
An app on someone's phone can be tampered with, so the decision to unlock a purchase belongs on your server. Google's guide to fighting fraud and abuse says to send each purchase token to your backend, keep a record of every token, check the token has not been used before, and call the Google Play Developer API "to verify with Google that the purchase is legitimate" before granting access.
Google's billing integration guide adds a deadline: after granting the purchase, your app must acknowledge it "within three days so that the purchase isn't automatically refunded and entitlement revoked". Google Play also sends real-time developer notifications when a subscription renews, is cancelled or goes on hold.
Apple offers the equivalent: App Store Server Notifications send "near-real time status updates for refunds, subscription state, Family Sharing access, and more" to a server address you set in App Store Connect, and the App Store Server API returns the latest status and history of each transaction. Your server then knows who is entitled to what, even after a refund made outside the app. Our mobile app security guide covers the wider backend.
Users who also pay on your website
Many services sell the same subscription on the web and in the app. Apple's guideline 3.1.3(b), "Multiplatform Services", allows users to access content or subscriptions "they have acquired in your app on other platforms or your web site", provided "those items are also available as in-app purchases within the app". So your account system needs one record of each customer's access, whichever store or website they paid through.
A checklist
- Each thing you sell is classed as digital (store billing) or physical (your own payment provider).
- Product types are chosen, with restore purchases for anything kept.
- Subscriptions give ongoing value, and existing users keep what they paid for.
- The paywall shows the full price, billing period, renewal, trial terms and a clear dismiss button.
- A "Manage subscription" item in the app lets people change or cancel.
- Grace periods and account hold are handled with a clear message.
- Purchases are verified and acknowledged on your server, which receives both stores' notifications.
Frequently asked questions
Do I have to use Apple's and Google's in-app purchase?
For digital goods and features used in the app, such as subscriptions, premium content or unlocking features, generally yes, with some regional exceptions. For physical goods and services, such as deliveries, rides or cleaning, Google says its billing must not be used and Apple says to use other purchase methods.
Can I charge for a subscription that gives a one-time benefit?
No. Apple requires ongoing value and a period of at least seven days. Google requires sustained or recurring value, and says one-time benefits such as a lump of credits must be sold as an in-app product, not a subscription.
What must a subscription screen show?
What the user gets, the price actually charged, how often they are billed, that it renews automatically, any trial terms and when it converts to paid, and a clear way to dismiss the offer.
How do users cancel an in-app subscription?
Through the store: Apple's subscription management, which your app can open directly, or Google Play's Subscription Center. Google requires apps to explain how to cancel and to include an easy online way to do it, such as a link in account settings.
Why check purchases on a server?
The app on a phone can be tampered with. Google recommends verifying each purchase token with the Google Play Developer API on your backend before granting access, and purchases must be acknowledged within three days or they are refunded.
Planning an app with subscriptions or paid features? We build iPhone and Android apps together with the backend, API and admin dashboard behind them, and decide early which payments must go through the stores' in-app purchase systems and which can use a regular payment provider. See our mobile app development service and all our services, or email [email protected].