How to Accept Payments in a Mobile or Web App
How you take payments in an app depends mainly on what you sell. Physical goods and real-world services (meals, rides, appointments, repairs) must use a payment processor such as Stripe, Square or Braintree, with Apple Pay and Google Pay as options. Digital goods and subscriptions used inside the app generally go through Apple In-App Purchase and Google Play Billing, though US rules now allow links or alternative billing in many cases. On the web, any processor works. Use hosted payment fields so card data never touches your servers.
- The store rules split on what is sold: physical goods and services use regular processors, digital content usually uses store billing.
- Apple's US storefront rules now permit buttons and links to external purchases; fees on those purchases are still being litigated.
- Google Play's Payments policy allows alternative billing and external links in eligible regions through enrollment programs.
- Hosted payment fields and native SDKs keep card numbers off your servers and shrink your PCI DSS scope.
- Confirm payments with server-side webhooks, not the app's success screen.
The Steps
- Classify what you sellSort every paid item into physical goods, real-world services, digital content or features, subscriptions, or payments between users. The category decides which payment systems the app stores permit.
- Check current store payment rulesRead Apple's App Store Review Guidelines section 3.1 and Google Play's Payments policy for each country you sell in. US rules on external links changed in 2025 and 2026.
- Choose your processor and methodsPick a processor such as Stripe, Square, Adyen or Braintree for non-store payments, and decide on cards, Apple Pay, Google Pay, bank debits or buy-now-pay-later based on your customers.
- Use hosted fields or native SDKsCollect card details through the processor's prebuilt payment sheet, hosted checkout or secure fields, so raw card numbers never pass through your servers or logs.
- Create payments on your serverHave your backend create the payment or subscription with the processor's secret key, and send only a client token to the app. Never ship secret keys in the app.
- Confirm with webhooksListen for processor and store server notifications to mark orders paid, renew or cancel subscriptions, and handle refunds and disputes. Make handlers idempotent so retries do not double-charge.
- Handle tax, receipts and refundsDecide how sales tax is calculated and filed, send receipts, publish a refund policy, and give support staff a safe way to issue refunds. Ask an accountant about tax obligations.
- Test every failure pathUse sandbox and test cards to simulate declines, expired cards, authentication challenges, network drops, refunds and subscription renewals before going live.
The Rule That Decides Everything: What You Sell
Apple and Google draw a firm line between digital and physical purchases.
- Physical goods and real-world services, such as retail products, food delivery, rides, appointments, event tickets and home services, must be paid for outside the stores' billing systems. Google's Payments policy says Play billing must not be used for these, and Apple's guidelines require other payment methods. You use a regular processor and keep the store out of the transaction entirely.
- Digital goods and features consumed in the app, such as premium features, in-app currency, paid content and subscriptions to app content, generally go through Apple In-App Purchase and Google Play Billing, which take a commission. Apple's Small Business Program lowers its commission to 15 percent for developers with up to 1 million USD in annual proceeds.
- Payments between users, such as marketplaces and tipping a service provider, follow their own rules and usually need a marketplace payment product such as Stripe Connect, which handles seller onboarding, identity checks and payouts.
There are also exceptions for certain categories, such as "reader" apps for previously purchased content and services used across multiple platforms. Read the current text before you design your pricing.
What Changed in the United States
Court rulings in Epic Games' cases against Apple and Google changed US rules significantly in 2025 and 2026. As of late 2026:
- Apple: the App Store Review Guidelines no longer prohibit buttons, external links or other calls to action that send users in US storefront apps to purchase elsewhere, such as your website. An appeals court ruled that Apple may charge a commission on those linked purchases tied to its actual costs, and the specific rate was still being decided in court in late 2026. Outside the US, the prohibition still applies except under specific entitlements.
- Google: Google Play's Payments policy permits alternative in-app billing and links to outside payment in eligible countries for developers who enroll in the relevant programs, and Google revised its fee structure in 2026. Stripe's documentation, for example, describes processing digital-goods payments directly in Android apps for US users.
Because these rules and fees are still moving, do not build a revenue model on a specific commission rate without checking the current terms. A common pattern is to offer store billing in the app for convenience and a web checkout for customers who prefer it, then compare conversion and net revenue for each.
Keeping Card Data Out of Your Systems
If your servers ever receive a raw card number, you take on a large share of PCI DSS compliance work. The simple way to avoid that is to never touch card data: use the processor's prebuilt payment sheet in the mobile SDK, a hosted checkout page, or secure embedded fields on the web. The card details go straight to the processor, and your system stores only a token. Stripe's integration security guide explains how integration choices affect your PCI validation requirements.
Two more security basics. The processor's secret key lives only on your server; the app gets a publishable key and short-lived client secrets. And your app's "payment succeeded" screen is not proof of payment. Mark orders as paid only when your server receives a verified webhook or confirms the payment through the processor's API. For a broader checklist, see how to secure a mobile app.
Subscriptions Need More Care Than One-Time Payments
Subscriptions create ongoing states to track: trials, renewals, upgrades, downgrades, grace periods, failed renewals, cancellations and refunds. Whichever system bills the customer, keep your own server-side record of each user's entitlement, updated from Apple's App Store Server Notifications, Google's Real-time developer notifications or your processor's webhooks. If a customer subscribes on the web and opens the app, or the reverse, your backend decides what they can access, regardless of where they paid.
Make cancellation easy to find. Both stores have rules on subscription disclosures, and US consumer protection rules on negative-option billing apply to subscriptions sold on the web as well. Have a qualified professional review your subscription terms.
Choosing a Processor
For most small and mid-sized businesses, the major processors are all capable. Compare them on the factors that affect you: supported payment methods (Apple Pay, Google Pay, ACH, buy-now-pay-later), the quality of mobile SDKs, marketplace and payout features, in-person payments if you also sell at a counter, dispute handling tools and international coverage. Pricing models are similar in structure (a percentage plus a fixed fee per transaction, with add-ons for extra services) but details change, so compare current pricing pages for your expected volume. If your app connects to existing systems, check integrations with your CRM and accounting software. Our e-commerce page and the guide to budgeting for app development cover how payments fit the wider build.
Sources and Further Reading
We link to the primary documentation so you can verify the details yourself.
- App Store Review Guidelines (section 3.1, Payments), Apple Developer
- Payments policy, Google Play Console Help
- Accept in-app purchases on iOS and Android, Stripe Docs
- Integration security guide, Stripe Docs
- App Store Small Business Program, Apple Developer
- Google Play's billing system, Android Developers
Related Questions
Can I use Stripe instead of Apple In-App Purchase?
For physical goods and real-world services, yes, and you must. For digital content and features, Apple generally requires In-App Purchase, but US storefront apps may now link customers to a web checkout, such as Stripe Checkout. Check Apple's current guidelines and the status of fees on linked purchases before choosing.
Do I need to be PCI compliant if I use Stripe?
Every business that accepts cards has PCI DSS obligations, but using hosted checkout or prebuilt payment fields keeps card data off your systems and usually qualifies you for the simplest self-assessment. Your processor's dashboard and documentation explain which validation applies to your integration.
Should I add Apple Pay and Google Pay?
Usually yes for physical goods and services. They remove card typing, autofill billing details and use device authentication, which tends to make mobile checkout faster. Most processors support both through their mobile SDKs and web checkout with modest extra work, including domain verification for Apple Pay on the web.
How do I handle sales tax on app purchases?
For store billing, Apple and Google generally handle tax collection in many regions. For your own processor, you are responsible for calculating, collecting and remitting tax where you have obligations. Tax automation services can help, but ask an accountant which states and products require collection.