Add in-app purchases for digital goods, and take a card for anything the customer uses outside the app.
To add in-app purchases, answer one question before you write any code. Is the thing being bought used inside the app? If it is, the store's own system is compulsory: Apple In-App Purchase on iOS, Google Play's billing system on Android. If it is a physical good or a physical service, both stores say you must not use their system, and you take a card instead. That second half is what most pages on this subject get wrong, and it is why store purchases sit apart from payments in general.
Below: the rule in each store's own terms, what each one charges, the setup that has to exist before a single test purchase can succeed, and what your code receives when someone cancels. Every figure and field name here comes from Apple's or Google's own documentation, read on 3 October 2026.
Check which system your product needsThe short version
The test is where the thing is used, not whether you think of it as digital.
Apple's guideline 3.1.1 covers unlocking features or functionality inside your app, and names subscriptions, in-game currencies, game levels, premium content and full version unlocks. Guideline 3.1.3(e) is the mirror image: physical goods or services used outside the app must be paid for some other way, such as Apple Pay or a card field. Google's Payments policy splits the same way, with its own examples on each side.
A photo file the buyer downloads in your app is store billing. A print of the same photo, posted to them, is not. The format decides nothing and delivery decides everything.
Digital goods must use the store, physical goods must not
Both directions are compulsory. Apple bans your own unlock mechanisms outright, naming license keys, augmented reality markers, QR codes and cryptocurrency wallets. Google requires Play billing for virtual currencies, extra lives, add-on items, subscription services, an ad free version of an app, features the free version lacks, and cloud software including storage and productivity tools. Google then states the reverse: its billing system must not be used where the payment is mainly for physical goods such as groceries, clothing or electronics, for physical services such as transport, cleaning, airfare, gym memberships, food delivery or live event tickets, or for a credit card or utility bill.
The edges are published too. Apple allows a digital gift card redeemable for digital goods only through in-app purchase, while a physical gift card posted to the customer may use another payment method. Credits bought through in-app purchase may not expire, and Apple expects a restore path for anything restorable.
One real asymmetry: Apple's 3.1.3(d) lets a real time service between two people, such as tutoring or a consultation, take payment outside in-app purchase, and requires in-app purchase for one to few and one to many. Google publishes no equivalent clause, so the same booking app can legitimately charge a card on iOS and still owe Play billing on Android. Google's exclusions cover peer to peer payments, online auctions and tax exempt donations instead. If what you sell renews, the console work and the rules both grow, which is add subscriptions.
Apple, App Store Review Guidelines, sections 3.1.1 to 3.1.3, read 3 October 2026
Check it
Which system does this purchase need?
Pick what the customer is actually buying. The answer is the same on both stores unless it says otherwise.
Store billing, and it is mandatory
Apple guideline 3.1.1 covers unlocking features and in-game currencies. Google's Payments policy names virtual currencies, extra lives and add-on items in the same list.
What each store takes, and the one number Apple does not print
Google publishes a full table and it changed this year, so most rates you will read elsewhere are stale. For users in Australia, the European Economic Area, Japan, the United Kingdom and the United States, the fee now turns on whether the install is new or existing, measured against a rollout date of 30 June 2026 for the EEA, the UK and the US and 30 September 2026 for Australia and Japan. On the first million US dollars of annual earnings it is 10 percent plus a 5 percent billing fee. At standard rates it is 10 percent plus that fee for auto renewing subscriptions, 20 percent plus it for other transactions from new installs, and 25 percent plus it from existing installs, or 20 percent where the sale came from an external web link. Every other market keeps the older tiers: for developers enrolled in the 15 percent tier, 15 percent on the first million dollars a year and 30 percent above it, plus 15 percent on auto renewing subscriptions whatever you earn.
Apple publishes its reduced rates clearly and its standard rate hardly at all. The Small Business Program page gives 15 percent to developers with proceeds of at most one million dollars in the prior calendar year and no more than that in the current one, and says developers new to the App Store qualify. Apple's subscriptions page states the split from the other side: you keep 70 percent during a subscriber's first year, 85 percent once they accumulate a year of paid service, and 85 percent from the start inside the Small Business Program. In the European Union, Apple's own DMA page prints the commission directly under terms effective 1 October 2026: 26 percent with Apple In-App Purchase, 15 percent for Small Business Program members and for subscriptions past their first year, 20 and 10 percent for alternative payment processing in the app, and a 5 percent Core Technology Commission outside the App Store, which replaced the per install Core Technology Fee. All three pages read 3 October 2026.
Which leaves the figure everyone quotes. The familiar 30 percent for a one-time purchase outside the EU appears on none of those Apple pages; the Small Business Program page says only that the standard commission rate applies. For subscriptions the arithmetic is public, because 70 percent to you is 30 percent to Apple. For anything else the rate sits in Schedule 2 of the Paid Applications Agreement, which you accept inside App Store Connect rather than read on the open web, so open yours before you set a price. A rate that size is a pricing decision rather than a screen, which is where add a paywall starts.
What has to exist before one test purchase can succeed
On iOS the first gate is legal. The membership Account Holder accepts the Paid Apps Agreement in the Business section of App Store Connect and adds banking and tax details, and Apple states the agreement must be Active before you can test in the sandbox at all. Products are created in App Store Connect: open the app, click In-App Purchases under Monetization in the sidebar, use the add button, pick Consumable or Non-Consumable, then give it a reference name and a product ID. Apple caps this at 10,000 products per app and warns that metadata edits can take an hour to reach the sandbox. The build has to be signed with a provisioning profile carrying the bundle identifier and the In-App Purchase capability.
Apple also reviews the products. Each one is submitted for review, and your first must go in with a new version of the app; once the first consumable or non-consumable is approved you can add more of that type without shipping a build.
On Android the gates come in a different order, and this is the step that strands people. You need a Google Payments Center profile linked to your Play developer account, and then you must publish a version of the app containing the Play Billing Library before the Play Console will let you configure products at all. Any track counts, including internal testing. Only then does the form open, at Monetize with Play, then Products, then One-time products, then Create one-time product. The product takes an ID, a name and a description; under it sits a purchase option with its own ID, a purchase type of Buy or Rent, a flag marking it Digital content or a Service, and regional pricing. Then you click Activate. Google documents no separate review of the product itself.
Names have moved on both sides, which matters because older pages describe the old ones. What Google called in-app products are now one-time products, in three levels: the product, the purchase option that sets how the entitlement is granted and what it costs, and offers that discount it or run a pre-order. The Play Developer API's inappproducts service is superseded by onetimeproducts for that model. The library is com.android.billingclient:billing at 9.1.0, and Google's deprecation table gives version 7 a deadline of 31 August 2026 for new apps and updates with an extension deadline of 1 November 2026, so an app still on 7 cannot ship an update today without that extension. On Apple's side the Swift based Apple In-App Purchase API is current, with Product, purchase(options:) and Transaction.currentEntitlements; the older SKPaymentQueue generation now sits under Deprecated as the Original API for Apple In-App Purchase.
What a refusal returns, and what you can test without a phone
Nobody is asked for a permission here the way a camera prompt asks. The only consent surface is the store's own purchase sheet, shown once per purchase, and your code learns the outcome from a result. On iOS, dismissing the sheet gives Product.PurchaseResult.userCancelled and no transaction. A child buying under Ask to Buy produces the pending case, and Apple's testing guide is explicit that a declined request sends your app no transaction at all, so the only correct behaviour is to change nothing and keep listening on Transaction.updates. Separately, AppStore.canMakePayments returns false when Screen Time content and privacy restrictions block purchases, or a device management profile does, and Apple's guidance is then to offer neither in-app purchase nor external purchase.
On Android a cancelled sheet is USER_CANCELED, which Google describes as the user clicking out of the billing flow. A purchase can also arrive PENDING while a slower payment method completes, and you grant nothing until it turns PURCHASED. Android also has a deadline iOS does not match: acknowledge the purchase within three days or Google refunds it automatically and revokes the entitlement. Apple asks you to call finish on the transaction once the content is delivered, which is correctness rather than a countdown.
Hardware is where the platforms differ most. StoreKit Testing in Xcode keeps the products in a local configuration file, needs nothing in App Store Connect, works without a network and runs in Simulator, and some cases exist only there: forcing StoreKit errors, approving or declining an Ask to Buy, and testing a subscription price increase are all marked unavailable in the sandbox. Apple's sandbox then wants the real products plus a Sandbox Apple Account, which appears under Settings then Developer after your first purchase attempt in a development signed build. Android has no local equivalent: the Play Billing Library is blocked for apps not signed and uploaded to Google Play, license testers lift that check so a sideloaded debug build works, and Google's testing guide points at Android hardware running a current Google Play app. Draft apps and internal test track purchases also carry spend limits. Which products to sell, and at what price, is the decision underneath all of it: choosing what to charge for.
The same purchase, the two stores, side by side
| What it takes | App Store, iOS | Google Play, Android | Harder platform |
|---|---|---|---|
| What the customer is asked | Apple payment sheet, once per purchase | Play purchase dialog, once per purchase | even |
| Where the capability is declared | In-App Purchase capability in the provisioning profile | com.android.vending.BILLING, carried by the library manifest | even |
| Before you can create a product | Paid Apps Agreement accepted by the Account Holder | Payments profile, plus a published build containing the library | Android |
| Store review of the product itself | Required, and the first one ships with an app version | None documented, you click Activate | iOS |
| Testable without real hardware | Yes, StoreKit testing in Xcode runs in Simulator | Not documented, Google points at an Android device | Android |
Building the purchase into an app you own
The code is the small half. Fetch the products by ID, show the price the store returns rather than one you typed, start the purchase, verify the result, grant the thing, then close the loop: acknowledge or consume on Android, call finish on iOS. Build the refusal paths at the same time, because cancelled, pending and not allowed to pay are three different states and all three default to granting nothing.
Newly is an AI app builder: you describe the app in plain English, it writes a React Native and TypeScript project you own, runs it on cloud iOS and Android simulators while it builds, and ships to TestFlight and Google Play internal testing. Ask the agent for purchases and it shows a Connect RevenueCat card, sets up the subscription products and adds the paywall; only an owner or admin can connect it. It is $25 a month on effort-based credits, with no free plan. What no builder does for you is accept the Paid Apps Agreement, create the product records or press submit. Apple's guideline 4.2.6 is why the last one is yours: an app made with a generation service is rejected unless the owner of the content submits it.
Plan the first purchase around the gate furthest away. On Android that is the upload, because no product exists in the console until a build with the Billing Library is live on a track. On iOS it is the agreement and the first review, because the first in-app purchase travels with an app version. Neither is removed by writing better code.
Questions people ask about in-app purchases
No, and you are not allowed to use it. Apple's guideline 3.1.3(e) says physical goods or services used outside the app must be paid for by another method, such as Apple Pay or a card field. Google's Payments policy says Play billing must not be used where the payment is mainly for physical goods or physical services, listing groceries, clothing, electronics, transport, cleaning, airfare, gym memberships, food delivery and live event tickets. Both read 3 October 2026.
Decide what is being sold, then build it
List everything a customer can buy and mark whether they use it inside the app or outside it. That list decides which system you need, which agreements to start today, and what your first test purchase has to prove.
Start building