4 ms·

Ok - so asking the inevitable question - what is the one thing Stripe does not provide that you want to build / have someone build for you?

heipei 4y ago
Using Stripe for B2B / Enterprise SaaS subscriptions. A few things that would improve my life, though I suspect Stripe might already working on a few of those: Easy way to create a recurring subscription based on a one-off price, currency and product description (just so this is still recognised as recurring revenue). Recurring subscriptions that automatically pause and remind me 30/60 days before renewal so I can reach out to the customer and get a new purchase order. Customer templates - Many customers purchase through resellers, so having templates for different resellers would accelerate the process to add new customers with the same bill-to but different ship-to. Dashboard with upcoming renewals for annual subscriptions. Saved export settings (columns) for payouts, so I can export these each month for my accountant. Yes, you can do all of those through the API, and I'm sure Stripe will tackle these sooner rather than later, still, just to give you an idea.
cyral 4y ago
I really want a wrapper around the terrible in-app payment APIs of Google and Apple. There are some companies doing this (RevenueCat) but in my experience they are super buggy even to this day, which sorta goes against the entire problem they are trying to solve. The APIs that apple and google provide are a mess and full of weird edge cases and hacks (like polling for changes rather than webhooks), so a wrapper around it with proper webhooks and a well designed API like Stripe’s existing products would be amazing.
- jefago 4y ago
  Hey, RevenueCat Head of Product here. I'm sorry that you have had a bad experience with RevenueCat – we definitely aim to provide just what you outlined. Could you let me know what kinds of bugs you experienced? We're doing our best to abstract those messy APIs, and unfortunately some things are outside our control, but if there are any issues we can fix, we'll do our best to do that!
  - cyral 4y ago
    Hi, I have two tickets open which are really causing a lot of issues for us: - Expiration webhooks are not always sent, so customers keep their entitlement way after they should: Ticket 13919 (although it's been spread across a few as it must close them after a while or something) - A much more urgent issue I opened a couple weeks ago: Customers that cancel and then re-subscribe for a trial at some point in the future have no webhook sent at all. The dashboard says their trial has started, so revenuecat knows the trial exists, but no webhook event is actually sent for it. This is causing a mess of customers who sign up but don't get their entitlements and end up asking for a refund or sending an angry email. Ticket 16016 - I've noticed a bunch of weird bugs, sometimes only affecting one customer so I haven't opened a ticket, but it just makes me question things. For exmaple, we implemented trials in April but our dashboard shows trial signups and conversions from last year. That is not possible, so I question the accuracy of the trial stats as well. Another issue from long ago was that the product_change event on android commonly sends the wrong new product ID, so we just have to ignore it. I was told this is a limitation of the play store though, but it wasn't obvious from the docs back then (not sure if it is fixed now). This makes it difficult to reflect what plan a user switched to within the app, since the product change event can't be trusted. Like most of the issues, the RC dashboard shows it correctly, it is just the webhook that is wrong (which is why I couldn't understand the response that it is a play store bug, when RC shows it right on their end but sends the wrong/old ID in the webhook) Since android downgrades are immediate, the initial_purchase that follows will actually set the correct ID, so that is the workaround for now that I found. (Hopefully I got that right, I'm reading the comments for the workaround we added) I really want to see revenuecat work and succeed, because it is a great idea and for the most part made implementing subscriptions much easier, there are just a lot of edge cases we keep running into. Support is also not the most helpful, but I understand they are probably swamped. The android bug I mentioned above, the solution was to just use the RC api to fetch the status rather than using the webhook. Why would the API return a different ID than the webhook sent 50ms before? I'm not sure why there is such a disconnect between webhooks and what the API/dashboard returns. It would also be great if you could add a dashboard for support tickets rather than having to use email, it would keep things more organized, as I often need to contact support directly because the community tech support forum is a graveyard. I understand technical issues should be directed there, but they often sit for weeks with no response. Even with these issues I'd still recommend RC in general though. If these issues are happening with a company who's purpose is to handle them, I can't imagine how difficult it would be to implement a subscription system from scratch.
markyc 4y ago
merchant of record (like paddle)
- lifeisstillgood 4y ago
  Afaik the merchant of record takes on the full liability, cost of fraud etc. It's pretty rare is it not?
  - markyc 4y ago
    yes, but it's awesome, for 5% you never have to worry about invoicing or vat (especially valuable in EU) one invoice per month to paddle and you're good to go great for small bootstrapped saas

heipei 4y ago

Using Stripe for B2B / Enterprise SaaS subscriptions. A few things that would improve my life, though I suspect Stripe might already working on a few of those: Easy way to create a recurring subscription based on a one-off price, currency and product description (just so this is still recognised as recurring revenue). Recurring subscriptions that automatically pause and remind me 30/60 days before renewal so I can reach out to the customer and get a new purchase order. Customer templates - Many customers purchase through resellers, so having templates for different resellers would accelerate the process to add new customers with the same bill-to but different ship-to. Dashboard with upcoming renewals for annual subscriptions. Saved export settings (columns) for payouts, so I can export these each month for my accountant. Yes, you can do all of those through the API, and I'm sure Stripe will tackle these sooner rather than later, still, just to give you an idea.

cyral 4y ago

I really want a wrapper around the terrible in-app payment APIs of Google and Apple. There are some companies doing this (RevenueCat) but in my experience they are super buggy even to this day, which sorta goes against the entire problem they are trying to solve. The APIs that apple and google provide are a mess and full of weird edge cases and hacks (like polling for changes rather than webhooks), so a wrapper around it with proper webhooks and a well designed API like Stripe’s existing products would be amazing.

jefago 4y ago
Hey, RevenueCat Head of Product here. I'm sorry that you have had a bad experience with RevenueCat – we definitely aim to provide just what you outlined. Could you let me know what kinds of bugs you experienced? We're doing our best to abstract those messy APIs, and unfortunately some things are outside our control, but if there are any issues we can fix, we'll do our best to do that!
- cyral 4y ago
  Hi, I have two tickets open which are really causing a lot of issues for us: - Expiration webhooks are not always sent, so customers keep their entitlement way after they should: Ticket 13919 (although it's been spread across a few as it must close them after a while or something) - A much more urgent issue I opened a couple weeks ago: Customers that cancel and then re-subscribe for a trial at some point in the future have no webhook sent at all. The dashboard says their trial has started, so revenuecat knows the trial exists, but no webhook event is actually sent for it. This is causing a mess of customers who sign up but don't get their entitlements and end up asking for a refund or sending an angry email. Ticket 16016 - I've noticed a bunch of weird bugs, sometimes only affecting one customer so I haven't opened a ticket, but it just makes me question things. For exmaple, we implemented trials in April but our dashboard shows trial signups and conversions from last year. That is not possible, so I question the accuracy of the trial stats as well. Another issue from long ago was that the product_change event on android commonly sends the wrong new product ID, so we just have to ignore it. I was told this is a limitation of the play store though, but it wasn't obvious from the docs back then (not sure if it is fixed now). This makes it difficult to reflect what plan a user switched to within the app, since the product change event can't be trusted. Like most of the issues, the RC dashboard shows it correctly, it is just the webhook that is wrong (which is why I couldn't understand the response that it is a play store bug, when RC shows it right on their end but sends the wrong/old ID in the webhook) Since android downgrades are immediate, the initial_purchase that follows will actually set the correct ID, so that is the workaround for now that I found. (Hopefully I got that right, I'm reading the comments for the workaround we added) I really want to see revenuecat work and succeed, because it is a great idea and for the most part made implementing subscriptions much easier, there are just a lot of edge cases we keep running into. Support is also not the most helpful, but I understand they are probably swamped. The android bug I mentioned above, the solution was to just use the RC api to fetch the status rather than using the webhook. Why would the API return a different ID than the webhook sent 50ms before? I'm not sure why there is such a disconnect between webhooks and what the API/dashboard returns. It would also be great if you could add a dashboard for support tickets rather than having to use email, it would keep things more organized, as I often need to contact support directly because the community tech support forum is a graveyard. I understand technical issues should be directed there, but they often sit for weeks with no response. Even with these issues I'd still recommend RC in general though. If these issues are happening with a company who's purpose is to handle them, I can't imagine how difficult it would be to implement a subscription system from scratch.

markyc 4y ago

merchant of record (like paddle)

lifeisstillgood 4y ago
Afaik the merchant of record takes on the full liability, cost of fraud etc. It's pretty rare is it not?
- markyc 4y ago
  yes, but it's awesome, for 5% you never have to worry about invoicing or vat (especially valuable in EU) one invoice per month to paddle and you're good to go great for small bootstrapped saas