Who sells what, and what triggers in-app purchase
In-app purchase is the payment collection mechanism run by the app store itself, which the store requires for only part of what an app sells. The dividing line depends on what the customer receives and where they consume it. It does not depend on the amount, the country, or the business model. Digital content delivered in the app falls under in-app purchase. A physical good, or a service performed outside the app, falls under ordinary payment methods, and in that case both stores prohibit the use of their own system. The rule therefore cuts both ways. It mandates the store’s payment collection on one side of the line and bars it on the other.
Apple sets out this split in guidelines 3.1.1 and 3.1.3(e) of its App Store Review Guidelines. They reserve in-app purchase for digital goods and services, and they require another payment method whenever the good or service is consumed outside the app. Google Play states the same rule in its Payments policy: Google Play Billing is mandatory for purchases of digital content and features, and it is excluded for physical goods. Both documents are public, versioned, and amended several times a year. A reading from 2022 no longer matches the text in force. Check the version published at the time you settle your payment collection architecture.
| What the customer buys | Required payment method | Deciding factor |
|---|---|---|
| Subscription to a service consumed in the app | In-app purchase required | The app itself delivers the service |
| In-game currency, lives, levels, virtual items | In-app purchase required | Digital good consumed in the app |
| Unlocking a software feature | In-app purchase required | The unlock applies to the binary distributed by the store |
| Meal delivery, ride-hailing trip, hotel night | Merchant’s own payment processing; in-app purchase prohibited | The service is performed in the physical world |
| Event ticketing, show tickets | Merchant’s own payment processing | Service consumed outside the app |
| Live one-on-one consultation, private lesson, telehealth visit | Merchant’s own payment processing, allowed by Apple | Guideline 3.1.3(d) covers one-on-one experiences; a class streamed to several people falls back under in-app purchase |
| Access to content already bought elsewhere (news, music, video, books) | No payment collected in the app | Reader apps rules, guideline 3.1.3(a) |
| Enterprise subscription bought outside the app by a procurement team | No payment collected in the app | Enterprise services, guideline 3.1.3(c) |
| Donation to a recognized nonprofit | Outside in-app purchase on both stores | Specific rules for charitable donations |
| Ad space bought by a business advertiser | Merchant’s own payment processing | Ad management tool, not consumed by the end user |
Three intermediate regimes shift this line without erasing it. Reader apps under guideline 3.1.3(a) cover news, books, audio, music, and video; they can give access to content bought elsewhere but never sell it in the app. Multiplatform services under guideline 3.1.3(b) let users consume on iOS content acquired on another device. Free stand-alone apps under guideline 3.1.3(f) are free companions to a paid web tool subscribed to elsewhere, provided the app contains no purchase and no call to action to buy. None of these three regimes allows selling to the user in the app. Each allows in-app use of what was paid for elsewhere, and developers regularly misread that tolerance as permission to sell there.
The reader apps rule came from a commitment made to a national competition authority, not from a business decision by Apple. The Japan Fair Trade Commission closed an investigation into the App Store in September 2021. Apple had committed to let these apps include a link to an external website for account creation and management. Apple applied the commitment worldwide starting in 2022, as the External Link Account Entitlement. A rule negotiated with the Japanese regulator therefore applies to developers in every country.
The commission and its tiers
The store commission is the share of the sale price that the store keeps on each in-app purchase. The standard rate is 30% at both Apple and Google, and almost no developer pays the full rate all the way through. Four mechanisms bring it down to 15%, sometimes lower, depending on the developer’s size, the subscriber’s tenure, the industry, and the distribution territory. These mechanisms do not stack freely, and each has its own entry and exit conditions. A revenue model that assumes a single rate will be off by several percentage points from the rate actually applied.
| Case | Apple App Store | Google Play |
|---|---|---|
| One-time purchase, developer above the threshold | 30 % | 30 % |
| One-time purchase, developer below the threshold | 15% below $1 million in net proceeds the previous calendar year, upon enrollment | 15% on the first $1 million of revenue each year, applied per account |
| Subscription, first year | 30 % | 15 % |
| Subscription, second year onward | 15% once the subscriber has accumulated one year of paid service | 15%, no tenure tier |
| Industry programs | Video Partner Program and News Partner Program at 15% | Play Media Experience Program, reduced rates for some media services |
| Alternative billing offered alongside the store’s | Terms specific to each territory where it is available | User choice billing, 4 percentage points off the applicable rate |
The most consequential gap concerns the first year of a subscription. Google has charged 15% from the first billing since January 1, 2022, while Apple keeps 30% for 12 months of paid service before dropping to 15%. Many monthly subscriptions end before reaching 12 months. On those products, all iOS revenue bears the full rate, while the same product sold on Android bears the reduced rate. The same app’s P&L therefore differs by 15 percentage points between the two platforms, at the same list price.
Apple’s small business program requires the developer to enroll; it does not apply automatically to an eligible account. Eligibility is based on net proceeds for the previous calendar year, and crossing $1 million during the year moves the developer to the full rate for the rest of the year. The threshold is assessed at the developer level, across all apps, and associated accounts in the same group are aggregated. A publisher that splits its catalog across several entities to stay under the threshold risks a contractual adjustment and removal from the program.
The alternative terms Apple published for the European Union in January 2024 introduced an entirely different cost structure. They apply to apps distributed in the EU since March 6, 2024. A developer that accepts them pays a 17% commission, reduced to 10% if it qualifies for the small business program. It pays an extra 3% if it keeps using the App Store payment system, plus a core technology fee of €0.50 per first annual install above one million over 12 months. Apple added exemptions in May 2024 for small developers and nonprofits. It overhauled the structure in 2025, introducing an initial acquisition fee and tiered store services fees. It then announced that a revenue-based commission would replace the per-install fee on January 1, 2026. The schedule has changed several times since 2024. A table copied on a given date therefore goes out of date; the current values are on the page Apple publishes.
The store as merchant of record
The merchant of record is the party that legally sells to the end customer, issues the receipt, and bears the obligations attached to the sale. In an in-app purchase, the store plays that role: it buys the content from the developer and resells it to the end user in its own name. This status stems from a written tax rule whose reach goes well beyond VAT. It determines who issues the invoice, who decides on refunds, who deals with the customer, and who owns the relationship data. The developer performs none of these four functions.
The practical consequence shows up on the invoice. The customer gets a receipt issued by the store’s entity, with VAT charged at the rate of the country of consumption, and the developer’s name appears only as a description. The developer, for its part, supplies a service to that entity, which is usually based outside the developer’s own country. For EU customers, Apple contracts through Apple Distribution International Ltd, an Irish company, so a European developer’s supply falls under the business-to-business regime, with the reverse charge applied by the recipient. A French developer therefore charges no French VAT on its European App Store revenue. Yet the French consumer paid VAT on the purchase, collected and remitted by the store.
| Attribute | Direct web sale | In-app purchase |
|---|---|---|
| Seller under the contract | The merchant | The store, on its own account |
| Issuer of the customer receipt | The merchant | The store |
| VAT collection and remittance | The merchant, VAT-registered or through the One-Stop Shop | The store, per the list of territories it publishes |
| Refund decision | The merchant | The store, without the developer’s prior consent |
| Cardholder’s card dispute | Against the merchant, with representment rights | Against the store; the developer is not a party |
| Payment method shown to the customer | Chosen by the merchant | Chosen by the store, including carrier billing and gift cards |
| Customer identity | Known to the merchant | Unknown to the developer, unless a separate app account is created |
| Descriptor on the bank statement | The merchant’s | The store’s |
The store decides refunds on in-app purchases, without the developer’s prior consent. On the App Store, the customer submits the request to Apple, which reviews and decides it alone, then deducts the amount from the developer’s proceeds for the relevant month. Apple has set up an information channel around that decision. The developer receives a CONSUMPTION_REQUEST notification and has 12 hours to respond with consumption data. A REFUND or REFUND_DECLINED notification follows, depending on the outcome. This data influences the decision without determining it. If the developer does not respond in time, Apple decides based only on the information it has, which does not work in the developer’s favor.
Google Play handles the same process differently. Google reviews requests submitted within 48 hours of purchase, without the developer’s involvement; after that window, the user is referred to the publisher, which can issue a refund from the Play Console. Developers detect cancellations through the Voided Purchases API, which returns purchases that have been voided and indicates the source of the cancellation. A refund and a chargeback have the same effect on the payout balance, but they differ in commercial meaning and accounting treatment. Standard practice is therefore to separate them at data ingestion, using the cancellation source that the API returns.
The lack of customer data affects everything downstream. The developer receives no name, email address, billing address, or verified country of residence. Both stores offer a single technical hook: an opaque identifier that the developer itself passes at the time of purchase, called appAccountToken at Apple and obfuscatedExternalAccountId at Google. Populating this field on every transaction is the only way to link a purchase to an app account later. Purchases made without it can never be tied to an account afterward.
The subscription the store runs
A subscription sold through in-app purchase is a recurring contract whose billing, renewal, and termination the store handles. That takes away the levers a merchant uses to run a recurring business. The renewal date, retries after a failure, the grace period, account hold, plan changes, price increases, and cancellation are all decided by the platform. The developer learns what happened through a server notification, often after the fact. Its billing system records events decided elsewhere, whereas a direct billing system triggers them itself.
Renewals follow a cycle set by the store alone. When a charge fails, Apple retries during a window that it documents as lasting up to 60 days. The developer learns of the failure through a DID_FAIL_TO_RENEW notification, with the GRACE_PERIOD subtype where applicable, indicating that access remains open. Google Play, for its part, distinguishes a configurable grace period from an account hold, whose default length it now calculates by subtracting the grace period from a 60-day recovery window. During the hold, the subscription exists but does not give access to the service, and recovery after the payment issue is fixed triggers a SUBSCRIPTION_RECOVERED notification. The developer therefore has to replicate these states in its own system, even though it controls none of them.
| Event | Who decides | What the developer receives |
|---|---|---|
| Initial subscription | The user, in the store’s purchase sheet | SUBSCRIBED (Apple) · SUBSCRIPTION_PURCHASED (Google) |
| Successful renewal | The store, on the date it sets | DID_RENEW · SUBSCRIPTION_RENEWED |
| Failed debit | The card issuer, via the store | DID_FAIL_TO_RENEW · SUBSCRIPTION_IN_GRACE_PERIOD |
| Dunning and retries | The store alone | No visibility into the retry schedule |
| Account hold for failed payment | The store | SUBSCRIPTION_ON_HOLD (Google) |
| Voluntary pause | The user, on Google Play only | SUBSCRIPTION_PAUSED |
| Plan change | The user, in the store’s interface | DID_CHANGE_RENEWAL_PREF · SUBSCRIPTION_PURCHASED |
| Auto-renewal turned off | The user | DID_CHANGE_RENEWAL_STATUS · SUBSCRIPTION_CANCELED |
| Actual expiration | The store, at the end of the paid period | EXPIRED · SUBSCRIPTION_EXPIRED |
| Refund, revocation | The store | REFUND, REVOKE · SUBSCRIPTION_REVOKED |
Recovery techniques for a failed renewal payment disappear along with the mandate, which the developer does not hold. It cannot retry the authorization, choose when to retry, offer another payment method, or send a card update link. The whole dunning process described for a self-billed subscription runs at the store, under the store’s rules and with results the developer cannot measure. What the developer has left is in-app messaging, asking a subscriber on hold to fix their payment method in the system settings. The recovery rate is therefore driven by the store’s retries, and this messaging moves it only at the margin.
Strong customer authentication is also the store’s job. For a European payment, the cardholder’s counterparty is the store, which holds the acceptance relationship and applies the exemption for merchant-initiated transactions. The developer never sees a 3-D Secure challenge, sets no thresholds, and cannot claim a low-value exemption on a transaction that is not its own. The authorization rate becomes a platform attribute, comparable from one developer to the next because the same company produces it. This uniformity deprives the developer of an optimization lever it has when it processes payments itself.
The commercial levers that remain are limited to those the store has built. Apple and Google offer introductory offers, promo codes, win-back offers for former subscribers, and price grids by territory. These are managed in the store console, each with its own eligibility rules, allowed durations, and propagation delays. A pricing mechanism the store does not support cannot be implemented, and a price test designed for in-house billing has to be rewritten from scratch before it can run in a store.
Leaving the store’s payment system
Leaving the store’s system covers the mechanisms a developer uses to steer customers to a payment made outside the app. Two separate developments have opened gaps in the in-app purchase requirement, one regulatory and European, the other judicial and American. They differ in the rights they create, the costs they carry, and their geography. Confusing them leads to an exit flow that is legal in one market and prohibited in the other. Both attack the same rule: the one that stopped a developer from telling customers that another price exists outside the app.
Regulation (EU) 2022/1925 targets the in-app purchase requirement through three separate provisions. Article 5(4) lets business users communicate and promote their offers to users acquired through the platform service, and conclude contracts with them, free of charge and without going through the gatekeeper. Article 5(7) bars the gatekeeper from requiring the use of its payment service, including in-app payment systems. Article 6(4) requires it to allow the installation and effective use of third-party apps and app stores. All three obligations apply directly in the EU, with no need for national transposition.
The US order of April 30, 2025, went further than the DMA on one point: the price of leaving. It barred Apple from charging a commission on purchases made outside the app after a link, and from surrounding that link with deterrent screens, wording restrictions, or placement constraints. On December 11, 2025, the Ninth Circuit upheld the contempt finding but ruled the ban on any commission too broad. It sent back to the trial judge the task of setting what Apple may charge on those transactions. The US channel therefore remains fee-free until that amount is set, with no guarantee that it will stay that way. The decision’s geographic reach, however, is settled. The injunction was issued under California’s unfair competition law and applies only in the US.
Other jurisdictions are moving on different legal grounds. In September 2021, South Korea amended its Telecommunications Business Act to bar app store operators from requiring a specific payment method. In June 2024, Japan passed a law promoting competition in smartphone software. Its opening obligations have applied since December 2025, under the oversight of the Japan Fair Trade Commission. In the UK, the Competition and Markets Authority had already found an effective duopoly in its June 2022 market study. In 2025, it designated Apple and Google as having strategic market status under the 2024 digital markets law. The timetable for UK remedies follows from that designation.
The payout, and what is missing to reconcile it
The payout is the transfer through which the store pays the developer its share of a period’s sales. It covers an aggregate of transactions, never an individual sale. Each store totals the period’s sales and deducts its commission, refunds, the taxes it collected, and any withholdings. A single transfer follows, per legal entity and per currency group. No line of that transfer carries a purchase reference. The accounting trail linking a sale to a bank deposit, which is straightforward in traditional card acquiring, is therefore broken by design.
| Apple App Store | Google Play | |
|---|---|---|
| Reporting period | Apple’s fiscal month, four or five weeks long, ending on a Saturday | The calendar month |
| Payment timing | About 30 to 45 days after the fiscal month closes | Around the 15th of the following month, for orders from the previous calendar month |
| Minimum payment threshold | Published by territory in App Store Connect; below it, the balance rolls over | Published in the payments profile; below it, the balance rolls over |
| Grouping | By payment region and currency, single transfer | By payments profile, single transfer |
| Available documents | Daily sales reports, monthly financial reports by region | Monthly earnings report detailed by order, sales reports |
| Currency conversion | Done by Apple, at its own rate, with no per-transaction detail | Done by Google, at its own rate |
Country-level tax withholdings are the second source of discrepancies. The stores collect and remit VAT or sales tax in the territories where they act as the seller. They pass on to the developer the digital services taxes that several countries have introduced, either by adjusting the list price or by reducing the payout. Some territories also impose withholding tax, which the store deducts before payment; a treaty exemption or reduction requires filing a tax form in the payments account beforehand. A developer that has not provided this information discovers the withholding on its first payout and cannot recover it retroactively.
In territories where the store collects the tax itself, the tax is removed from the price paid before the commission is calculated. The commission base is therefore the pre-tax price, not the amount the customer paid. Two customers who pay the same list price generate different net revenue depending on their country of residence. The list price itself is chosen from a grid of price points per territory, which Apple expanded in 2023 to several hundred values per country. A harmonized pre-tax price across all markets is impossible in a store, whereas it is trivial on a merchant website. Revenue management therefore requires territory-by-territory modeling. An average rate applied to total revenue hides these differences.
- Ingest server notifications and financial reports separately. Notifications provide the real-time event and the transaction ID; reports provide the net amount actually paid out. Neither source replaces the other, and their totals do not match over the same calendar window.
- Book gross first, then net. The amount paid by the customer, the tax collected by the store, the commission, and refunds are four separate figures; revenue tracked only as net makes any price or refund analysis impossible.
- Reconcile refunds in the period in which the store books them. A refund granted in March on a January sale is deducted from the March payout, which makes the gap unexplainable in books kept by sale date.
- Treat notifications as unordered and replayable. Both platforms resend notifications, and non-idempotent processing leads to duplicate entitlement grants or wrongful revocations.
- Document the contracting entity for each territory. The identity of the store company that buys the content determines the VAT treatment of the developer’s supply, and it varies by region.
- Load the store’s fiscal calendar into the data warehouse. Period misalignment is the leading cause of reconciliation gaps, and the easiest to eliminate for good.
Market sizing suffers from the same opacity as reconciliation. Neither Apple nor Alphabet reports App Store or Google Play revenue separately in its financial statements. Apple includes it in services; Alphabet reports it in a line that combines subscriptions, platforms, and devices. The in-app spending figures commonly cited therefore come from estimation firms, a source that became more concentrated after Sensor Tower acquired data.ai in 2024. Apple, for its part, publishes a study it commissioned from Analysis Group. The study put developer billings and sales in the App Store ecosystem at $1.1 trillion in 2022, more than 90% of which carried no commission. The scope the study chose serves the argument of the company that paid for it. The figure is accurate under the definition used. Reading it correctly requires knowing what that scope includes.