Michelle Bu the engineer who wrote this is probably the kindest person I've met in startup. In 2014/15 when I as working on DigitalOcean we decided to switch to Stripe, based in NYC I went to SF to meet the Stripe folks and get to know them a little. They partnered me with Michelle who not only went out of her way to spend an afternoon with me, feeding me lunch, and telling me anything I needed to know about Stripe, but also as a talented engineer; made me feel really confident that moving to Stripe was the right thing to do! Shout out to Michelle.
I'm very happy with Stripe's API; it's one of their best selling points.<p>I'm very unhappy with their support, which is automated by bots and I've gone around in circles with such a bot.<p>Unfortunately their support plans are between a rock and a hard place. It's either[1]:<p>(1) Free, but garbage. (2) Starting at £1,400 per month.<p>The reason I chose Azure for my cloud provider was because Microsoft are obsessed with support, and I can get[2]:<p>Free, £21.62 per month, £74.54 per month, £745.31 per month for different levels of availability, response times, and assistance type.<p>I wish I could pay Stripe some amount per month to talk to a human who speaks English when I need it.<p>Or else, the first competitor to Stripe that offers this and I will jump ship. I already took a look at Paddle, but their approach with customers is equally appalling.<p>[1]: <a href="https://stripe.com/en-gb/support-and-services#compare-plans" rel="nofollow">https://stripe.com/en-gb/support-and-services#compare-plans</a>
[2]: <a href="https://azure.microsoft.com/en-gb/support/plans/" rel="nofollow">https://azure.microsoft.com/en-gb/support/plans/</a>
I guess this article sums up why we've had a rather bad experience with stripe so far: the API constantly changes, and the documentation or even Googling for a solution seems to be more confusing than ever since most articles you'll find are about some older API.<p>It initially took us much more engineering hours to integrate Stripe into our processes then expected. Granted, we do worldwide sales, with multiple tax-flows and we accept multiple payment methods in both euros and USD. This was during the Charges/Sources days.<p>Then this year we had to go through all that again to migrate from the Charges/Sources model to the PaymentIntent model. This was a pain as the popular payment method in our own country was still very much in beta for the PaymentIntent flow. Documentation was all over the place and customer service often did not know answers to implementation questions (though I must say, they always followed up eventually with some good pointers).<p>Now we are receiving scary emails about how much money we'll lose if we are not SCA compliant. But following the link in that email shows we <i>are</i> SCA compliant... Confusing stuff. Let's just hope we don't have to go through a migration again.<p>Disclaimer: I don't have any meaningful experience with other payment providers, so a can't really tell if Stripe is better or worse than others. I guess accepting payments is just really hard if you want to do anything beyond the 'hello world' (which is: credit cards in the US only).
> Close laptops. When working together in the same room, we found the fastest way to be fully present and attentive was to close our computers. When we did, we felt more listened to and could more clearly and easily explain our reasoning to each other.<p>> Pace your questions. Start each session with a set of questions you want to answer. Write down any new questions that arise in a working session for the next session. Try to avoid discussing them in the moment. In the time between sessions, you’ll get some distance from those questions, collect new information, and meditate more on the topic. End each session with clear answers and questions to explore in the next session.<p>Simple and brilliant.
Stripe is my favorite startups ever. I have been following them for sometime now and I have learned lot about APIs and documentation. I have said this earlier and never fail to mention that their API documentation is really really good. Also, their website and product launch pages are just beautiful. Wish I was that talented. My sincere thanks to stripe engineering team, I have learned lot from you.
I can hack some python, but I am not really a SWE. I came up just short in a Stripe interview a couple months ago- the whole thing was really pleasant and I'm going to try again in the spring.<p>I didn't really realize what it meant to build the product around the APIs until I looked at similar companies and their API guides... yikes. Stripe really is in a class of their own :)
I remember /dev/payments back in Summer of 2009 when were were in YC with the Collisons I am curious if any of the APIs are actually 11 years old ;)<p>(that said, I am curious what happened in S09, we wanted /dev/payments badly, but nothing really happened as far as we could tell, and Stripe went through a future YC batch again)
I've used Stripe through three of these APIs (v1, then sources / charges, and now PaymentIntents). Since the Stripe docs began recommending intents, I've used them 2-3 times; I found them to be more complicated (the flow now starts on the server which means exposing more endpoints on my project) and I misunderstood their purpose. I thought they were meant to be more end-user friendly since you have to basically declare on the server what a charge is for prior to taking their payment details. That might have been a foil against "we have your card and can charge any amount we want now!". However, from reading this well-written article, I see that intents were actually the resolution to a crisis of abstractions. Stripe wants payments to feel unified and hence has brainstormed the best model to fit different types of synchronous and asynchronous methods. I'm curious as to what percent of Stripe usage is American credit card charges and subscriptions vs ACH, Bitcoin, OXXO and the rest.
PSA: Be careful with ACH payments on Stripe. We had a customer one time who sent us $20k via ACH via Stripe. The customer insisted they sent the money, but it was nowhere to be found in our Stripe account. It took months to track down the money working with Stripe support (Stripe indeed received it, but failed to actually payout to our account)<p>After that experience, we pull customers out of the Stripe ecosystem as soon as they want to pay by any method other than credit card. Also saves on fees.
Their API is good but I hope they let you configure webhook API versions from their UI or even tie them into the API version used to trigger the webhook because webhooks do not respect the API version you used to call an API endpoint that triggered the webhook at the moment.<p>It will use the API version you defined when you created the webhook endpoint, but the UI to create the webhook endpoint also doesn't let you pick a specific API version. It will use their latest API version.<p>It's really non-intuitive because it means you have to set webhook endpoints using Stripe's API because only then the API version is configurable, but it also makes deploying Stripe API changes kind of complicated because you need to create multiple webhook endpoints in parallel to not throw exceptions due to your code expecting webhooks with different properties based on API differences.<p>I emailed Stripe about this once and support had to forward the request to someone higher up but ultimately my feedback got put into the "Dear valued customer, thanks for the feedback" bucket which means nothing will probably come of it.<p>I wish I knew the technical details on why webhooks aren't sent using the same API version that was used to call the API endpoint that triggered it. Stripe engineers are a lot smarter than me and I can't imagine they didn't think of this already. Is there a technical limitation or downside to this strategy?
I really liked Stripe until recently.<p>Their support and “code of ethics” completely failed me however in a recent startup.<p>A cofounder was able to remove me from our Stripe account, and despite having another account linked to nearly 10 sub-accounts (for different businesses/clients), support essentially completely ignored me. I sent all documentation you can imagine, including legal documents showing my ownership in the business, all to no avail.<p>Never have I felt more powerless and betrayed.
Previous APIs were an afterthought of the business process. Developers weren't first class citizens in the process.<p>With Stripe, the product was built around the API experience, which would engage a new world of users.<p>It's an important lesson in product management.
I generally like Stripe's API, and this blog post gives me some hope, but the complexity of their system and documentation has definitely been growing a lot more than I'd like. These days, I end up attaching `expand` to most API requests, because they've become addicted to overly nested data structures. And for some reason you have to include array brackets within the parameter name, so really it's `expand[]`, which is awkward in many contexts. The length of property names has gone up significantly and now often use multiple words separated by underscores, e.g. `statement_descriptor_suffix`, which is also awkward, especially in JavaScript. The docs still mention Sources and Tokens in many cases, without a clear translation to Payment Methods and usually without even mentioning that those concepts are deprecated or outdated.<p>Tangential to that, while the post seems to hint at trying to make a unified and cohesive experience, I can only see that happening for simple one-time payments. Subscriptions and Connect still seem like an afterthought. For the longest time, you could do destination charges for one-time payments but not subscriptions. Additionally, when using subscriptions with Connect, you have to specify the application fee as a percentage, which is painful for us because we want to charge a flat rate, so we have to fudge it with some math using hardcoded values to properly take into account coupons and Stripe's fees and we end up having to round to the nearest penny. It's just an unnecessarily messy headache. One-time payments are pretty easy with Stripe, the rest seems bolted on.
Very happy with Stripe. A customer for 3.7 years now<p>1) Their customer service has been good. However, I've never had to use it for anything serious<p>2) Their API is awesome<p>3) Their level of complexity is slowly increasing. This is something very dangerous for them and they need to look into it. Their biggest advantage is/was - super simple to set up everything<p>4) Like many others, not happy that costs are slowly increasing.<p>5) Perhaps I'm the only person who falls into the camp that Stripe doing things like Atlas and Stripe Capital is somewhat unnecessary and takes away from their focus on Payments<p>6) Don't really understand why they are doing the whole Platform of Platforms thing i.e. Stripe customers can now offer stuff like Bank Accounts to their customers<p>Seems like adding needless risks and complexity<p>7) Anyways, I miss having Stripe be really simple and really focused on one thing. Hope they can at least be like Apple and Microsoft where they keep laser sharp focus on their money makers/core competencies and have dedicated teams and the best people on it<p>and they don't shift over their best people to pie in the sky stuff like Platform of Platforms
Does anybody know if Stripe uses some specific tool to draw their diagrams, like those on this blog? They're very well made and the branding is consistent and beautiful. I'd be curious if it was something one of their designers does by hand, or if they have some tool that allows them to create their (block) diagrams with such unified branding.
Is Stripe planning to support additional crypto currencies like ETH, Nano, Monero etc in addition to Bitcoin?<p>It seems like the same user initiated payment flow and merchant to validate receipt in their blockchain account would apply to other cryto currency payment methods as well.