How to Add In-App Purchases to Your Mobile App

Last updated: August 2026.

Adding in-app purchases in 2026 is less about writing billing code and more about a handful of business decisions, then letting a tool like RevenueCat handle the platform-specific plumbing. The part that still trips people up isn't the code, it's the setup order and the fee structure, both of which have real gotchas that aren't obvious until you hit them.

The three purchase types

Consumable: used once and can be bought again, extra credits, in-game currency, a one-time boost.

Non-consumable: bought once and stays unlocked forever, removing ads, unlocking a pro feature permanently.

Subscription: recurring, auto-renewing access, the standard model for ongoing app value.

Picking the wrong type for a given product is a common early mistake, marking a subscription as non-consumable, for instance, breaks renewal handling entirely.

What you need before you touch any billing code

Both platforms gate you behind setup steps that have to happen in a specific order. On Google Play: your Console account and its one-time fee, the Developer Distribution Agreement and Paid Applications Agreement both signed, a merchant account linked to your Console (without it, the "create product" buttons stay greyed out), and at least one signed app bundle uploaded to a test track, Google won't let you create a product until it's seen your package name in a real upload. Apple has its own equivalent: an active Paid Applications agreement in App Store Connect and tax and banking information on file before purchases go live, even in sandbox testing.

The easier path: RevenueCat instead of raw StoreKit and Play Billing

Most apps built in 2026, no-code or hand-coded, use RevenueCat rather than writing directly against Apple's StoreKit or Google's Play Billing Library. It wraps both platforms behind one API, so a purchase, a renewal, or a cancellation looks the same in your code regardless of which store it came from, handles server-side receipt validation so you're not trusting the client alone, and gives you a dashboard for products, entitlements, and revenue instead of digging through App Store Connect and Play Console separately. If you're building through a tool like Huxly, this is usually a one-click backend connection rather than an SDK you wire up by hand.

What Apple and Google take

Apple's standard commission is 30%, dropping to 15% for developers earning under $1 million a year or on subscriptions after the first year. Google runs a similar tiered structure, 15% on the first $1 million a year, 30% above it, with subscriptions dropping to 15% from year two onward. Neither of these numbers changes based on which no-code or AI tool you built the app with, they're set by the platforms.

The alternative billing options that opened up in 2026

This is new territory as of this year. Google's global "Own Billing" program, announced in March 2026, lets any developer use their own billing system in-app or link out to a web purchase page, at a 20% service fee on new installs and a notably lower 10% on recurring subscriptions, often cheaper than standard Play Billing once you're past the first year. The EU's Digital Markets Act goes further for EEA developers, allowing third-party app stores, sideloading, and alternative billing with reduced or zero Google fees. On Apple's side, the Epic v. Apple ruling made external payment links meaningfully easier to use in the US, and Brazil has its own dedicated program (StoreKit External Purchases) with commissions between 10% and 21% depending on the path. None of this is mandatory, standard IAP still works fine for most apps, but it's worth knowing these options exist before assuming Apple and Google's cut is fixed.

One technical deadline worth knowing if you're building an Android app now: Google requires Play Billing Library 8 or later for any new app or update by August 31, 2026, with a short extension available on request until November 1.

Common mistakes that trip up a first launch

Trying to create a product before uploading a build. Both stores need to see your app's package or bundle identifier in a real upload first, this is the single most common source of "why won't this button work" confusion.

Skipping sandbox testing. Both platforms provide test purchase flows that don't charge real money, use them before your first real transaction, not after.

Mismatched product types between the store and your entitlement logic. A subscription configured as consumable on one side and non-consumable on the other will produce broken renewal or access behavior that's hard to debug after the fact.

For the fuller picture on backend choices generally, see our breakdown of what it costs to build a mobile app in 2026.

FAQ