In-App Purchase Implementation:The 2026 Guide to StoreKit 2, Play Billing, and the Commission Rules Two Courts Rewrote

In-app purchase implementation is the system that lets a user pay for something inside your app and reliably receive what they paid for — not the single SDK call most teams picture when they say "we added in-app purchases."

Both Apple and Google recognize three purchase shapes, and getting the shape right at the product-catalog level matters more than most teams expect, because reclassifying a shipped product later is disruptive to customers who already own it. A consumable can be purchased repeatedly and is used up (in-game currency, extra credits). A non-consumable is purchased once and unlocks something permanently (a pro-tier feature, an ad-removal toggle). An auto-renewable subscription recurs on a billing cycle until canceled, and carries the most lifecycle complexity of the three — renewals, grace periods, billing retries, price-increase consent, cross-device restoration.

Apple's current guideline text is direct about what does not count as a legitimate workaround:

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. Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets, etc.

— Apple App Store Review Guidelines, §3.1.1

The same section requires that any restorable purchase have a working restore mechanism, that purchased credits or in-game currency never expire, and — for apps offering randomized virtual items ("loot boxes") — that the odds of each outcome be disclosed to the customer before purchase. These are not stylistic preferences; each has been an actual App Store rejection reason, and each is checkable in your own product against the exact wording above rather than a paraphrase of it.

The exceptions matter as much as the rule. Physical goods and services consumed outside the app — a rideshare, a hotel booking, a physical product shipped to the customer — have always been allowed to use other payment processors on both platforms; this guide is about digital content and in-app functionality, which is the category that is actually restricted, and where that restriction sits has changed meaningfully in 2026, as the commission section below covers in detail.

StoreKit 2, introduced at WWDC 2021, replaced a genuinely painful integration pattern. The original StoreKit required fetching an opaque, encrypted receipt blob from the device and either sending it to Apple's verifyReceipt endpoint or decoding it locally with OpenSSL — slow, hard to test, and a recurring source of production bugs around receipt refresh timing and sandbox-versus-production endpoint confusion.

StoreKit 2 replaces the opaque receipt with typed Swift objects — Product for what's purchasable, Transaction for what was actually bought — and signs every transaction as a JSON Web Signature (JWS) you can verify cryptographically against Apple's published keys, without a network round trip for every check. Transaction.currentEntitlementshands you the customer's current, already-verified purchase state directly as an async sequence, which is a materially different developer experience from manually reconstructing entitlement state from a decoded receipt array.

The old verifyReceiptendpoint still functions today, and Apple has not announced a shutdown date for it the way Google shut down FCM's legacy send APIs. But every piece of Apple's current documentation treats it as the legacy path, not the way to build new integrations — if you're standing up a new purchase flow in 2026, there is no reason to build against receipts instead of StoreKit 2's transaction model.

One detail that trips up teams migrating from StoreKit 1: a transaction is not finished automatically. Your app must call transaction.finish() after it has verified the purchase and durably granted the entitlement — a transaction that is never finished reappears in Transaction.updates on every future app launch, which is either a minor annoyance (a duplicate local notification) or a real bug (double-granting a consumable) depending on how your grant logic is written.

If you're deciding on a cross-platform framework before this level of detail even becomes relevant, our iOS app development guide and Android app development guide cover the platform-native versus cross-platform tradeoff more broadly; StoreKit 2 and Play Billing both have solid wrappers in React Native and Flutter, but you will still end up reading each platform's own documentation for anything beyond the basic purchase flow.

A client-side purchase confirmation tells your app's UI to update immediately — it should never be the thing that actually grants an entitlement your business depends on. That is what the App Store Server API and App Store Server Notifications V2 are for: an independent, server-to-server source of truth your backend controls.

The App Store Server API is a pull model: your server authenticates with a signed JWT and can query a customer's live subscription status or full purchase history directly from Apple, using only a transaction identifier — not the entire receipt blob StoreKit 1 required. This is the correct place to check entitlement state when a request comes in from a surface StoreKit itself doesn't touch — a companion web app, an internal support tool, an API key gate.

