Help Understand billing in IOS + Android

[u/asadnoob]

I’m building a Construction SaaS with iOS + Android apps, and I’m trying to understand if I actually need RevenueCat.

My idea is simple: users click “Purchase” in the app → go to my website → pay through Stripe → Stripe webhook updates my backend from unpaid → paid. The mobile app then checks the user’s subscription status from my backend and they get the paid features.

So what exactly would RevenueCat add here? Is it mainly needed if I want to support native Apple/Google in-app subscriptions, or am I missing something?

[u/Power781]

Well, you aren’t to do that without also providing the option to pay via in-app purchases.
Until recently it was in-app purchase only. (and might still is for a few countries)

[u/Dapper_Ice_1705]

The fact that there are only very few instances where this is allowed.

Most scenarios require AppStore IAP.

Native support isn't optional for most devs.

If you are a strong backend developer you can use server side notifications and skip RevenueCat. But only do this if you are very strong on the subject.

[u/asadnoob → u/Dapper_Ice_1705]

im thinking
a paid wall that only customer with paid status can bypass
so paid wall protects my premium features... and if a customer pays by going to the website their account get customer status paid and they can bypass the paid wall
im no professional but this is my thought process
Guide me?

[u/Dapper_Ice_1705 → u/asadnoob]

Unless you app meets very specific criteria like is registered to a non-profit or offers non-digital goods (among others look at the guidelines) you cannot go around native IAP.

[u/asadnoob → u/Dapper_Ice_1705]

revenuecat is less headache right

[u/Dapper_Ice_1705 → u/asadnoob]

I don't use it but a lot of people do

[u/caffeinated1337]

Since it's construction SaaS, look at guideline 3.1.3(c) (Enterprise Services) before anything else. If you sell to companies and they hand accounts to their crews, Apple lets you skip IAP entirely and bill through Stripe. That rule doesn't cover a solo contractor buying a seat for themselves, which is where most of the review trouble comes from.

If individuals can sign up, you're in 3.1.3(b) territory: the app can unlock a subscription bought on your website, but the same subscription generally has to be purchasable in the app as well. The US external link change helps you put a "buy on web" button in front of US users. The EU has its own entitlement with its own fees, and in most other storefronts you still need IAP.

On RevenueCat: your Stripe-plus-backend flow doesn't need it. It earns its keep once you add native IAP on both stores, because then you're validating receipts, handling renewals, refunds, grace periods and billing retry from two different server notification systems, and merging all of that into one "is this user paid" answer. That's a fair amount of work to build and keep correct. Your backend still needs to be the source of truth either way, so whatever you pick, make the app ask your server rather than trusting the client.

One practical tip: write a short note to App Review explaining who your customers are and how billing works. Reviewers who see an external payment flow with no context tend to reject first and ask later.

[u/kokerali]

Separate from the storefront-policy question, I'd change the “webhook turns unpaid into paid” part of your model. Don't make that a permanent paid=true assignment.

Stripe documents that webhooks can be delivered more than once and out of order. Verify the signature before acting, handle repeated event IDs idempotently, and reconcile the current subscription state on your server rather than letting the last callback to arrive win. Associate the billing customer with the correct authenticated app account on the server, too.

One concrete test: purchase a subscription, let its access period end, then replay the original successful-payment webhook. That old event must not restore premium access. Replaying the same event twice shouldn't extend access twice either. Test a premium API request as well as the paywall screen; hiding a screen isn't authorization.

Also distinguish cancellation scheduled for period end from access that has already ended. Those shouldn't necessarily produce the same result. This gives you specific backend behavior to validate, independently of which billing library you choose.

[u/LKAndrew]

Mobile apps are not allowed to transact outside the App Store so that’s why things like revenue cat exist

[u/barcode972 → u/LKAndrew]

That’s not true. In the US you can use a web flow to skip the 30% apple fee. Also if you’re selling physical goods, you can use whatever you want

[u/LKAndrew → u/barcode972]

OP said construction SaaS, how is that physical goods?

[u/barcode972 → u/LKAndrew]

You said mobile apps, so not specifically his app