How to do payments on mobile?
Sorta specific question: how are we doing payments?
I have an rn expo app using supabase for db/auth and a nest js backend on railway. Sometimes call straight from db for reads but backend for most complex stuff. I’ve seen people talk about how stripe is painful rn, and clerk is a nice wrapper for that.
So I have 2 options:
supabase + clerk (+ technically stripe)?
OR
supabase + stripe?
Is there a better way to do this?
8 Replies
In-App Subscriptions Made Easy – RevenueCat
The world’s best apps use RevenueCat to power in-app purchases, manage customer data, and grow revenue across iOS, Android, and the web.
Handles all the Apple/Google complexity + Server-side receipt validation
Consider keeping Stripe only if you also have web subscriptions
May your pillow be extra cold all year long 🙇🏾♂️👏🏾
I was actually thinking of making a web version eventually tho?
But for now it’s mobile only, I’ll look into it
You will most likely need both RevenueCat (Mobile) + Stripe (Web)
Apple/Google force you to use their billing for digital content on mobile apps
15 - 30% fees iirc, you don't have a choice
A common practice is
Mobile: Higher prices to account for platform fees
Web: Lower prices since you save on fees (2.9% from Stripe)
Use RevenueCat for mobile, Stripe for web
Your NestJS backend syncs both to Supabase
Wait sorry if this is stupid but what about that epic v apple lawsuit recently? Doesn’t that mean we could just go straight to a stripe checkout and back skipping Apple/google?
Also it’s probably important to know it’s an ai inventory management app so we might def need usage-based pricing + subscriptions and multi-seat stuff eventually.
Ok upon review it seems like stripe is still the best option since I need those 2 things (usage based and multi-seat/revenue splits) + I can avoid giving Apple/google any money
I just have to link users to pay on the web and then log back into the app. But follow their guidelines for wording and design.
Which stripe probably has figured out right?
Apple has to allow alternative payment methods
But only for certain apps in certain regions (EU mostly)
If you're targeting businesses rather than consumers, you might be able to position as a productivity software rather than "just" a consumer app
I would go for a web first approach
Main sales/onboarding happens on web, mobile would be something like a companion app
Ok yeah that makes a lot of sense. You are the best
Also your site is beautiful, would love your feedback on the app’s security/everything when it’s in beta
Of course
Thank you very much, feel free to reach out