How to Sell In-App Purchases Outside the App Store: A Practical Setup

To sell in-app purchases outside the App Store, you set up a web shop where customers buy your subscriptions or credits, link it to the same user accounts your app uses, and have the app unlock whatever they paid for. How you can point people from the app to that shop depends on the country of their app store account: on the US App Store you can now link straight to your own checkout, while in most other countries the app can't mention it at all.

This guide covers the practical side: what you need to build, which tools do the heavy lifting, and the mistakes that get apps rejected. If you want the background on the fees themselves, start with our guide to whether Apple and Google take a cut of app payments.

What is the web shop model for mobile apps?

The web shop model means your website becomes a second place to buy what your app sells. A customer pays on the web, and the purchase appears in the app because both use the same account.

It only matters for digital goods: subscriptions, premium features, credits, courses and in-app content. Physical products and real-world services, such as deliveries or appointments, can already be paid for with your own card processor inside the app, with no store commission.

Done well, a web shop gives you:

• Lower fees on the sales that move to the web, where you pay card processing rather than store commission.
• Your own customer relationship: you hold the email address, the billing history and the ability to offer discounts or annual plans the way you want.
• Pricing freedom, such as web-only bundles or introductory offers.

It also costs you something. Store billing is a single tap for someone already signed in, and a web checkout is an extra step where some people will give up. Treat the web shop as a second channel to test, not as an automatic switch.

Can I link from my app to my own checkout?

This is the rule that decides your whole set-up, and it depends on the storefront.

These are taken from Apple's App Review Guidelines, section 3.1.1. Because the rule follows the customer's storefront, one app can need different behaviour for different users. Stripe's documentation suggests using StoreKit's Storefront property to detect which storefront the app was downloaded from.

On Android, Google has introduced billing choice and a new fee structure in the US, the UK and the EEA, as our guide to app store fees explains. Stripe's guide notes that Android developers in the US can process payments directly in the app with a third-party processor. Google's fees still apply in many of these programmes, so model them before you assume a saving.

What if I can't link out?

Where links aren't allowed, the web shop still works. You just can't advertise it inside the app. Apple's "multiplatform services" rule (3.1.3(b)) lets customers use subscriptions and features they bought on your website, as long as those items are also available as in-app purchases in the app.

So the app sells through store billing, and you promote the web shop through your own channels instead: your website, emails to existing customers and social media. Reader apps (magazines, newspapers, books, audio, music and video) have a separate rule and entitlement for linking to account management on their own site.

What do I need to build?

Four pieces have to work together. Most failed web shops get one of them wrong.

1. One account across app and web

The customer must be the same person in both places. That means a proper sign-in system shared by the app and the website, rather than separate logins. Stripe's guide points to options such as Sign in with Apple or Firebase Authentication if you don't have one yet.

2. A checkout built for app users

You need a payment page that works well on a phone and returns people to the app afterwards. Hosted checkouts save a lot of work here: Stripe Checkout has a mode for app-to-web purchases, and RevenueCat's Web Purchase Links give you a hosted purchase flow without writing code. RevenueCat attaches the purchase to the right user by adding the app's user ID to the link, and offers redemption links for people who buy before they have an account.

To get customers back into the app, use Universal Links on iOS (ordinary web addresses that open your app), with a fallback page in case the link opens in the browser instead.

3. Your server as the single record of what each customer owns

Whether someone paid through Apple, Google or your website, your back end should decide what they're entitled to. The payment provider tells your server about each successful payment through a webhook, a message sent the moment payment completes, and your server updates the customer's access. The app then asks your server what to unlock.

Never let the app decide on its own that a purchase happened. It is the easiest thing for someone to fake.

4. Subscription management and refunds

Customers who buy on the web need a way to change their plan, update their card and cancel. Stripe offers a hosted customer portal for this. Decide your refund policy in advance too, because web refunds are your job, not the store's.

How should I handle tax on web sales?

When Apple or Google sells your subscription, they deal with sales tax and VAT in most countries. When you sell it on your own website, that becomes your responsibility.

In the UK, GOV.UK's guidance on digital services says supplies to UK consumers are liable to UK VAT, while consumers in other countries may be liable to VAT where they live. For EU customers, a UK business must either register for the EU's non-Union scheme in one member state or register for VAT in each member state where it sells. Other countries have their own rules.

There are two practical ways to handle this:

• Use your processor's tax tools, such as Stripe Checkout's tax collection, and register where required.
• Use a merchant of record, a provider that sells to the customer on your behalf and takes on the tax and disputes. Stripe offers this as Managed Payments; other providers work the same way. It usually costs more per sale, but it removes most of the tax admin.

Tax rules vary by country and change, so confirm your set-up with an accountant before launch.

How should I price web purchases?

Moving buyers to the web is about trade-offs, so price deliberately:

• Offer a reason to buy on the web. A lower price, a better annual plan or a bonus can make up for the extra step.
• Keep in-app purchase available wherever you must, and especially in countries where you can't link out.
• Watch your margin, not just the fee. After processing fees, tax tools, refunds and a lower conversion rate, the gap between store commission and web checkout is smaller than it first looks.

What should I measure?

Track the web shop as its own channel so you can tell whether it's working:

• How many people start a web checkout, and how many finish it.
• Revenue per customer, compared with store purchases.
• Refunds and chargebacks.
• Renewal rates for web subscribers compared with store subscribers.

Stripe lets you label each checkout integration so you can measure its conversion separately. Give it a few months of real data before deciding to push harder.

Common mistakes that get apps rejected

• Adding a link or button outside the US storefront without the right entitlement.
• Offering items only on the web in regions that rely on the multiplatform rule, which requires them to be available as in-app purchases too.
• Showing a card form inside the app for digital goods where the rules don't allow it.
• Letting the app grant access without checking with your server.

Frequently asked questions

If you'd like help planning or building a web shop for your app, from shared accounts and checkout to entitlements and tax, our app development team can map out what fits your markets and build it. Book a free consultation and we'll go through your app's payments with you.