4 ms·

Not related to payment links... but I would love to see Stripe take on handling in app purchases. (basically a webhook and management layer over the terrible na

by cyral 5y ago

Not related to payment links... but I would love to see Stripe take on handling in app purchases. (basically a webhook and management layer over the terrible native APIs) Companies like RevenueCat are halfway there but have nowhere as nice of an API or dashboard as Stripe. I run a cross platform (web/ios/android) app and would love to do payments all under one platform (Stripe, that is). Apple and Google subscriptions have so many complexities and edge cases that companies like RevenueCat and Qonversion are enormously helpful, but they themselves have many bugs and issues that I've ran into.

jeiting 5y ago
Would love to hear how we can improve the API to make you not want Stripe to do it better. :) Obviously, Stripe is the gold standard and I think we have a hard time, but we're hoping to improve the developer experience even more this year.
- cyral 5y ago
  My main issue is how the webhooks sometimes give incorrect info, which has led to many customer complains when their subscription gets messed up by some edge case that I would expect to be abstracted away by RevenueCat but isn't. For example, when I implemented the PRODUCT_CHANGE event I expected it would notify me of the new product, but that is not the case on Android which led to bugs with some customers. It turns out that only iOS sends the new_product_id, so it is impossible to know from this event what the new product should be to display it in the app. Since upgrades/downgrades are immediate on Android, it turns out that the solution was just to not handle that event on Android since the renewal event would override the product anyways. (but sometimes the events came out of order, which is what led to bugs when PRODUCT_CHANGE was after RENEWAL). There are a lot of cases where events in the dashboard are totally out of order and don't make sense, like showing a customer purchasing the lesser plan, then renewing for the upgraded plan, and then switching from the lesser to the upgraded plan 10 days later. How could that be possible? The switch should have been between the renewals, so it's very confusing to debug. I've been told that now the recommended approach is to ignore all the webhook data, and simply call the RevenueCat API to get the entitlement and subscription status - however I asked how to parse this into something meaningful and didn't get a good answer. I would like to know the users current entitlement, and the current subscription (which can be different than the entitlement). For example, if the user downgrades, their entitlement may still be the upgraded plan for a while, but the app should reflect that they are no longer subscribed, or that they are subscribed to a different plan. For the entitlement it is easy I think, just choose the highest entitlement level to use. For the subscription, maybe choosing the last renewed one would work? But there are so many complexities with downgrades, upgrades, crossgrades I don't know if that is true. The answer from support was basically that they didn't know, yet this is an absolute must for almost any app - there has to be a way to display what the user is currently paying (or not paying) for, linking out to the native UI is not an option as it's not user friendly and cannot be displayed cross platform (I want the website to also reflect what they are paying for). My big concern with this is also, why does the API supposedly return the correct data but the webhook doesn't? If I am calling the API 10ms after receiving the webhook, why can't the webhook just deliver correct data instead? Another current issue I discovered the other day was that grace periods are no longer working. The RevenueCat dashboard shows that they are getting a 7 day grace period (the expiration date in the dashboard is correct), yet in the webhooks I am getting the wrong expiration, one that is only a day away. Apparently this is due to a change by Google and a fix is (maybe?) on the way? But it caused a lot of issues that I didn't expect. Basically RevenueCat's promise is great, it has saved a ton of time but isn't quite there on fully abstracting all these native edge cases away, they crop up in the API occasionally, and the proposed fix to use the API instead of the webhook data is half baked when support has no idea how to actually parse it to get the current subscription that should be displayed to the user (in the case that they upgraded/downgraded and have more than one). I love the idea but I'm hesitant to recommend it to anyone because lately it's been causing a lot of headaches with customers having billing issues due to these inconsistencies.
  - jeiting 5y ago
    Thanks for the great feedback. These are all legit issues. We have on our roadmap a revisiting of our API this year and I think we need to have a lower tolerance for abstraction leakage. Would you mind dropping me an email jacob@revenuecat.com? I think for our long term viability we need to have the trust of people who care about edge cases like this. I’d love to hear more.
