In-app purchase (IAP) / store billing

An in-app purchase is a sale that runs through the platform's own checkout: StoreKit on iOS, Google Play Billing on Android. The user taps 'Buy', the OS shows a sheet you do not control, the store charges the card on file, and your app gets told to unlock something. In exchange the store keeps a commission. The two rates you will hear quoted are 30% and 15%, but there is no single schedule: which one you pay depends on the platform, the product type, your revenue tier, which small-business or media program you enrolled in, the storefront the buyer is in, and whether you use an alternative billing option. Look up your own case in each console rather than budgeting off a number you read in a blog post.

Under the default store rules you are generally required to use it for digital goods consumed in the app: coins, pro features, subscriptions, extra credits. External payment and alternative billing paths do exist, but they are regional and program-specific, they come with their own disclosure rules, and they rarely make the commission disappear. You are not allowed to use it for physical goods or real-world services, which go through Stripe or similar and pay no store cut. Products come in flavors: consumable (buy again and again), non-consumable (buy once forever), auto-renewable subscription, and non-renewing. Most teams put a server behind it (RevenueCat, or their own receipt validation) so entitlements live in an account rather than on one phone.

The gotcha that bites everyone: purchases are asynchronous and you must acknowledge or finish every transaction. Google Play auto-refunds a purchase you never acknowledge within three days, and Apple keeps replaying an unfinished transaction on every launch. Also, a purchase can arrive when your app was killed mid-flow, so grant entitlements from a transaction listener at startup, never only from the button handler.