In-App Purchases and Subscriptions Explained: How Mobile Apps Take Payment

Taking payment inside a mobile app is not the same as adding a checkout to a website. Apple and Google each set rules about which payment method an app must use, and those rules depend on what you are selling. Get it wrong and the app can be rejected at review, or customers end up paying for something the app never unlocks.

This guide explains how in-app purchases and subscriptions work for business owners and product managers planning iPhone app development or an Android release. It covers what the stores require today, the product types available, how a subscription behaves over time, and what your development team has to build behind the scenes.

Store rules differ by country and change often, so treat this as orientation rather than legal advice, and read the current policy pages before you commit to a model.

Digital or physical: the question that decides your payment method

The first thing to establish is whether the customer is buying something used inside the app or something delivered in the real world. Apple's App Review Guidelines (section 3.1.1) say that if you want to unlock features or functionality within your app, such as subscriptions, in-game currencies, premium content or a full version, you must use in-app purchase. Section 3.1.3(e) says the opposite for the real world: if the app lets people buy physical goods or services consumed outside the app, you must use other methods, such as Apple Pay or card entry.

Google draws a similar line. Its Payments policy requires Google Play's billing system for access to in-app features, digital content or goods, and says that system must not be used where payment is primarily for physical goods such as groceries or clothing, or physical services such as transportation, cleaning, gym memberships or food delivery.

So a store selling shoes, a taxi app and a salon booking app use an ordinary payment gateway. A meditation app selling premium sessions, a game selling coins or a news app selling a monthly plan use the store's own billing. Both policies list further special cases, so read the section that matches your product.

The kinds of in-app products

Apple's In-App Purchase overview lists four types: consumable, non-consumable, auto-renewable subscription and non-renewing subscription. Google Play groups its catalog into one-time products and subscriptions. In practice, you are choosing between three ideas:

• Consumable: something that is used up and can be bought again, such as credits, coins or a single report.
• Non-consumable: a one-time unlock the customer keeps, such as removing ads or opening a premium feature set.
• Subscription: ongoing access that renews on a schedule until the customer cancels.

The type affects more than pricing. Apple's guidelines say credits bought through in-app purchase may not expire, that restorable purchases need a restore mechanism, and that an auto-renewable subscription must provide ongoing value and work on all of the user's devices where the app is available.

How a subscription lifecycle works

A subscription is not a single sale. It is a relationship that moves through states, and your app has to respond correctly to each one.

Trial and renewal

Both stores support free trials and introductory pricing. Apple's subscriptions guidance asks that the purchase flow clearly state how long a free trial lasts and the price billed afterward. After the trial, the store charges the customer at each renewal without the app being open, which is why your server needs to hear about renewals directly.

Failed payments and grace periods

Cards expire and payments fail. Apple lets developers enable a Billing Grace Period of 3, 16 or 28 days, during which the subscriber keeps access while Apple tries to recover the payment. Google's subscription lifecycle documentation describes a grace period in which the user should still have access, followed by an account hold during which you should block access until the payment method is fixed.

Cancellation and refunds

Cancelling stops the next renewal, not the current period. Google's documentation states that a canceled subscriber retains access until the end of the current billing cycle. Refunds are different: when a purchase is revoked or charged back, Google says to revoke the entitlement immediately. Customers cancel through their store account, and Apple asks developers to make that screen easy to reach.

Why the backend must verify purchases

An app running on a customer's phone can be tampered with, so it should not be the only thing deciding whether someone has paid. Google's billing security guidance tells developers to send each purchase token to their backend, check that it has not been used before, and confirm the purchase with Google's server API before granting access. Apple offers the App Store Server API and App Store Server Notifications for the same purpose.

Renewals, failed payments, cancellations and refunds also occur while the app is closed, and both stores send server-to-server notifications about them. There is a practical penalty for skipping this work on Android: Google states that a new subscription purchase that is not acknowledged within three days is automatically refunded and revoked.

Customers who pay on the web or on another device

Many products are sold in more than one place: an iPhone app, an Android app and a website. Customers expect to pay once and sign in anywhere. That requires an entitlement record on your own server, tied to the customer's account, that says what they may access and until when, regardless of where the payment came from.

Apple's guidelines (section 3.1.3(b)) allow apps that operate across multiple platforms to let users access content, subscriptions or features acquired on other platforms or on your website, provided those items are also available as in-app purchases within the app. Whether the app may link to or mention a web checkout is a separate question and depends on the storefront. Apple's guidelines currently treat the United States storefront differently from most others, and Google's policy refers to alternative billing programs for eligible countries and regions. Check the position for each country you sell in, including the UK, before designing a web purchase flow.

The framework you choose affects how much of this is shared between platforms; our comparison of native, Flutter and React Native covers that trade-off.

What developers must build and test

The purchase screen is the visible part. The larger share of the work sits behind it:

• Product setup in App Store Connect and Google Play Console, with prices and trial terms for each country.
• A paywall that states price, period and trial terms clearly, plus restore and manage-subscription options.
• Server-side verification, an entitlement store, and handlers for store notifications.
• Handling for edge cases: interrupted purchases, upgrades and downgrades, grace periods, refunds and account changes.

Testing takes real time because the states are hard to reproduce. Apple provides a sandbox environment and StoreKit Testing in Xcode, and notes that purchases in TestFlight use the sandbox, so testers are not charged. Google Play provides its own test tooling. Ask your team to show each lifecycle state working, not just a successful first purchase.

Common mistakes

The most frequent problem is picking the wrong payment method for the product, for example a card form for a digital feature, or store billing for a physical service. Both lead to review problems and rework.

The second is trusting the app alone, so access is kept after a refund. The third is treating iOS and Android as separate customer lists, so a subscriber on one platform is asked to pay again on the other. The fourth is an unclear paywall: Apple's guidelines state that apps that try to trick users into purchasing a subscription will be removed from the App Store.

Questions to ask before choosing a model

Before any design work, write down the answers to a few questions. Is what you sell consumed inside the app or outside it? Does the value continue every month, or is it a one-time unlock? Will customers also buy on the web, and in which countries? What should happen to access when a payment fails, and after a refund? Who will handle billing support questions when the store, not you, processes the charge?

Then check the fees. Both stores keep a share of in-app purchase revenue, and the terms vary and change, so read the current figures on the Apple and Google developer sites and build them into your pricing.

Conclusion

In-app purchases and subscriptions come down to three decisions: whether your product is digital or physical, which product type fits it, and how your own server will track who is entitled to what. The stores handle the charge, but verification, entitlements across devices and the full subscription lifecycle are yours to build and test.

If you are planning an app that takes payment and want a second opinion on the model or the build effort, you can request a quote and describe what you intend to sell and where.