App Store Server Notifications V2 is the push counterpart: Apple posts a signed JWS payload to a webhook endpoint you register whenever a subscription-relevant event happens — a renewal, an expiration, a refund, entry into a billing grace period, a price-increase consent, and more. Apple's documented retry behavior sends up to five attempts, roughly at 1, 12, 24, 48 and 72 hours after the previous attempt, if your endpoint doesn't return a success response — an endpoint down for a few hours will still receive the notification eventually, but one down for more than three days will not. V1 notifications are deprecated in Apple's current documentation; build against V2 only.

Webhook handling for both platforms needs to be idempotent by design: Apple and Google can both redeliver a notification you've already processed (a retry after a slow-but-eventually-successful response, for instance), and a handler that isn't safe to run twice on the same event will eventually double-grant something or send a duplicate downstream side effect.

Play Billing Library is Google's equivalent client-side framework — BillingClient, launchBillingFlow — and it carries a requirement that catches more integrations than any single StoreKit 2 detail: every purchase must be explicitly acknowledged within three days of completing, or Google automatically refunds it and reverses the purchase.

Acknowledgment is a distinct API call from whatever your app logic does to unlock content locally, which is exactly why it's easy to ship a flow that looks correct in testing — the user pays, the UI unlocks — but never actually calls the acknowledgment endpoint. Three days later, Google auto-refunds the purchase, and unless your app is separately watching for that reversal, it keeps showing the content as unlocked with no unlock event to explain why the user is no longer entitled. Consumable products have a second, related requirement: they must be consumed via consumeAsync (which also acknowledges) before the same item can be purchased again — a non-consumable or subscription is acknowledged but never consumed.

Google runs Billing Library itself on a two-year deprecation cycle, announced at Google I/O 2019: each major version stops being accepted for new app submissions and app updates two years after release, with an extension window available on request through the Play Console.

Google's own guidance for teams upgrading right now is to go straight to Billing Library 9 rather than stop at the version-8 floor, since 8 faces the identical August 31, 2027 cutoff and 9 shipped with additional in-app messaging and price-increase opt-in features that most teams will want regardless.

Laid next to each other, the two platforms solve the same problem with genuinely different mechanics — and the differences are exactly the details that get missed when a team builds one platform first and assumes the other works the same way.

Through 2023, "Apple takes 30%" and "Google takes 30%" were close enough to true everywhere that a single number could scope a business model. That stopped being true in 2026. The commission owed on functionally the same transaction now depends on the storefront region, the payment path the customer used, and — for Apple in the US specifically — a rate that is still being litigated.

Two rows deserve a closer read before you build a pricing model around them, because both are mid-litigation rather than settled: Apple's $0 US external-link commission, and Google's US alternative-billing rate. The next two sections cover each in the detail an actual pricing decision requires.

Understanding what Apple can currently charge on US external-link purchases requires the actual sequence — reporting on this case has repeatedly conflated "the injunction exists" with "the commission is zero forever," and the two are not the same claim.

1. 1.2021: The district court (Judge Yvonne Gonzalez Rogers) rules mostly for Apple on antitrust monopoly claims, but issues a permanent injunction on a California Unfair Competition Law anti-steering claim: Apple must let developers include external links and other calls to action directing customers to purchasing mechanisms outside Apple's in-app purchase system.
2. 2.April 30, 2025: Judge Gonzalez Rogers holds Apple in civil contempt, finding Apple violated the 2021 injunction through 'scare screens' discouraging external-link use and by continuing to charge a commission on external-link sales. The court orders Apple to stop charging any commission on external-link purchases and to remove the scare screens immediately.
3. 3.Since April 2025: Apple has charged $0 commission on purchases completed through external links from US-storefront apps.
4. 4.December 11, 2025: The Ninth Circuit affirms the contempt finding and the scare-screen and dynamic-link holdings, but rules the district court's total ban on any commission is itself overbroad — the panel holds Apple may charge some commission tied to costs that are genuinely and reasonably necessary to facilitate external-link purchases, and remands for the district court to set that rate. The panel also denies Apple's request to vacate the injunction and denies its request to reassign the case to a different judge.
5. 5.Early-to-mid 2026: Apple obtains a stay preserving the $0-commission status quo while it seeks Supreme Court review.
6. 6.April 28–29, 2026: The Ninth Circuit grants Epic's motion for reconsideration and reverses the stay, finding Apple had not shown good cause to keep it in place — the case returns to the district court to set the actual commission rate even as Apple's Supreme Court petition remains pending.
7. 7.May 21, 2026: Apple petitions the U.S. Supreme Court for review of the Ninth Circuit's opinion.
8. 8.June 30, 2026: The Supreme Court grants certiorari — specifically to review the legal standard applied for civil contempt, not a direct review of the commission-rate question itself — with arguments expected in the Court's October 2026 term.

