We (Render) are a featured app in the marketplace [1]; the app lets you run real time queries against your Stripe data in a fully-managed PostgreSQL database that's always in sync. Happy to answer questions about our experience building it!
While the Stripe/Render integration looks interesting for our latest startup, more than anything I just wanted to take a moment and say 'Thank you' for building such a decent product.
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?
In terms of effort, a couple of engineers worked on the app part-time for a few weeks. A Stripe App is the best way to handle permissions on behalf of a user, plus it gives Render more visibility in their marketplace.
Any interesting details on how it’s implemented? If I were guessing, register a stripe webhook. On each webhook, and fetch changed events and turn it into proper sql.
Somewhat unrelated, but I've found it really difficult to stop a recurring payment with Stripe. A company which has shut (website down and email unresponsive) keeps trying to charge 299 bucks on my card via stripe. No way to stop it either, if the client website is down.
Could you email me at [email protected]? Would like to see what's going on here and stop the payments. (We stop recurring payments when a business shuts down their Stripe account.)
What if a business does not shut down their Stripe account?
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)?
iko.ai looks neat! Our developers hang out in Discord (https://stripe.com/go/developer-chat) — this seems like a good question you can chat with them live about.
I had this happen with a fraudulent charge once. To be clear, I don't know that it was a recurring payment with Stripe, but the behavior was similar. It took me about three years and a half dozen new cards to finally kill it.
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.
I am always pleasantly surprise by Stripe's output from Increment to this marketplace. My spouse uses Stripe for two small businesses and we haven't had any issues. I work in ad tech and I point to Stripe's documentation as a great example of clear comms and instructions.
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.
The question is often how closely they let apps compete with them. Ie, can I roll out a (cheaper) invoicing solution with for example a $5/invoice cap. Quickbooks et al do allow this. Some players do not like that.
It's almost like any successful developer needs to develop an app thats popular but not that popular and verging on slightly more difficult so that the moat holder (in this case Stripe) doesn't want to build it themselves. Alternatively make something that catches fire really quickly and sell very quickly before they can build it themself.
Every time I use any of these apps, there is always a nagging sense of instability. I don’t want to base my business transactions that relies on a 3rd party Shopify app that fulfills orders over a fragile API, run by one dude hanging out on the beaches of Bali.
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.
I was in the beta for this and it's been really cool to hack around on this platform. Been working on making a read-write stripe app to connect to an external CRM.
To be honest the only struggle I experienced is that sometimes the console of the browser doesn't return the error and therefore it requires a little digging to figure out what's going on that causes the app to not render.
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.
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.
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!
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.
Thanks for taking a look, I believe I sent you an email about the first one actually since it had been months without any updates. They did get on it and released a fix soon after, but last I heard it was rolled back and then (maybe?) re-applied. Unfortunately it is still happening, but the second issue is much more urgent for us right now.
Ah! Right, yeah that was me kicking it back to the top of the stack. IMO, these core issues are more important than almost anything else we do, but I think we aren't as good as we should be as making sure we are resourcing them over the new and shiny things.
I've made CEO-noise again and hopefully we can keep pushing on these two.
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 :)
It states "Stripe Apps are coming in the next few weeks. Explore the Marketplace, and get notified when an app is available" so maybe it's just how they're gating access.
This is great, congrats on the launch, I love ecosystems! One thing I'd really love to get Stripe's take on is how they are thinking about utility of 3p apps within Stripe. For me, it's much easier to work within the native app than to figure out how to use that same app, with limited functionality, within Stripe.
We do relatively lower volume of higher value ACH transactions (ie, 20K/transaction).
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.
That's really my question - I think there's room for a $5 or $10 invoicing solution (ie, cap invoicing fee at $5 or so). Maybe somewhat simplified. I'd like custom domain as well of course.
Pricing works best when aligning with value instead of costs. In general you should also try to align your pricing with value for better margins (especially if you are have a monopoly condition).
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.
I firmly believe that transaction fees (incl invoices, etc) should be fundamentally a constant flat fee. Whoever builds a competitor to Stripe will blow everyone away.
The cost of transaction is the same. Customers are being robbed in day light with % based transaction fees since the dawn of time.
Transaction costs are not the same price per transaction. The major costs for most transactions are the risks (credit, irr, fx etc) associated with it not the fixed costs of infrastructure.
Those costs go up with the value of the transaction.
No. And you can do pricing that’s flat if you are really good at risk management but note that means the price for smaller transactions begins to subsidize the big ones.
See Atlantic Monthly vs Wise for different pricing types in fx transactions as an example.
Until you want value-based fraud prevention layers like insurance. Keeping fixed fee would knock that out of alignment. But perhaps your point would be that should be some sort of opt-in higher SLA tier so the transaction layer fee is low but the insurance etc. add-on layers are variable.
Sorry, question by someone who is not part of the USA (not even Europe, if it's a common case in Europe too). Why would you have to pay to send an invoice? It isn't just a PDF? Is there an extra mechanism that I am missing?
When people say “invoicing” in this context they generally refer to both the PDF and the transfer of money per the details on that PDF. How that money is transferred will incur different costs.
That's actually not correct. Stripe invoicing charges 0.4 or 0.5% on top of the normal payment transaction fee (for either card payments or bank transfers). Essentially, you are paying a % fee for a nice PDF (plus some reconciliation/reporting etc)
"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."
I was expecting it to come earlier but never disappoint when it finally arrives. This will definitely make the Stripe ecosystem (apps, developers, etc) even stronger.
Surprised they don’t handle App-Billing like Shopify does from a first look at the docs. Is this on the roadmap so that devs can directly charge for their app?
seems like a lot of YC IPO companies are struggling to keep their share prices afloat and this seems like something to send more paying customers to its network of YC backed businesses.
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.
> Lot of the companies featured in the marketplace is what I'm referring...
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?
so its a conspiracy that Docusign is down 80% from ATH as are many YC backed IPO stocks?
Just open up a chart and have a go at the numerous tickers YC is involved with. Are those stocks that you would trust your life savings with and that its a conspiracy that they are struggling with potential problems to capital and liquidity?
If you are going to simp for YC at least have skin in the game
"...this seems like something to send more paying customers to its network of YC backed businesses."
Is a baseless conspiracy. Back it up with facts! If you can, we're all here to listen. Accusing someone of being a simp because they think your argument is baseless and weak is not a great way to strengthen your argument.
I don't know why who or what I simp for is on trial here. You have no idea what I own stock in. Maybe my big simpin' is a perfectly valid repsonse? Simpin' aint easy, that's for sure. For the sake of ending this inane argument, let's say I simp YC supes hard, but it's for personal reasons I'd rather not share.
Now that we have that out of the way, do you have any facts to hold up your baseless claims?
I tough you're referring to their recent outage event (yesterday). Doesn't make sense to have such events at their level. Or is it something fishy there..
[1] https://marketplace.stripe.com/apps/render-sql