In-App Purchase or Website Checkout: How Should a Business App Collect Payment?

Most business apps should not default to Apple or Google in-app purchase. Classify each sellable item first: digital goods and unlockable app features sold inside a store-distributed app typically require Apple In-App Purchase or Google Play’s billing system, while physical goods and real-world services consumed outside the app must use merchant checkout such as Apple Pay, cards, or your website payment flow. This article gives you a Payment Path Ladder, a Payment Path Fit Scorecard, and a worked example so you can approve the payment architecture before engineering builds the wrong checkout.

Key takeaways

• Apple’s App Store Review Guidelines require In-App Purchase to unlock features or functionality inside the app, and require non-IAP methods when people buy physical goods or services consumed outside the app.

• Google Play’s Payments policy requires Google Play’s billing system for in-app digital goods and services, and states that physical goods and physical services are not supported by Play Billing.

• Mixed catalogs must be judged at the SKU level. Google requires Play Billing for SKUs that include more digital than physical value, or that are marketed as digital.

• Consumption-only companion apps can avoid in-app digital checkout when purchases happen elsewhere—but in-app steering to alternate payment methods is restricted, with important regional exceptions.

• Use the Payment Path Ladder and Payment Path Fit Scorecard below before you fund StoreKit, Play Billing, or a merchant checkout build.

Why payment architecture is a product decision

Payment choice looks like an implementation detail. In practice it decides fees, refund ownership, subscription renewal behavior, tax handling, and whether App Review or Play review rejects the binary.

Teams often reverse the sequence: they pick a checkout UI first, then discover that a membership sold inside the app is treated as digital, or that cake orders cannot use Play Billing. Rework at that stage is expensive because entitlements, receipt validation, and merchant-of-record wiring are already underway. The decision also interacts with earlier product choices such as what belongs in version 1. If V1 sells both digital unlocks and physical fulfillment, you may need two payment rails—not one universal checkout screen.

What Apple and Google actually require

Apple: unlockables use IAP; physical and out-of-app purchases do not

Guideline 3.1.1 states that if you want to unlock features or functionality within your app—subscriptions, premium content, unlocking a full version, and similar—you must use In-App Purchase. Apps may not use their own mechanisms to unlock content or functionality.

Guideline 3.1.3(e) is equally direct in the other direction: if your app enables people to purchase physical goods or services consumed outside the app, you must use purchase methods other than In-App Purchase, such as Apple Pay or traditional credit card entry.

Other 3.1.3 paths matter for business apps. Reader apps may let users access previously purchased magazines, books, audio, music, or video. Multiplatform services may let users access content bought on the web or another platform, provided those items are also available as In-App Purchases inside the app. Enterprise apps sold only to organizations for employees or students may allow access to previously purchased content. Real-time person-to-person services between two individuals—such as tutoring or medical consultations—may use non-IAP methods; one-to-few and one-to-many real-time services must use In-App Purchase. Free stand-alone companions to a paid web tool need not use IAP when there is no purchasing inside the app and no purchase call to action outside the app.

For digital goods, steering rules are region-sensitive. Outside the United States storefront—and outside specific entitlement programs—Apple’s guidelines generally prohibit buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than In-App Purchase. United States storefront apps have broader latitude under the current guideline language, and Apple documents separate StoreKit External Purchase Link entitlements for specific regions. Treat US and non-US storefronts as different constraints.

Google Play: Play Billing for digital; not for physical

Google’s Payments policy says Google Play’s billing system is required for in-app purchases of digital goods and services distributed on Google Play, unless otherwise permitted. Required examples include digital items, subscription services, app functionality or content, and cloud software and services.

Purchases not supported by Play Billing include physical goods, physical services, and payment of a credit card or utility bill. Google’s Play Billing documentation likewise states that the system is only for digital items.

Google also documents consumption-only apps: users may log in and access content paid for elsewhere when the app does not enable purchasing from within the app. Outside the app, developers may communicate about alternate purchase options. Inside the app, leading users to a payment method other than Play Billing is restricted unless an applicable policy section or regional program applies. Google currently documents billing-alternative programs for eligible developers in regions such as the EEA, India, South Korea, and—while a U.S. court order remains in effect—specific U.S. program enrollment paths.

The Payment Path Ladder

Use this ladder to choose the earliest justified payment architecture—not the cheapest-looking checkout. Climb only as far as each SKU’s real consumption model requires. Many apps operate on more than one level.