Practically, what this means for external-link purchase flows in a US-storefront app: Apple's Guideline 3.1.3 now states that apps "cannot, within the app, encourage users to use a purchasing method other than in-app purchase, except for apps on the United States storefront and as set forth in 3.1.1(a) and 3.1.3(a)" — the direct textual result of this litigation. A US app can include buttons and external links today without the reader-app restrictions that still apply elsewhere; whether that specific carve-out or the $0 commission survives the pending Supreme Court and district-court proceedings unchanged is genuinely not yet known.

Epic's case against Google ran on a different track and reached a jury verdict rather than a bench ruling: in December 2023, a jury found Google's Play Store conduct constituted an illegal monopoly. In October 2024, Judge James Donato issued a permanent, worldwide injunction requiring Google to allow third-party app stores to operate within Google Play, to stop forcing developers to use Google Play's own billing system exclusively, and to stop restricting developers from telling users about — or linking to — alternative payment methods. The Ninth Circuit substantially upheld the jury verdict and the injunction's remedies on appeal in 2025.

In November 2025, Epic and Google filed a proposed settlement intended to resolve the case on negotiated terms rather than continue litigating the injunction's exact scope. As of when we checked, Judge Donato has not approved that settlement — he scheduled a summer-2026 evidentiary hearing he reportedly called the case's "final act," and the original October 2024 injunction remains in force in the meantime.

What's actually live for a developer building today: Google's Play Console policies for US developers already permit offering alternative billing and linking to external payment options, consistent with the standing 2024 injunction. The specific fee Google charges on alternative-billing transactions is negotiated per the injunction's terms rather than a single flat published percentage the way the EU numbers are — if alternative billing materially changes your unit economics, get the current terms directly from Google Play Console rather than from a number in this or any other article, since this is exactly the kind of detail a pending settlement could still revise.

Two platform-contract obligations sit underneath every subscription flow, independent of whatever federal rulemaking is doing at a given moment: Apple's Guideline 3.1.1 requires a working restore mechanism for any restorable purchase, and both Apple and Google require you to expose subscription management and cancellation through the platform's own settings surface — not buried inside your own app's account menu as the only path.

Federal rulemaking on cancellation ease has itself been unsettled in exactly the way the commission litigation above is. The FTC's Negative Option Rule — widely called the "click-to-cancel" rule — was vacated by the Eighth Circuit on July 8, 2025, on procedural grounds: the court found the FTC had skipped a preliminary regulatory analysis required because the rule's projected economic impact exceeded the statutory threshold for a "major rule." That is a process failure, not a ruling that the underlying policy goal was wrong. The FTC opened a new Advance Notice of Proposed Rulemaking on March 11, 2026 seeking public comment on how to proceed; as of when we checked, that comment period has closed and no replacement rule is yet in force.

On restore specifically: the most common production gap is treating restore as an edge case tested once before launch rather than a flow real users hit constantly — every reinstall, every new device, every user who signed up on one platform and expects entitlement to follow them. Transaction.currentEntitlements on iOS and a re-query against the signed-in Google account on Android both handle the mechanics; the gap is almost always in how that reconciles against your own entitlement store, not in the platform API itself.

