How many man-hours did it take to build this app? Does releasing it as an Stripe app instead of hosting it on your own website(using Stripe Connect) reduced technical implementations such as authentication/authorization?
Ripe for failed founders to exploit
My business uses Payment links and a customer asked to cancel their subscription. Of course I canceled it but I stopped to think what would happen if I was hit by a bus. Is there no other option but a chargeback if a subscription does not have a cancel option?
I'm a bit ashamed to say, but I'm having trouble with checking if the customer has a valid subscription. I'm currently only storing the customer_id in the database and retrieving the information from Stripe to have it as a single source of truth and avoiding putting the Stripe info in our database and having to make sure it's synced.
On the other hand, I can't make a request to Stripe with every request, so I'm thinking of memoization or something.
I could find guides on how to accept payments and create subscriptions which are trivial, but no examples on what happens after that.
Suppose I have an API with a single endpoint and set up a subscription for a customer, how do I not hit the Stripe API with every request to check if the subscription is still alive without storing customer info in my database and having to sync it (i.e: keep everything in Stripe)?
At one point I asked the customer rep if there was any way to rid myself of this nuisance other than completely closing my account. She responded with the normal "that's your decision, blah, blah, blah...", but I was legitimately asking, not threatening.
I think I said something like: "No, let me be clear: I don't want to close the account. I just don't want to deal with this every six months either. I'm seriously asking if this is the only other recourse because it seems we've tried everything else."
It did get resolved eventually. It was also for a trivial amount so nothing like what you're looking at. It was still very annoying though.
App marketplaces are great all around. Great for users - more functionality. Great for partners - easy access to distribution/users. Great for the marketplace owner - improve your product, while adding network effects that deepen your moat against competitors.
Some of these may be very stable but this is always on the back of my mind: “Is this going to work in 5 years?”
If you ever want to witness horror, jump over to Shopify forums: Zapier integrations gone wrong, unresponsive APIs, App owners not responding, businesses adding free integration apps that were last updated during the Obama administration, etc.
While Stripe API and their core services are stable, none of this inspires confidence.
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.
- 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.
one invoice per month to paddle and you're good to go
great for small bootstrapped saas
To continue, please accept Stripe Apps terms and conditions for your account. Press Enter to open the browser or visit https://dashboard.stripe.com/apps/accept-terms (^C to quit)
Waiting for confirmation...
After waiting for a few minutes, it terminates with this:
please accept Stripe Apps terms and conditions before proceeding
I've already accepted the terms.
You can follow that issue for updates (hopefully shortly!) and if you have additional details to add, adding them there will get them to the team directly.
Thanks again and sorry for the launch day bumps :)
What's interesting is strip invoicing is pretty uncompetitive here.
Fee for sending one invoice is $100/invoice. For every 100 invoices you are spending $10,000.
OUCH!!!
In other words, if someone was allowed to do an invoicing app in this marketplace it might do ok for a group out there. A target would be folks doing ACH payments (you need to cap per invoice including payment fees at $10 to be competitive here I think).
EDIT: Sorry, corrected to be $100/invoice from $500/invoice which is still much higher than we see elsewhere to send out an invoice.
The rationale is that Stripe believe that a small percentage will align better with customer acceptance of pricing than a flat fee per invoice, which allows them to capture more dollars from the relationship.
There is an additional payments fee that applies.
"Transparent and consistent pricing You must clearly state your app pricing up front, without hidden costs or fees. App pricing must also be consistent with off-marketplace prices."
https://stripe.com/docs/stripe-apps/review-requirements#app-...
Though I suppose Stripe is watching for apps doing things Stripe should/could do itself as a real-time "what would people pay extra for?" list.
ex) Docusign is down by at least 80%
1. Stripe is a private company, it hasn't IPO'd.
2. YC was an early investor in Stripe, but as a late stage company, Stripe has many, many stakeholders that are investors: https://www.crunchbase.com/organization/stripe/company_finan... to think that they're beholden to YC and would make business decisions for the sake of YC companies -- oof.
But I'm sure you been paying attention to the markets....
This isn't actually what you said in your original post, but sure, let's breakdown this too. Under "Featured apps" there's Mailchimp, Dropbox, Google Drive, Bench Accounting, Ramp, and Render. Dropbox is the only one I recognize as a YC company.
I pay attention to a lot of things. What do you pay attention to?