criddell 5y ago
Can you use Stripe in iOS and Android apps? I thought purchases had to go through Apple and Google?
- joshstrange 5y ago
  You can but only for physical goods or a small handful of other uses (person to person and 1-2 other special carve-outs I can't remember).
- cyral 5y ago
  Correct, I mean if Stripe developed a wrapper around the native APIs as other companies have done. Payment is still handled natively but Stripe would provide consistent webhooks without having to deal with Apple’s complex receipt API.
joshstrange 5y ago
If it's IAP for digital items then you can't use Stripe for IAP on iOS/Android, it has to go through the respective store's IAP logic.
- 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 ago
    Ahh, 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!
deleted 5y ago
[deleted]

by cyral 5y ago

jeiting 5y ago

Would love to hear how we can improve the API to make you not want Stripe to do it better. :) Obviously, Stripe is the gold standard and I think we have a hard time, but we're hoping to improve the developer experience even more this year.

cyral 5y ago
My main issue is how the webhooks sometimes give incorrect info, which has led to many customer complains when their subscription gets messed up by some edge case that I would expect to be abstracted away by RevenueCat but isn't. For example, when I implemented the PRODUCT_CHANGE event I expected it would notify me of the new product, but that is not the case on Android which led to bugs with some customers. It turns out that only iOS sends the new_product_id, so it is impossible to know from this event what the new product should be to display it in the app. Since upgrades/downgrades are immediate on Android, it turns out that the solution was just to not handle that event on Android since the renewal event would override the product anyways. (but sometimes the events came out of order, which is what led to bugs when PRODUCT_CHANGE was after RENEWAL). There are a lot of cases where events in the dashboard are totally out of order and don't make sense, like showing a customer purchasing the lesser plan, then renewing for the upgraded plan, and then switching from the lesser to the upgraded plan 10 days later. How could that be possible? The switch should have been between the renewals, so it's very confusing to debug. I've been told that now the recommended approach is to ignore all the webhook data, and simply call the RevenueCat API to get the entitlement and subscription status - however I asked how to parse this into something meaningful and didn't get a good answer. I would like to know the users current entitlement, and the current subscription (which can be different than the entitlement). For example, if the user downgrades, their entitlement may still be the upgraded plan for a while, but the app should reflect that they are no longer subscribed, or that they are subscribed to a different plan. For the entitlement it is easy I think, just choose the highest entitlement level to use. For the subscription, maybe choosing the last renewed one would work? But there are so many complexities with downgrades, upgrades, crossgrades I don't know if that is true. The answer from support was basically that they didn't know, yet this is an absolute must for almost any app - there has to be a way to display what the user is currently paying (or not paying) for, linking out to the native UI is not an option as it's not user friendly and cannot be displayed cross platform (I want the website to also reflect what they are paying for). My big concern with this is also, why does the API supposedly return the correct data but the webhook doesn't? If I am calling the API 10ms after receiving the webhook, why can't the webhook just deliver correct data instead? Another current issue I discovered the other day was that grace periods are no longer working. The RevenueCat dashboard shows that they are getting a 7 day grace period (the expiration date in the dashboard is correct), yet in the webhooks I am getting the wrong expiration, one that is only a day away. Apparently this is due to a change by Google and a fix is (maybe?) on the way? But it caused a lot of issues that I didn't expect. Basically RevenueCat's promise is great, it has saved a ton of time but isn't quite there on fully abstracting all these native edge cases away, they crop up in the API occasionally, and the proposed fix to use the API instead of the webhook data is half baked when support has no idea how to actually parse it to get the current subscription that should be displayed to the user (in the case that they upgraded/downgraded and have more than one). I love the idea but I'm hesitant to recommend it to anyone because lately it's been causing a lot of headaches with customers having billing issues due to these inconsistencies.
- jeiting 5y ago
  Thanks for the great feedback. These are all legit issues. We have on our roadmap a revisiting of our API this year and I think we need to have a lower tolerance for abstraction leakage. Would you mind dropping me an email jacob@revenuecat.com? I think for our long term viability we need to have the trust of people who care about edge cases like this. I’d love to hear more.

criddell 5y ago

Can you use Stripe in iOS and Android apps? I thought purchases had to go through Apple and Google?

joshstrange 5y ago
You can but only for physical goods or a small handful of other uses (person to person and 1-2 other special carve-outs I can't remember).
cyral 5y ago
Correct, I mean if Stripe developed a wrapper around the native APIs as other companies have done. Payment is still handled natively but Stripe would provide consistent webhooks without having to deal with Apple’s complex receipt API.

joshstrange 5y ago

If it's IAP for digital items then you can't use Stripe for IAP on iOS/Android, it has to go through the respective store's IAP logic.

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 ago
  Ahh, 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!

deleted 5y ago

[deleted]