If your product spans a mobile app and a companion web experience, the same accounts-and-entitlements question shows up there too — our mobile app RFP template guide covers how to specify cross-platform entitlement and restore requirements precisely enough that competing proposals are actually comparable, rather than each vendor claiming "subscriptions supported" at very different levels of rigor.

The order matters because each step either depends on the one before it or fails invisibly without it — the same pattern that governs push notification infrastructure applies here, with the platform-specific failure modes swapped in.

A note on ownership: webhook handling, entitlement reconciliation, and platform SDK version currency (the Billing Library deprecation cadence from earlier) all need a named owner and a recurring cadence, not a one-time build task closed at launch. A purchase flow that worked correctly at launch degrades quietly as platform requirements shift underneath it — an unnoticed Billing Library deadline, a webhook endpoint that silently stopped responding — and by the time a support queue notices "customers who paid aren't getting access," the underlying cause has often been accumulating for weeks.

This is not a ranked top list, for the same reason the push-infrastructure landscape isn't one: StoreKit 2 and Play Billing are mandatory platform layers every vendor sits on top of, so the useful question is what a given vendor actually replaces, not which one scores highest on a benchmark nobody can verify.

Building this yourself is defensible when you have one platform, a simple product catalog, and an engineer who will actually own the ongoing maintenance — server-side verification against the App Store Server API or the Play Developer API is genuinely tractable now in a way StoreKit 1's receipt validation wasn't. A vendor earns its subscription fee once you need entitlement state synchronized across iOS, Android and web from one source of truth, or paywall experimentation without shipping a new app-store build for every test, or you'd rather not build and maintain webhook normalization across both platforms' very different notification formats yourself.

On the refused figures specifically: searching on September 3, 2026, we found multiple vendors' "State of Subscription Apps"-style reports quoting trial-to-paid conversion rates and month-one churn percentages drawn entirely from each vendor's own SDK-integrated customer base, with no disclosed sampling method and no stated confidence interval. A sample restricted to apps that already adopted a specific vendor's subscription tooling is not a random or representative sample of the app market, and treating it as "the industry average" overstates what the underlying data actually supports. We name the pattern and decline to print a specific number as fact.

The following is an illustrative worked scenario, not a real client engagement or a reported outcome — the arithmetic uses the verified commission rates from this guide, applied honestly to round numbers, to make the fee fragmentation above concrete.

Consider a habit-tracking app with a $9.99/month subscription and 10,000 active paying subscribers split evenly across three paths: Apple in-app purchase (US storefront), Apple in-app purchase (EU storefront), and an external-link purchase from a US-storefront app. That's roughly 3,333 subscribers per path, or about $33,297 in monthly subscription revenue per path before any commission.

The honest reading of that table is not "route everyone to external links" — it's that the third row is the least stable number in the entire model. The Ninth Circuit has already ruled the $0 rate is not the final word, and a rate the district court eventually sets could land anywhere the "genuinely and reasonably necessary costs" standard supports. A business model that only works at $0 external-link commission is a business model built on pending litigation, not a durable unit economics assumption — the discipline this scenario is meant to illustrate is running your own numbers at $0, at a plausible modest commission, and at the standard 15-30% rate, and checking the model survives all three, not just the most favorable one.

One scoping note specific to this domain: the discovery phase for in-app purchase work should always include a platform-currency check on two fronts — the Billing Library version your Android app currently ships (anything on 7 or earlier needs to move before your next release) and whether your iOS integration still depends on legacy receipt validation instead of StoreKit 2's transaction model. Both are quick to check and expensive to discover mid-release instead.

None of this is a substitute for your own counsel reviewing your specific product, region mix and purchase paths — commission and compliance obligations here are genuinely in motion across three separate active proceedings (Epic v. Apple, Epic v. Google, and the FTC's negative-option rulemaking), and a guide like this one can only be accurate as of the date it was checked, not as a permanent reference.