Skip to main content
If your app charges for anything digital — a subscription, a pro unlock, credits, extra levels — Apple and Google both have rules about how you take that money. Getting it wrong is one of the most common reasons a first submission is rejected. This page covers the rules that matter in practice, and what Bilt’s Payments setup does for you.
Store policies change often. This page reflects the guidelines as of 2026 — always check Apple’s App Review Guidelines and Google Play’s Payments policy before you submit.

​
First question: does your app even need in-app purchases?

Both stores draw the same line, and both reject apps on the wrong side of it. The test is not “am I selling something” — it’s what the buyer gets, and where they use it.
Adding in-app purchase to a physical-goods app gets rejected just as fast as skipping it for a digital one. Pick the right lane before you build the paywall.

​
When you may use Stripe, Shopify or another provider

Beyond physical goods, both stores carve out cases where outside payment is allowed. Apple lists them under guideline 3.1.3; Google’s Payments policy has close equivalents.
A Shopify storefront, a Stripe checkout for a product you ship, a booking flow for a real appointment. These must use an outside provider, and the checkout can live directly in the app. This is the clearest case, and the one most Stripe- and Shopify-based apps fall into.
Apps whose main purpose is consuming magazines, newspapers, books, audio, music or video. They may let a user sign in and access content bought elsewhere — but cannot include buttons or calls to action pointing at your web checkout unless you hold Apple’s external-link entitlement.
If a user already subscribed on your website, an Android app or a console, the iOS app may honour that subscription. What you may not do is sell the subscription outside the store from inside the app.
Sold to organisations for their employees rather than to individual consumers. Seats are billed on your own invoice; the app is sign-in only.
Live, individual person-to-person sessions — tutoring, medical consultations, fitness coaching, a real-estate video tour — may be paid outside the store. The moment it becomes one-to-many (a recorded course, a group class, a webinar for 50 people), it counts as digital content and needs in-app purchase.
A free app that is a companion to a paid web tool (cloud storage, email, web hosting, a SaaS dashboard) does not need in-app purchase — provided the app contains no purchasing UI at all. Sign-in only.
Donations to registered nonprofits, sending money to another person, paying an invoice, taxes and physical club memberships are outside store billing. Rules on how donations may be collected differ between Apple and Google — check both before you build.

​
The cases people get wrong

  • Advertising and boosts. Paying to promote your own post or listing inside the app counts as digital and needs in-app purchase, even though the money buys “reach”.
  • Tips and gifts to creators for digital content need in-app purchase. Tipping a real-world worker (a delivery driver) does not.
  • Mixed marketplaces. If your app sells physical goods and a premium membership, the goods go through Stripe or Shopify and the membership goes through the stores. Two payment paths in one app is normal and allowed.
  • “Just link to our website.” For digital goods, a button or link steering users to your own checkout is the classic rejection. Link-outs exist in some regions but are entitlement-gated — don’t assume.
  • Crypto and NFTs have their own rules on both stores, and owning a token cannot unlock in-app features.
Bilt can build a Stripe or Shopify checkout into your app like any other feature — just prompt for it. The Payments setup described below is specifically for App Store and Google Play in-app purchases.

​
Apple’s rules

Commission. 15% or 30% of each sale. Most new developers qualify for the Small Business Program at 15% for the first $1M per year — you have to apply for it. What reviewers check on a paid app:
  • Purchases go through StoreKit. No credit-card form, no PayPal button, no crypto for digital content (guideline 3.1.1).
  • A working “Restore purchases” button. Required. A user who reinstalls, or signs in on a new device, must be able to get their purchase back without paying again.
  • Price, term and renewal shown before purchase. For subscriptions, the paywall must say what it costs, how long the period is, and that it renews automatically (3.1.2).
  • Links to your terms and privacy policy on the paywall itself, not just in a settings screen.
  • A way to manage or cancel the subscription from inside the app (this can open Apple’s native manage-subscriptions sheet).
  • Account deletion in-app if your app has accounts (5.1.1(v)). Deleting the account must not be a support-email-only flow.
  • Entitlements work across the user’s devices — a purchase on iPhone must apply on iPad with the same Apple Account.
