Stripe’s payments APIs: the first ten years(stripe.com)
stripe.com
Stripe’s payments APIs: the first ten years
https://stripe.com/blog/payment-api-design
78 コメント
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.
Michelle is shockingly kind and has shaped Stripe's culture very considerably in this and other regards.
Agreed! When I worked at Stripe, Michelle was my "spin-up buddy", and getting the chance to work with her was one of the highlights of my time at the company. Strong second that she is extremely kind and embodies the best of Stripe's culture.
an afternoon with me feeding me
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... 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?
Not the OP, but I visited the Stripe HQ back when they were around 50 people and they had a full time chef on staff. I spent an afternoon with them, which included a free lunch.
[deleted]
I'm very happy with Stripe's API; it's one of their best selling points.
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]:
(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[2]:
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.
[1]: https://stripe.com/en-gb/support-and-services#compare-plans [2]: https://azure.microsoft.com/en-gb/support/plans/
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]:
(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[2]:
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.
[1]: https://stripe.com/en-gb/support-and-services#compare-plans [2]: https://azure.microsoft.com/en-gb/support/plans/
Edwin from Stripe here. I'm sorry this happened. We have one bot/automated reponse, which is our first reply to say, "we've received your message and we'll get back to you soon." Beyond that, every interaction with Stripe Support is with a human. We've invested quite a lot in support this year—the team itself is larger, and each week, we now survey tens of thousands of Stripe users who've talked with our support team recently, and 4/5 say they're satisified. But it sounds like we've dropped the ball in your case, and I'd love to learn why. Would you be able to forward those emails to me at [email protected]? (And if anyone else reading this had a similar time with us, please email me. I'd really like to help dig into each one and see what went wrong.)
I went around and around with support to get opted out of Stripe Capital spam emails (they claimed to opt me out, but I kept receiving emails about Stripe Capital), and in the process they broke my notification preferences causing me to get a daily batch email. When asked to undo the damage support referred me to a beta setting in the Stripe website IIRC.
Overall, terrible experience.
FYI, you need to start including unsubscribe links in your emails to be CAN-SPAM Act compliant.
Overall, terrible experience.
FYI, you need to start including unsubscribe links in your emails to be CAN-SPAM Act compliant.
The errors I've seen with some startups is that they rely on the unsubscribe mechanism of the mail sending platform, but then they use their customer-base emails across multiple mail sending platforms (and obviously people unsubscribe from one but they remain subscribed on the others).
Hopefully it's not the case here with Stripe (fingers-crossed)
Hopefully it's not the case here with Stripe (fingers-crossed)
I’ve seen this go badly in the other direction too. Customer unsubscribes from a marketing email, but then is unsubscribed across the whole mail sending platform causing them to not receive critical updates about their account. I sadly believe that email notifications are a part of UX that is often forgotten yet always creates so much friction when done poorly.
Their regular platform notification emails titled "Your funds are on the way!" include no opt-out link, these were sent via Amazon SES.
The mailer platform they use for Stripe Capital spam appears to be marketo.org, and those did have an opt out link.
The mailer platform they use for Stripe Capital spam appears to be marketo.org, and those did have an opt out link.
[deleted]
Another data point. I have not used phone support, but been a customer since 2013 and have used the live chat quite a bit. It has always been extremely good. Never gone around with a bot. Last chat was maybe 1 month ago.
Recently I’ve had nothing but bad experiences with Stripe live chat.
Several times agents didn’t understand English well enough to process the specifics of my issue, so they gave canned generic replies.
Other times they weren’t familiar with Stripe’s own UI (I’m not talking some little-known API- I’m saying the Stripe Checkout config Dashboard).
I learned to stop wasting time hoping to get a live chat agent who works at Stripe (rather than what appears to be an outsourced VA engaged for quick replies on live chat in my timezone), and instead ask questions on Stripe’s IRC support channel.
Would you be able to send the chat (or the email address on your Stripe account) to me at [email protected]? Stripe live chat should be better than that—I'm sorry.
Same, I've used both phone and chat many times and every time it's been a wonderful experience.
If Patrick reads this, their support had us going around in circles. We originally had an account manager, then we got a new one, then we got told we're not having an account manager and ended up getting a different person for the same expensive issue...
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...
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...
Running this type of custom platfom with managed accounts for your users isn't a light responsibilty—if those users start going into the negative, you'll have to communicate with them to prevent that. (We have the `balance_retrieve` API call designed for this purpose.) Please don't take this as some sort of shunning of responsibilities on our part—managed accounts were designed like this so Stripe doesn't have a direct relationship with your customer (they may not even know Stripe exists!). But like you said, it allows you to wrap Stripe for payments, so you can own this relationship and the health of their account. For _standard_ accounts with Stripe Connect, Stripe would own this and we'd send notifications warning of negative balances. We have a guide on how this works: https://stripe.com/docs/connect/account-balances.
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 [email protected] and I can look into what happened and see what we can improve for future cases?
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 [email protected] and I can look into what happened and see what we can improve for future cases?
I'm still emotionally invested in how angry this episode got me because we ended up needing to downsize because of it and it wasn't like we were printing money from the decision to use managed accounts and we absolutely didn't budget for an overnight 40k expense. We understood the liability issues, that's why ultimately we had no leg to stand on, but the crux of how poorly Stripe handled this was:
- "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.
- "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.
I think this is a real issue as I suffered from a very similar issue with Stripe Connect (see my post below) yet support seemed oblivious that you could fall into this trap. In my case, refunds were going through even when we were checking the available balance was greater than the refund amount on our server before permitting the refund request to be sent to Stripe. I do understand and agree with Edwin that a Stripe Connect custom account is responsible for its users but it just feels a bit un-Stripe that it's really not clear how to handle refunds and what the edge cases are.
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.
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.
[deleted]
I've had this too. I'm pretty sure they've outsourced their support (or at least moved it overseas). You ask them simple questions and you get an answer which completely misses the question.
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 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've had a similar experience.
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 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.)
@tebbers and @ceejayoz — I couldn't immediately find either of these exchanges on the Stripe side, but I'd like to see how we can fix this. Could you forward those emails to me at [email protected]?
Done, thanks.
Been a user of Stripe's since when it was called /dev/payments. I've also had two terrible experiences with Stripe's developer support (and my co-founder has has one of his own).
I tweeted about it and @mentioned Patrick Collison back in May[1]. I was bloody impressed that he replied[2]. 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.
1- https://twitter.com/kareem/status/1243540147775451136
2- https://dl.dropboxusercontent.com/s%2Fjvjl1m808lx8a8t%2FPatr...
I tweeted about it and @mentioned Patrick Collison back in May[1]. I was bloody impressed that he replied[2]. 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.
1- https://twitter.com/kareem/status/1243540147775451136
2- https://dl.dropboxusercontent.com/s%2Fjvjl1m808lx8a8t%2FPatr...
Hey, we did reply! (We investigated the issue, ensured your problem got fixed, and started some systemic work to solve the broader category of issues here.)
I bring this up just to make clear that we do care a lot about every single problem like this.
I bring this up just to make clear that we do care a lot about every single problem like this.
Apologies - after revisiting the email thread you did indeed reply saying you’d take a look. My bad!
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.
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.
Every CEO out there should learn from this - the Twitter interaction, your email follow up, and your response here.
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.
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.
Adding another datapoint on this: I’ve been a Stripe customer for 5-6 years and have received outstanding customer service.
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.
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.
Ive been very happy with Dwolla and their level of support is wonderful. Our small team gets a slack channel with our rep and a few others and they respond quickly.
Extremely unhappy too with Stripe's support. Patrick Collison never answered my emails (not that I expected to). They disabled and re-enabled our Stripe account multiple times thinking it was a forbidden business. With another company we received 2 chargebacks out of 20 transactions and balance ($6K+) has been blocked for 90 days. Not to mention that the chargebacks arrived much later, and the reason it has not been paid out early (weeks earlier) prior to the chargebacks (weekly schedule) was because of an unknown bug or something. Basically the payout date moved to the next day every single day the payout was supposed to happen. or so it seems, who knows! no emails, no nothing. Stripe's support that bad.
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
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
[deleted]
You should check out Finix
[deleted]
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.
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).
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).
> 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.
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.
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.
agree on that. I haven't changed my stripe api calls in about 3 years, and everything is still working.
> 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.
> 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.
> 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.
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.
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 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 :)
was the interview similar to how its documented on their website?
Seconded! I would love to hear about the Stripe interview process from someone who came up just short but had a good experience - I've not seen many accounts like that for any company.
Stripe's culture of writing well is really quite impressive. Everything they publish (in my opinion) is top notch and super readable.
Do you know what software/tools they use to draw their diagrams in this blog?
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.
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.
I've used Whimsical a ton in the past year and it's magical software.
Ah, thank you!
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 ;)
(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)
(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)
AFAIK Stripe (/dev/payments back then ) never demo'd on the demo day of either S09 or S10. YC had/has a deal with Sequoia that Sequoia gets first dibs on the companies in each batch before demo day. Stripe presented to a bunch of VCs but got picked up before the demo day.
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.
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.
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.
Considering that every online card transaction within Europe now requires the more complicated payment intents model (because of the SCA, Strong Customer Authentication, requirements) I would imagine that it's a fairly significant percentage.
Considering that every online card transaction within Europe now requires the more complicated payment intents model (because of the SCA, Strong Customer Authentication, requirements) I would imagine that it's a fairly significant percentage.
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.
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.
I presume its down to the bank. Most of them likely choose to avoid it if possible as it's a barrier to people using their card.
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.
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.
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)
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.
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.
Isn’t this all the more reason to use it for those who need automated ACH? I’d assume they fixed the bug. It seems counterintuitive but like AWS, Stripe is anti fragile. Each problem makes the system better the next day, and so more worthy of continued use.
> Stripe indeed received it, but failed to actually payout to our account
That's astonishing. Did they ever explain what link in the chain failed?
That's astonishing. Did they ever explain what link in the chain failed?
Hi cj, thanks for sharing this. I think one of my colleagues already reached out, but just in case I wanted to stop by and make sure everything is getting resolved here. Additionally, we have a totally new ACH credit transfer product in beta right now that's built on our new Payment Intents API. If you (or anyone else) would like to try it out, we think all the improvements we've made will help eliminate all the headaches the old implementation may have caused. Please reach out to me at gideon+hn @ stripe.com (+hn adds a tag and helps avoid the spam filter) and I'd love to continue the conversation.
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.
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?
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?
You can have multiple clients at different API versions interacting with Stripe, with a single webhook in your service to receive the callback. Even if you had a single integration, you cannot usually guarantee an atomic switch to the newer API version across all servers, so you either have separate versioned endpoints or your webhook endpoint has to deal with multiple versions.
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.
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.
The simplest answer is probably that events aren't really generated in a one-to-one relationship with API calls, so it's very non obvious at that point what behavior you would expect.
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.
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.
I really liked Stripe until recently.
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.
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.
Previous APIs were an afterthought of the business process. Developers weren't first class citizens in the process.
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.
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.
Stripe's beautiful API design and documentation, along with their highly reliable service have had a profound impact on my life :)
It's quite insane how well Stripe executes their strategies. Their API docs set examples to all the other startups.
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.
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.
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
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
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
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?
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.
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.
They no longer support Bitcoin. See: https://stripe.com/blog/ending-bitcoin-support
[deleted]
No complaints about the product, but not happy with Stripe's ever increasing transaction cost.