For many local service and ecommerce brands, L1 is the correct primary path. For consumer digital products, L4—or L3 if you already sell on the web—is typically the correct primary path. L0 is a deliberate product choice, not a loophole for hiding a paywall behind a vague “visit our site” button.

Payment Path Fit Scorecard

Score your planned checkout before development. Each item is 0 (no), 1 (partial), or 2 (yes). Total ranges from 0 to 14.

• 0–5: Do not build checkout yet. Finish SKU classification and consumption mapping first.

• 6–9: Build only the primary ladder level that matches your dominant SKU type. Defer secondary rails.

• 10–14: Ready to implement the chosen path, with monitoring for rejection reasons and refund mismatches.

Worked example: a clinic booking app with a digital membership add-on

Consider a hypothetical multi-location clinic building a customer app. Stakeholders want one checkout for everything: in-clinic appointments, retail products shipped from the front desk, and a digital “priority booking” membership that unlocks exclusive in-app scheduling slots.

Initial scorecard before redesign: SKU classification 0; consumption location 1; mixed-catalog rules 0; steering compliance 1; entitlement/restore 0; merchant-of-record 1; reviewer testability 1. Total: 4. Not ready.

Revised architecture:

1. Appointments and shipped retail products stay on L1 merchant checkout (Apple Pay, card, or the existing web payment processor).

2. Priority booking membership moves to L4 store billing because it unlocks functionality inside the app.

3. The app may still show appointment history for web bookings without selling the digital membership through a custom web paywall inside the binaries outside allowed regional rules.

4. Demo accounts include one unpaid user and one membership user so reviewers can exercise both rails.

Re-scored total typically lands around 12 when the SKU map, entitlements, and reviewer notes are written down. The clinic still has two payment rails—but that is cheaper than one non-compliant rail and a rejection cycle.

Common failure patterns

• Fee-first architecture: choosing website checkout for digital unlocks solely to avoid store commissions, then discovering guideline 3.1.1 or Play Payments blocks the release.

• One-cart thinking: mixing physical fulfillment and digital unlocks in a single payment API without SKU classification.

• Reader theater: calling the app consumption-only while the home screen pushes “Buy Premium on our website” in storefronts where that steering is restricted.

• Exception inflation: treating every service as Apple’s 1:1 person-to-person exception, including group classes or content that remains available after the session.

• Region blindness: shipping US-storefront CTA patterns worldwide, or assuming an EEA, India, or Korea program applies without enrollment and implementation requirements.

• Missing restore path: selling digital entitlements with no restore or server verification, creating support debt and review risk.

Limitations and exceptions

Regional programs change faster than most product roadmaps. Apple’s external purchase and link rules differ by storefront and entitlement. Google documents alternative billing and user-choice programs with eligibility, fee, and implementation requirements. If your revenue depends on a regional exception, verify the current program page before you promise leadership a fee model.

Enterprise-only distribution and employee tools can change who pays and how accounts are provisioned, but they do not automatically authorize consumer digital unlocks through arbitrary web checkout on public store listings. This article is decision support for product sequencing—not legal or tax advice, and not a substitute for reading the live Apple and Google policy pages for every storefront you ship.

What to do next

1. Inventory every V1 SKU and label each one digital-in-app, physical/out-of-app, 1:1 exception, or consumption-only access.

2. Pick the primary Payment Path Ladder level for the dominant SKU type, then decide whether a second rail is truly required for launch.

3. Score the plan with the Payment Path Fit Scorecard; delay engineering if you are below 6.

4. Document reviewer credentials, restore and refund ownership, and storefront-specific CTA rules before submission.

When payment rails have to live inside a broader build plan—delivery approach, store submission, analytics, and post-launch iteration—Oasbit’s mobile app development services can help you sequence those decisions so checkout matches platform rules instead of fighting them in review.

If you want a practical review of your app’s SKU map and payment path before engineering locks the architecture, book a growth strategy session.

Sources

• Apple App Store Review Guidelines (section 3.1 Payments, including 3.1.1 and 3.1.3)

• Google Play Console Help: Understanding Google Play’s Payments policy

• Android Developers: Google Play’s billing system

• Apple Developer: Payment options on the App Store in the EU

• Apple Developer News: Updated guidelines now available (May 1, 2025)