Linking out. Since 2025, US-storefront apps may link to an external purchase page without Apple’s commission, and EU apps can do so under the DMA terms. This is entitlement-gated and legally fiddly — if you are just starting out, take the simple path and use StoreKit.

​
Google Play’s rules

Commission. 15% or 30%, with 15% on the first $1M per year for most developers. What Play checks:
  • Purchases go through Google Play Billing for digital content (Payments policy).
  • Recent Play Billing Library version. Google raises the minimum version roughly every year, and apps below it eventually stop being updatable. Keep your builds current.
  • Purchases must be acknowledged within 3 days. An unacknowledged purchase is automatically refunded by Google — this is the single most common way a hand-rolled Android billing integration silently loses money.
  • Products defined in Play Console. Subscriptions use base plans and offers; the app cannot invent prices at runtime.
  • The same disclosure rules as Apple: price, renewal period, auto-renewal, cancellation path, terms and privacy links.
  • Server-side verification. Purchases should be verified with the Play Developer API rather than trusted from the device, and subscription changes tracked through Real-time Developer Notifications.
Alternative billing. Depending on your country, Play offers user-choice billing and external-offer programs with a reduced fee. Same advice as Apple: start with the standard flow.

​
What Bilt handles

Open Settings → Payments in your project — see In-app Payments for the full walkthrough.
1

Connect your store account

Payments reuses the App Store Connect API key, bundle ID and App ID you already set up in Publish to App Store. Bilt registers your app with the billing service and stores the credentials for you.
2

Author your catalog

In the Catalog tab, create your products — a monthly subscription, a lifetime unlock, whatever you sell. Each product maps to an entitlement like pro or no_ads. Saving pushes the products to App Store Connect and publishes the product-to-entitlement mapping to Bilt’s billing backend.
3

Ask for the paywall

Prompt for it like any other feature: “Add a paywall screen that offers the monthly Pro subscription, and hide the export button unless the user has the pro entitlement.” Bilt wires the generated app to the @biltme/iap client.
4

Test in a dev build

Development builds run against a mock billing environment, so you can walk through purchase, restore and entitlement gating without a sandbox Apple Account or a real charge. Mock purchases go through the same backend logic as real ones.
The pieces that usually take a backend engineer a few weeks are already built:
  • Server-side receipt verification — StoreKit purchase tokens are verified against Apple’s certificates on Bilt’s servers, not trusted from the device.
  • Entitlements, not SKUs — your app checks useEntitlement('pro'). Rename a product, add an annual plan, run a promo, and the app code stays the same.
  • Restore purchases — a built-in flow that re-reads the device’s purchases and reconciles anything the backend already knows about, which covers the reinstall and new-device cases reviewers test.
  • Manage subscriptions — one call opens Apple’s native sheet, satisfying the in-app cancellation requirement.
  • Subscription state stays current — Apple’s server-to-server notifications (renewals, cancellations, refunds, billing retries) are ingested and projected into entitlements automatically.
  • Offline retry — a purchase made on a flaky connection is queued and re-sent, surviving app restarts, so users don’t get charged without getting access.
  • User lookup — the Users tab lets you look up a customer, see their purchases and entitlements, and trigger a reconcile when a support ticket comes in.

​
What’s still on you

  • Enrolling in the developer programs, and completing tax and banking details in App Store Connect. Apple will not let you sell anything until those are filled in.
  • Writing honest paywall copy — price, period, and renewal wording. Ask Bilt for it, then read it as a reviewer would.
  • Choosing your prices and submitting the products for review alongside your build.
  • Deciding whether your app should be using in-app purchase at all — see the table at the top.
Payments currently covers iOS in-app purchases end to end. Google Play support is in progress; the entitlement model and catalog are already platform-neutral, so apps built on it now won’t need rewriting.

​
Further reading