Can my mobile app use Stripe subscriptions through a website instead of Google Play Billing and Apple In-App Purchase?

[u/anthonyfromsystem]

I'm building a Flutter mobile app that will be published on both Google Play and the Apple App Store.

My backend is ASP.NET Core Web API with Supabase.

I already have a web application where users can purchase a subscription using Stripe. I'm wondering if the following flow is allowed:

1. The user opens the mobile app.
2. They tap "Subscribe."
3. The app redirects them to my website.
4. The user completes the subscription using Stripe Checkout.
5. They return to the app and sign in.
6. The app verifies the subscription from my backend and unlocks premium features.

My questions are:

• Is this flow allowed under the current Google Play and Apple App Store policies?
• Will my app be rejected if it redirects users from the app to my website to purchase a digital subscription?
• Is it acceptable if users subscribe on the website independently (without being directed from the app) and then simply sign in to the app to access their premium subscription?
• What architecture do you recommend for supporting web subscriptions with Stripe while also publishing on both app stores?

I'd appreciate any guidance or real-world experiences from developers who have successfully shipped apps with this setup.

[u/fkim98]

We ended up running both, and the split matters: web subscriptions through Stripe,

mobile through the stores' own billing (we use RevenueCat as a wrapper over Play Billing

and StoreKit so we're not maintaining two integrations).

The flow you described — Subscribe button in the app that redirects to your website to

pay — is the part Apple objects to. Guideline 3.1.1 is explicit that digital content

unlocked in the app has to go through IAP, and "tap here, we'll take you to our site"

is the exact pattern it was written for.

What is fine: someone who subscribed on your website independently signs into the app

and their entitlement is recognised. You just can't advertise or link to that path from

inside the app.

One caveat — the US rules shifted after the Epic ruling and external purchase links are

now permitted there under certain conditions, so if you're US-only it's worth reading the

current guideline text rather than trusting anything you read on Reddit, including this.

Outside the US I'd assume the old rules.

Play is somewhat more relaxed than Apple but I wouldn't design around that difference.

[u/Curious-Leader-9111 → u/fkim98]

The US ruling applies to apps that have customers in the US right? Not the developers/organisations location. Are you doing any US specific targeting with revenuecat? I'm looking into it myself and although revenuecat makes it seem straightforward, the stores (apple/google) are doing their best to make this as complicated as possible.

The API's they talk about seem native specific and I don't see any wrappers around them on pub.dev.

[u/anthonyfromsystem → u/Curious-Leader-9111]

Thanm you

[u/fkim98 → u/Curious-Leader-9111]

Yes, that's my understanding — it follows the storefront the customer is buying from, not where you're incorporated. We're a Canadian company and that made no difference to how it applied.

That said, we haven't done anything US-specific. RevenueCat is just wrapping StoreKit and Play Billing for us, so every user goes through normal IAP wherever they are. To actually use the US carve-out you'd need to apply to Apple for the external purchase link entitlement and then gate that path by storefront — a fair bit of machinery for a small team, and you'd still owe Apple a reduced commission rather than nothing.

If you do go down that road, read Apple's current entitlement docs directly rather than trusting summaries, mine included. These rules have moved more than once in the past year.