4 ms·
Yes, which is why I am asking for Stripe to do an IAP wrapper as other companies have tried. Apple and Android’s subscription APIs are terrible, essentially wha
by cyral 5y ago
Yes, which is why I am asking for Stripe to do an IAP wrapper as other companies have tried. Apple and Android’s subscription APIs are terrible, essentially what is needed is an abstraction around them to keep user entitlements in sync without having to deal with the native APIs. The IAP is still handled natively, but the receipts and notifications are used to create a consistent experience.
- joshstrange 5y agoAhh, that’s an interesting proposition and the more I think about it, the more I like it. Just pass in some param to the “create payment intent” to indicate it’s a IAP-required purchase and they wrap the internal Apple/Google implementation. You’d still need to handle Apple/Google-specific errors but it’s be in one code-flow (the same way you have to handle secure-3D or whatever it’s called in the current Stripe payment flow). Really they’d be smart to create an “External Payments” or “Off-platform payments” concept to support more than just Apple/Google. It could be a little odd to not get payouts on a portion of your invoices (like it could cause weird issues if you suck all the Stripe data into another tool/your platform, you’d have to take that into account) but it might be useful to enough people. It sets Stripe up to step in, with small code changes for the developer, if the walls weaken/come down around current IAP policies. Also, it provides only 1 API for a dev who wants to offer CC as well Apple Pay (not IAP) instead of 2 or just skipping CC (using only Apple Pay). All that said, it will be a hard sell to Stripe execs who will probably see it as a large maintenance burden all to record stuff they don’t make money off of. I do like the idea though!