I'm... honestly not sure if this is metaphorical. Did she take you to a cafe and give you literal food, or was she "feeding" you information?
I'm very unhappy with their support, which is automated by bots and I've gone around in circles with such a bot.
Unfortunately their support plans are between a rock and a hard place. It's either:
(1) Free, but garbage. (2) Starting at £1,400 per month.
The reason I chose Azure for my cloud provider was because Microsoft are obsessed with support, and I can get:
Free, £21.62 per month, £74.54 per month, £745.31 per month for different levels of availability, response times, and assistance type.
I wish I could pay Stripe some amount per month to talk to a human who speaks English when I need it.
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.
Overall, terrible experience.
FYI, you need to start including unsubscribe links in your emails to be CAN-SPAM Act compliant.
Hopefully it's not the case here with Stripe (fingers-crossed)
The mailer platform they use for Stripe Capital spam appears to be marketo.org, and those did have an opt out link.
We were using managed accounts for our customers, wrapping Stripe to provide payment accounts to our customers. Stripe was allowing our customers to process refunds on payments even if they had negative balances and had no automated notifications in place to send us notice of these negative balances.
Stripe gave us no notice, and shut down payments for all of our customers and accounts until the balance was cleared. We basically got an email one day saying pay 40k~ and we'll unlock your accounts. This behaviour was going on for about 18 months I think, it wasn't just some issue that came about over 2 weeks. We were running our business in such a way that to us looked profitable and well-ran but Stripe was keeping an internal debit against us which they decided had reached it's cap and email us.
Their thinking was that they didn't have any responsibility to send notifications to us and they also didn't need to restrict refunds, we should do it on our application.. except the information we needed wasn't even available to us.
About 3 months afterwards, their platform magically started doing exactly what we were saying should have been their responsibility from day one. When you hit robotic support people who are reading from a script, your account manager is removed and your business depends on processing payments they really had all the power.
Very unhappy about this and we're still paying off the $40k that they decided to collect overnight from us...
That said, it does sound like we could've handled this better—and we really shouldn't be that abrupt. Could you get in touch with me at firstname.lastname@example.org and I can look into what happened and see what we can improve for future cases?
- "0 day" notice. Boom, account shut down. Don't like it? Well pay clear every single account.
- You let accounts process refunds even with active chargebacks. This isn't a default "sane" position. We had no way of reacting to this.
- The period this went on. From the first negative balance to "Day 0" was well over a year. Not once did you send a notice or friendly email this was happen. It literally went from happy days to business destroying lock outs overnight. We had customers leave us with serious negative balances which we could have possibly collected if they were still customers. Overall we only managed to get about 1k back from our customers.
Only when I realised Stripe was treating funds that were already allocated to an upcoming payout as 'available' or 'cleared' did the penny finally drop. So the refund for $100 would go through, the payout of $200 would then go through and then the customer account would be $100 in the red which would be deducted from our company Stripe account. Now we have learned to count the value of upcoming payouts as unavailable when working out the balance available for refunds.
Luckily for me this didn't happen too many times and I was lucky that my customers were billing enough that the shortfall on their accounts was cleared within a few days/weeks, but I can easily see how this could spiral into a big problem for a startup where customers are not billing so much.
I had to resort to trial and error to find the answers to my questions about Stripe Connect and refund timings as it turns out that Stripe will count a balance as available even if the whole balance is already tied up in a scheduled payout, causing havoc with evaluating whether an account has sufficient balance to make a refund or not.
Took me 18 months to work out as I don't think this is documented anywhere and support were clueless!
I asked a fairly simple question last fall - why Apple Pay showed up in Stripe Checkout for new subscriptions, but not when doing an update.
First answer: "Ask Apple!" (No.)
Second answer: "Apple Pay can't be used for recurring charges." (No.)
Third answer: "We don't support that yet on updates." (Apparently correct, but ugh.)
I tweeted about it and @mentioned Patrick Collison back in May. I was bloody impressed that he replied. I shared my experience w/ him over email. Didn't hear back (didn't expect to) and not sure anything got fixed.
At least they're listening. Stripe was great because it was no-nonsense and heavily focused on a great developer experience. That focus sadly seems like it's in decline.
I bring this up just to make clear that we do care a lot about every single problem like this.
Meant to say that I didn’t get an update on fixes (nor did I expect / need one). Great to hear you’re addressing some of the systemic issues though. Makes me feel good that using Stripe will get back to being a joy to use.
And btw I know you care. The fact that you’re here anytime there’s a Stripe thread and that we engaged on Twitter shows that. The hard part seems to be ensuring others in your org care the way you do as you scale. Happy to see that still is the case at Stripe.
Might not be the most efficient way, but what the heck - you are showing how a CEO is able to deeply care about the company's product and its customers.
This includes immediate callbacks by phone, knowledgeable support on disputes, etc. Each time the support person has been more knowledgeable than I’d expect at a company this size. For more context, in case it matters, we process roughly 200k of through stripe annually.
10/10 service for me.
Disclaimer: former stripe employee, worked directly with said team.
I emailed Stripe and the chat support 10+ times and all I received is 10(!!) days later was a copy paste "sorry can't do anything about that" - referring to the fact that by then the chargeback rate was 10% because of 2....so statistically insignificant... chargebacks. which again, happened much later, after the supposed payout date.
Oh. And to add to it, we requested 10+ days ago for a migration of our data to Braintree / Paypal and they never got back to us. again. it's just a shitshow.
Very sketchy and nonsensical business practices, if you ask me.
if someone from stripe is wiling to actually fix this shitshow (aka perform the migration and payout our money or at least explain why prior to any chargeback the money hasn't been paid out), you can email me at: arturaregnante90 at gmail
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.
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).
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 are SCA compliant... Confusing stuff. Let's just hope we don't have to go through a migration again.
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).
Just a note, one of the things they got right with their API is versioning. Until you decide to upgrade to a newer version of their API, nothing changes for you, and you can test out compatibility in dev/staging by simply specifying a flag on each API call (which is easy to do if they all go thru a central class that handles the Stripe API calls for your app). Their changelog also takes a "from -> to" flag which will show you the exact changes that are between the version you're on and the latest (or any other). All in all, for this specific part of it, I wish more places handled evolving APIs the way Stripe does.
> 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.
Simple and brilliant.
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 :)
They're super beautiful and highly readable, with a unified art style/branding. I'm curious if its something one of their designers cooked up by hand in Illustrator or Figma/Sketch, or if it is some specialized diagramming tool that they use.
(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)
Basically they had funding before the demo day.
Also they stayed in "beta" all the way until Sept/Oct 2011 when they formally launched on Techcrunch. That gave them enough time to hone the basic API, work out a TPPP (Third party payment processor ) deal with Wells Fargo and actually try it out before launching.
Just as an anecdotal data point, this is not actually true in practice, at least not yet for us. We abandoned our considerable efforts to move to Stripe's new API during its catastrophic phase, for reasons I've mentioned in past HN discussions and won't rehash here. The bottom line is that anything that required 3D Secure would presumably now fail for us. However, as a UK business with customers in several other EU member states as well, we have yet to notice any significant failure rate when signing up new customers. This may be because we charge relatively low subscription fees and qualify for one or more of the exemptions most or all of the time. In any case, we keep being told it will change one of these days but so far the sky has not fallen and we're still using Stripe when taking card payments.
However, I use Monzo as my main current account. I would say that around 50% of my online payments send me through 3D secure, which for them involves pressing the approve button on a notification and entering my card PIN.
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.
That's astonishing. Did they ever explain what link in the chain failed?
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.
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.
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.
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?
That said, I do agree you should be able to specify the exact version for a webhook in the Stripe admin UI. But I also wouldn't worry about trying to track the versions too much, Stripe is great in that your integration from 5 years ago will still work just fine today unless you need the newer payment methods.
I believe the logic behind associating the current API version with the endpoint you are adding is that you are adding it now so you should use the current API. Perhaps they should let you choose an older version, but there's always some desire to get people to upgrade to the latest version of things.
Their support and “code of ethics” completely failed me however in a recent startup.
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.
Never have I felt more powerless and betrayed.
With Stripe, the product was built around the API experience, which would engage a new world of users.
It's an important lesson in product management.
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.
1) Their customer service has been good. However, I've never had to use it for anything serious
2) Their API is awesome
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
4) Like many others, not happy that costs are slowly increasing.
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
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
Seems like adding needless risks and complexity
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
and they don't shift over their best people to pie in the sky stuff like Platform of Platforms
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.