3 ms·
As someone in these shoes, coming from experience, it is a pain. Where it could just be stripe/whatever single payment system you choose, it now has to be an a
by camhart 6y ago
As someone in these shoes, coming from experience, it is a pain. Where it could just be stripe/whatever single payment system you choose, it now has to be an abstraction at best. The abstractions aren't perfect--they limit you to only using the common features across all payment systems you have to support. It absolutely creates a poor user experience for customers.
Want to prorate upgrades? Well google play doesn't offer that. Want to allow switching from monthly to annually? Does Apple offer that? Want to issue a partial refund? Want to credit an account? Etc.
It goes further, a customer emails and asks "how do I cancel?". Instead of having easy instructions for them, it's now a switch block for all the different IAP solutions. If that customer forgets how they signed up, now they need to dig through all the IAP steps for cancelling.
And it's not just Google Play and Apple. There's web, Windows store, amazon app store, android, ios, chrome payments (deprecated), something for linux, etc.
While revenuecat seems decent for Google/Apple, it doesn't touch any of the others.
I'm not saying it's not possible. All I'm saying is it's a whole lot of extra work just to allow the largest companies in the world to scalp 30% from an indie dev, and force a poor experience down users throats.
- manquer 6y agoit is going to be rough around the edges. Platform pain is already there, react native is a solution to a similar problem. It is no means perfect, you cannot avoid knowing the underlying platform kinks and library limitations Abstractions are not excuse for the underlying payment grab both the vendors are forcing on the devs. Just saying such problems and abstractions are not new and indie devs will get some relief with an abstraction