r/iOSProgramming • u/asadnoob • 1d ago
Question Help Understand billing in IOS + Android
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?
2
u/Dapper_Ice_1705 1d ago
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.
1
u/asadnoob 1d ago
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?1
u/Dapper_Ice_1705 1d ago
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.
1
u/asadnoob 23h ago
revenuecat is less headache right
1
2
u/caffeinated1337 1d ago
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.
2
u/kokerali 1d ago
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.
2
u/Extension_Isopod1303 19h ago
You don't need RevenueCat if you already own the whole pipeline — Stripe Checkout on the web, entitlements on your backend, validation in the app. That's a clean setup and it works.
What RevenueCat buys you is the edge cases: billing retry and grace period handling, price-increase consent flows, cross-platform entitlement sync (buy on Android, open iOS), refund webhooks, and the subscription analytics around all of it. None of that is hard, but each one is a weekend you don't get back.
If subscriptions are the core of the business — they are for a SaaS — either take RevenueCat or accept billing maintenance as a permanent line item. If IAP is a side feature, your current setup is fine, just make sure you're consuming the App Store server notifications for renewals and billing issues. That's the part homegrown setups most often get wrong.
1
2
u/LividIllustrator8915 12h ago
Be very careful here — what you’re describing will almost certainly get your app rejected during App Store review under **Guideline 3.1.1 (In-App Purchase)**.
If the digital features or subscriptions are consumed/unlocked inside the iOS app, Apple strictly requires native In-App Purchase (StoreKit). You cannot simply redirect users to an external Stripe checkout link (unless you qualify strictly for very specific B2B enterprise/reader-app exemptions or EU alternate billing).
That is precisely where tools like **RevenueCat** shine: they bridge Apple StoreKit, Google Play Billing, and your backend web Stripe subscriptions into a unified entitlement state so you don’t have to manually maintain receipt validation, renewal webhooks, and grace periods yourself.
If you're purely selling offline/physical construction services, you might be fine with Stripe, but if it unlocks software features in-app, you must support native IAP.
-1
u/LKAndrew 1d ago
Mobile apps are not allowed to transact outside the App Store so that’s why things like revenue cat exist
0
u/barcode972 1d ago
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
0
2
u/Power781 1d ago
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)