Thanks to everyone here who took a chance on us in the beginning and shared helpful feedback over the years! How to serve startups/developers more effectively at scale is still the main thrust of our product focus. We've fixed and improved a lot of things since we launched here in 2011, but we also still have a lot of work to do. (Both "obvious things we want to fix" and "new functionality we want to build".) I always appreciate hearing from HN users (even if I don't always have time to respond): patrick@stripe.com.
For anyone thinking about what they should work on: I started building developer tools when I was 15 and "tools for creation" is still, IMO, one of the most interesting areas to work in.
> I thank you all at Stripe for setting an example of what real API/SDK documentation is.
It's not just their documentation, Stripe's versioning, backwards compatibility support, and fast improvements probably make it the single best API I've ever worked with.
I have new projects that use the latest and greatest Stripe API and features, but also older projects that use their 5 year old APIs, and both work without a hitch.
> It's not just their documentation, Stripe's versioning, backwards compatibility support, and fast improvements probably make it the single best API I've ever worked with.
I completely agree - I consider Stripe the gold standard for an API. Best I've ever used.
Its the basis upon which I form my opinion as to what "good docs" look like. It makes you incredibly spoiled when trying to use some of Stripe's competitors.
I've integrated 8+ payments APIs over my career. IMO, Stripe's "secret sauce" is the quality of the API and the documentation. It's so compelling that I repeatedly choose Stripe over other payments systems that offer network effects like PayPal and Amazon.
I sometimes get asked by customers if we take PayPal. I tell them truthfully "no, it's just too much trouble".
It doesn't seem like "better developer experience" is much of a moat, but based on how bad the competition is - year after year - it sure seems to be. I wonder what other services could be "disrupted" the same way.
> I repeatedly choose Stripe over other payments systems that offer network effects like PayPal and Amazon.
For one of the first SaSS products I ever worked on, I (naively) chose Amazon payments. Within six months, Amazon introduced backwards incompatible changes. Six months later, they did it again. For another project I started 5 years ago, I used Stripe. We're still using the same 5 year old API and it works perfectly, even though Stripe has added new features and bells and whistles in their newer versions. Their commitment to backwards compatibility is probably the best I've seen of any fast moving API.
And thank you also for your CTFs. I almost finished CTF 2 (I had the 3/4 of last password) and I learned a lot during this CTF. I am very proud of my T-Shirt.
Wanted to hop in and say thank you for starting Stripe. At my first startup, we had to integrate with an old merchant processor for payments and it was a nightmare. With my current startup, we were able to setup Stripe in the first week of operations and take payments seamlessly without too much hassle. Freeing us up from thinking about how to take payments allows us to focus on our product and building out our company. I'd imagine this is a similar story for thousands of other startups too. Hats off to you, your brother, and all the Stripes.
Stripe has a slick API, but their banned merchant categories (anything telecom or networking related) have caused trouble for many potential clients, esp. as Ubiquiti integrated them as their first payment processor.
The distinction between high risk consumer sales & B2B low risk sales is not drawn by Stripe.
Most of those categories are from financial institutions or card networks. Stripe has been working with them so we can support more businesses, and I know of quite a few networking equipment businesses that run on Stripe today. If you're still seeing any trouble, we'd love to take another look—our support team's at support@stripe.com (and my email's edwin@stripe.com).
Support told me that our business could not continue to use Stripe 2 years ago, we've been with Payment.ninja since (and pay a little under half what we used to pay Stripe).
I took what Stripe Support told us very literally, and we ceased using DigitalOcean and one other service since their only recurring billing options were Stripe.
We don't want to break Stripes ToS or do wrong by our clients, hence our contract-less, B2B only, monthly prepaid business model. Apparently this is too high risk for your company?
I'm 90% certain Stripe has had a few fly by night calling card companies sign up with them, and gotten burned when the calling card company gets a ton of chargebacks for not delivering everything promised.
Thus, a blanket ban on Telecom and anything vaugely related (like ISPs). Certain flagship clients like Twilio get a pass, but smaller players like SignalWire, Telnyx, Teli, etc do not.
The Ubiqiti forums are also littered with ISPs that signed up with Stripe (since Ubiquiti integrates with them) used it for a few months w/o chargebacks or any fraud, but got an email one day saying they were not allowed to use Stripe. Appeals are consistently rejected or go unreplied to.
I emailed Edwin at Stripe 4hrs ago, have not heard back from him.
That's true that ISPs and WISPs can't really use Stripe (many use Adyen), but pure-VOIP companies offering hosted PBX and such are welcome at Stripe based on feedback I received from several people who work at Stripe.
When I asked Stripe Support about servicing VoIP companies last year they referred me to the prohibited businesses section and said:
"Historically we have seen that the telecommunications industry is one with too high of a likelihood of customer chargebacks. These need not necessarily be chargebacks in fact; the likelihood of potential chargebacks is also a deciding factor in our deliberations."
> Thanks to everyone here who took a chance on us in the beginning ...
Stripe is one of the few successful silicon valley companies that provided a service of real value, with enormous efficiency gains, upfront pricing, and don't screw over people as part of their business model. They may have "disrupted" the online payments market in SV parlance, but they didn't actually disrupt anything, they found a nascent but fast-growing market (online payments), and built a product targeted just for it.
Mastercard and Visa are each worth 10X as much as Stripe. Stripe is one of the few unicorn companies that's probably under-hyped.
Developers rightly praise Stripe's API documentation, but their approach to versioning and backwards compatibility is a gold standard that is not sung enough. What other fast-moving startup that constantly tweaks and changes their APIs also provide backwards compatibility with their earliest versions?
Stripe understands that handling payments is critical, scary, and hard to get right. When a company builds a payment solution that works, there is strong resistance to mess with it. The fact that Stripe is so backwards compatible means that they do not have to.
I’m going to ask a favor on behalf of a multi billion dollar industry: please figure out how to service cannabis companies.
I build cannabis tech.
Its reall stressful when doing over $1 million in sales in a month and it’s literally all freaking cash and we have to spend hours even with a counting machine counting $20 bills.
Please tell me what your plan is to support legal cannabis.
Take for example all thecredit unions in OR, CO, CA
Like north bay credit union in santa rosa.... their requirwments list for opening an account is RIDICULOUS!!
Other companies want either 3% of your deposits or $3,000 a month for a checking account whichever is higher.
Other banks AND companies will cancel your account if you even have the word “canna” in your name.
Ive literally sat there looking at $160,000 in cash with bills needed to be paid and no way to pay the bills...
You know how fun it is to go to seven different post offices with four employees in tow to buy as many money orders as you can so you can pay bills, such as a $25,000 software bill?
Congratulations! Stripe has consistently made my life as a developer and entrepreneur significantly easier. I still remember that feeling of relief some 5-6 years ago thinking, "Yes! I don't have to use PayPal's API!"
I use paypal because their arbitration (buyer protection) has worked very well for me as a buyer when a vendor tries to screw me over (which does happen from time to time). I do otherwise prefer stripe. I've always hyped it to my friends as a well made and reliable service.
The vendor experience with PayPal is appalling though. They'll randomly take money back off you when a customer hasn't even complained, frequently they'll just freeze you out of your account for months at a time. Better not rely on that seasonal income, half the time it'll be delayed by three months ...
I built opalang.org many years ago - introducing a mix of functional programming, strong static typing for the web, fixing the independence mismatch between client/server/db etc. in 2009, and although we were not able to make it a big success, I'm still spending all my time in this area and am convinced that there is a lot to fix.
Please can you make your update PIN flow a bit different to your view PIN flow ta? If you are developing an app it's nice to be able to confirm that someone has got their OTC correct before they move to setting their PIN - so perhaps give us an ephemeral key for updating PIN we can use to do this as opposed to it being a one step process
Thanks for all that you, John and Stripe have done for startups. Question for you, how will you continue to remain focused on helping startups if/when you go public and have shareholders to appease?
Hi Pat. Do you have archives of the original /dev/payments around anywhere? The internet doesn't seem to have any and it would be great to see what Stripe version 0 looked like.
Before stripe, I used paypal and it was sooo painful! There are so many terrible APIs out there that waste so much time needlessly.
Then I found stripe. What a treat. Everything was documented and the documentation itself was both readable and didn't go in endless circles like the paypal ones. The error messages were helpful. And every api endpoint had an example, which is hugely helpful: HUGELY! All the other API developers out there can learn from this: you can't underestimate the value of having a working example. Not only that but the testing is much easier in stripe, and there's no need for a bunch of seperate accounts and sandboxes that don't make sense.
Oh and did I mention that the variables describe themselves: the first 3 or 4 letter of an ID says what it is (subscription or etc). Genius! It's little things like this which make Stripe stand out orders of magnitude above the rest of all the APIs in the world.
I hope you guys rule the marketplace for payment processing and wish you all the success you deserve.
Stripe's success in payment processing sends a clear signal to the Paypals and API developers of world: If you're producing an API that sucks, it creates an opportunity for someone else to come eat your lunch. :)
Paypal also came out and said they will no longer refund seller fees when a customer is refunded. Before, they used to just keep the $0.30, but now they will keep the 2.9% as well. More the reason to switch to a new processor like Stripe.
> More the reason to switch to a new processor like Stripe.
For a lot of merchants it's not a matter of switching to Stripe.
It's using Stripe but also including PayPal as an option because a huge percentage of buyers want to use it to pay for things -- especially 1 time purchases of digital goods.
About 40% of my course sales are through PayPal.
By the way if anyone reading is curious, that new PayPal refund policy goes into effect October 11th 2019 (you probably got the User Agreement email to notify you of this too if you're a merchant).
> Stripe supports the ability to refund charges made to your account, either in whole or in part. If the original charge underwent currency conversion, the refunded amount is converted back using the same process. There are no fees to refund a charge, but the fees from the original charge are not returned.
I definitely consider stripe to be the canonical example when it comes to both API and documentation design. Really an excellent benchmark and point of reference for anyone who's making a published API.
> Before stripe, I used paypal and it was sooo painful!
Almost no matter what Stripe does from here, that they disrupted the PayPal monster (and the rest), will always reserve them a place in my developer heart. It really was an atrocious experience; there's pre-Stripe and post-Stripe.
I remember when we launched our Japanese tea service [1]: we wanted to switch to Stripe so badly that I was emailing them at the very least once a month, until we made it in their beta program. I'm not sure the youngest remember what the payment landscape was before Stripe, but it wasn't great. Stripe lifted the whole industry up from mediocrity.
Around 10 years ago I had the pleasure of setting up payments with a French bank: instead of a web API we had to use an opaque binary installed on our server. In terms of setup it took many weeks and several in person meetings to get approved. There was a (big) setup fee and a (not so small) monthly subscription. And then of course transaction fees.
In Japan for startups targeting foreignland it was even worse: only PayPal supported payments in anything other than JPY! [2] Interestingly it seems that with Stripe Japan everything coming from outside of Japan goes through USD. I have many customers being charged in EUR, and on our end we of course get JPY. So I would expect an EUR/JPY transaction to occur in the middle, yet oftentimes the USD/EUR exchange rates ends up leaking on our customer receipts... I wonder how it works behind the scene...
[2] Maybe banks were offering this service directly, but for what was only an experiment at the time, I was expecting the setup cost to be prohibitive (at least in time, if not in money).
> I have many customers being charged in EUR, and on our end we of course get JPY.
We charge in USD, we pay for services in USD, but with Stripe we can get payouts only in our local currency. This leads to us losing twice on pointless currency conversions to the tune of 10-15% of the volume. It's been an ongoing headache for several years now and the only response from Stripe to all our asking to fix this has been that "it will be passed to the respective team."
“Wasn’t great” is an understatement! I dealt with it as a developer both in New Zealand and the Uk and it was outright terrible. Oh, you didn’t apply for a merchant account 6 weeks ago...yeah, you’re not gonna go live this month. You just go right ahead and book in a meeting with you bank manager and get down on your knees to plea for an account.
But I thought I would just set up stripe here in NZ just now and it was... wonderful! I just needed to offer business info and it's ... done? There is nothing else to worry about?
The rates themselves show on your receipts? Are you using some sort of plug-in? Could you forward me a receipt at edwin@stripe.com?
For the conversion itself, we automatically convert from whatever currency you've accepted the payment in, then send it to your JPY bank account. The conversion rate is the average of whatever people are buying and selling the currency at that hour, but some financial institutions add a small markup on top of that along the way.
The rates were not showing on our receipts. They were showing on the bank statements of our customers. They were charged an extra 2 EUR by their banks as a FOREX fee on the Tomotcha payment, on a line showing the USD/EUR forex rate, despite us charging in EUR. Very weird. That issue was only ever reported by two customers in France.
This is on top of my head, but I will forward you the relevant and exact information.
My guess is that Stripe has a service internally which predicts "how much of each currency am I going to have, and how much of each currency do I need to pay out at the end of the day?" Then, they balance whatever currencies they can internally, and for the rest, convert to USD, before paying out to customers.
The reason here is because Stripe wants to mitigate exposure to non-USD price fluctuation, e.g. if EUR dives against the dollar. Many companies do (or should do) some version of this rebalancing, e.g. FB cited on an earnings call last year that they lost a large amount due to forex fluctuations.
You know you have a killer product when your customers will literally fly half way around the world just to use it.
When I started my company (since acquired) in 2012, Stripe was so game changing I flew from Australia to the US to open a bank account so we could use it. While we could incorporate in the US online, we had to turn up in person at a bank to open an account.
The only alternatives in Australia at the time were PayPal, which had outrageous fees and a terrible experience for recurring SaaS billing, or a merchant account with a bank which was going to require a $30k deposit.
It cost me $750 to incorporate a US entity, $1250 for airfares and hotel (oh to remember SF was that affordable!!). I stayed at Hotel Whitcomb, which conveniently has a Chase branch right next door, and 1 day later we had a US bank account and could turn on our Stripe integration. We didn’t look back.
I love Stripe Atlas, because I intimately relate to the problem, and wish we had it in 2012.
Ha! Glad you were able to find a way. We still think it could be easier, even with Atlas and Australia support now. Would you be up to chat more? edwin@stripe.com
Chase! It must have been a while ago, because today Chase blocks your account at the mere whiff of anything non-standard going on. And I do mean "anything", being out of the country definitely qualifies. They also shoot first and ask questions later, so your wire transfers will get cancelled or your entire account blocked with incoming transfers bouncing (what is amazing is that the amount that bounces is less $50 that they take for the bouncing service, fun!).
My last wire transfer was "cancelled" by their anti-fraud people, and after calling them and identifying myself extensively, I was told that I am to show up at my local branch with two forms of ID. Yes, the same two forms of ID that they've already seen. Kind of difficult if you are out of the country.
Stripe has made transactions for my SaaS business so painless. I recently learned that I have customers with different currencies and it's not even something I had to consider or account for. Yeah their API is a little bit... bloated for simple needs since they're covering for many different use-cases, but their superb documentation, clean dashboard UX, and relatively low fees really make the value offering huge.
Overall I'm really not surprised at the valuation. Stripe is one of the best products/services out there.
Please also make using Elements with Stripe.js v3 fully optional.
We finished migrating to SCA-enabled payment flow not few days ago. Apparently, you can't create a PaymentMethod instance without using Elements and we don't have the time (nor do we see any practical need) to redo the frontend with them. So the end result is a Frankestein-style frontend that uses the v3, but with a fair share of v2 methods, because it's the only way to retain all the functionality we had prior to the migration (e.g. saving the card info for future use). This was a bit of nasty surprise to be honest. Migrating to the v3 basically breaks existing systems in a non-trivial and expensive to fix way... and the migration is mandatory because of SCA.
According to [1] it is required and there's no other (documented) way to do it.
Ditto for stripe.createToken() [2].
In fact, there's no word in the docs on how to feed raw card data into the v3 at all.
So we had no choice but to use Stripe.card.createToken() from the v2, but then also use stripe.handleCardAction() from the v3 for confirmation... it's a mess. What did we miss?
beware of PCI compliance requirements [0] but you can either create a payment method explicitly [1] or include the card details when handling a card payment [2] `{payment_method_data: {card: {…}}}`
I am aware of [0], but unless I'm missing something neither of the methods allows creating a payment method on the client and then passing its ID to our backend to be executed and set up for 'future use'.
That's the flow we had with the v2 and that's what we can't replicate with the v3.
We do want to optimize for those simple needs. Which parts do you think are bloated? Would love to hear how we can de-bloat. (Feel free to email me at edwin@stripe.com too.)
Not OP but I've used the Stripe API extensively (I know it nearly end to end due to implementing one of the framework client libraries) and to me the parts that come to mind if I think "bloat"/"unintuitive" are SKUs, Coupons, and most likely what GP is talking about the new payment intent APIs, even though I don't think there's a real way you could implement them any better given the PSD2 requirements.
By far Stripe has the cleanest experience of all. I wish you'd treat your APIs more like amazon treats theirs though, that is to say: no private internal-only APIs; I should be able to reimplement the Stripe Dashboard in my own app if I so wanted (just like how the AWS console only uses public APIs). That'd also make for some cool potential projects like a Terraform plugin for Stripe.
Feel free to reach out if you like, email on my profile.
> ... most likely what GP is talking about the new payment intent APIs, even though I don't think there's a real way you could implement them any better given the PSD2 requirements.
Yes, definitely this.
Payment intents is so much more complicated and convoluted than the previous "Charges" API. Stripe went from one of the easiest bits of my app to develop to one of the most difficult, to the point where I'll admit it even temporarily killed my motivation to work on my app solely due to Stripe's API. I stopped working on the checkout process just to take a break and work on other parts of the app and it pains me to think about even touching the checkout flow again even though I know I have to in order to release my app.
For any real app that's beyond the most trivial case you're likely going to be stuck using the "manual" payment intents workflow. Just figuring out which method to use was a huge ramp up of difficulty vs the old Charges API.
I went as far as even emailing their support for advice and even they weren't able to give me a straight answer. Their primary advice was to recommend not using it and instead use their new Stripe-hosted checkout system (which will not work for most people since it's so limited) or continue using the old Charges API and lose out on payments due to authorization issues that will come with not being able to deal with the new user verification strategies that are required by some banks and cards.
Like you I have no idea how to implement it any better, it's just the reality of the situation of the world we live in today but the bar has certainly been raised to consider accepting payments with Stripe now.
Upvotes don’t show on HN, so let me first say this is very much like our recent experience.
If those from Stripe who are reading this would like a hopefully constructive suggestion, may I suggest here the same thing I suggested to your support team?
Right on the front page of your documentation site (https://stripe.com/docs) you have a step-by-step walkthrough for setting up a basic subscription the old way.
If you follow through that process using one of the test cards for the new SCA behaviour (4000002500003155, say) you will see that the API effectively fails at a couple of points along the way.
Presumably either integrations need to do something extra at those points to take into account what needs to happen for SCA, or integrations need to follow different steps in the first place so they don’t run into those problems.
Either way, an equivalent step-by-step walkthrough showing how to use Stripe.js, the API and webhooks to set up a simple subscription in an SCA-compatible way would have been very helpful.
Yep, I came across the Payment Intents stuff - holy crap, it's complicated, and the documentation actually isn't great - it's good for details of API calls and such, but not for explaining what the hell you actually need to do, and why.
I also upgraded our Stripe API version recently, as a result of the new SCA regs - the whole experience was really frustrating! It felt like it should have taken me 4 hours max (test time inclusive), but it ended up taking me 5 days - the docs were just... not good.
This all seems very un-Stripe like, and TBH has me a little worried.
> This all seems very un-Stripe like, and TBH has me a little worried.
Well, I brought this up, but for what it's worth, as a user who's been thinking about this for a long time, I don't know how they could have done it any better given the new regulations and good support for payment methods that aren't credit cards.
Hrm, I've seen most who migrate spend a similiar time to your estimate. I know you've already migrated, but I'm really sorry it took that long, and I'd really like to hear where we can improve the docs. Would you mind emailing dev-feedback@stripe.com (and feel free to CC edwin@stripe.com).
[Not the GP, but 100% in agreement with them, except that we abandoned updating our integration.]
I'd really like to hear where we can improve the docs.
IMHO, the fundamental problem is that as the data model and API have become more complicated, the explanatory documentation has become less coherent. It feels like jumping around a Wiki now.
More specifically, we couldn’t find anything to show us the big picture of how SCA actually works with Stripe’s system. We also couldn’t find useful end-to-end walkthroughs with code samples to learn by example, hence my suggestion in the other comment you replied to. Lacking a frame of reference from one source or the other, all the detailed documentation about Stripe.js and APIs doesn’t help very much, because you don’t know what you need to look up in the first place or how anything fits together.
This was compounded in our case because after spending considerable time swapping messages with Stripe support, in which we did explain that we’d read all of your documentation and we did also describe our (very simple) existing subscription set-up process in terms of specific Stripe.js and API calls, the responses were just boilerplate references to documentation pages we’d already read. Of at least five different people from Stripe who replied to me over more than two weeks, not a single message mentioned any specific function in Stripe.js or the API or any specific webhook, despite several explicit requests and sending specific details on that level from our side at Stripe’s request.
To put this in perspective, please consider that when we first integrated with Stripe, it took one Stripe.js call, usually one API call and one webhook to tokenize card details, set up a Customer and Subscription with that card, and then act on each successful payment. I wrote that code myself in less than an hour, and I think it was described start-to-finish on no more than two or three pages on Stripe’s documentation site.
At the risk of making this comment antisocially long, but with the suspicion that we have not been the only ones following this path, I’ll describe what happened this time instead. The first of several links I was sent by Stripe support in one of those emails went to a page about saving card details for later (https://stripe.com/docs/payments/cards/saving-cards-after-pa...). Within just the first step of that page, there are at least six different concepts we hadn’t previously used in our integration that were mentioned, most of them without any sort of introduction, definition or link. Some of these are clearly very important concepts in SCA world, like a new PaymentIntents API and distinguishing on-session from off-session payments. OK, so we need to learn about those. Off we go to the API documentation, where we do find PaymentIntents, which in turn refers us immediately to the PaymentIntents API explanatory page (https://stripe.com/docs/payments/payment-intents/creating-pa...). This gives us a general idea of what PaymentIntents do (remember, when we integrated before, you didn’t even have concepts like Invoices in your API) but then starts talking about manual and automatic confirmation. So before we’ve finished reading the introduction on that page, we already have two more new concepts, and there’s a third link to a comparison between them, but that refers to one-time payments and we’re trying to set up a subscription, so now we’re jumping context and don’t know whether what we’re reading is actually relevant to our use case or not.
That last paragraph could continue for literally several more days of finding our way around, often going in circles. We’ll later be confused by the difference between PaymentIntents and SetupIntents, several similarly named but apparently quite distinct functions in Stripe.js v3 that might replace the old call to create a token, the difference between a source and a payment method, which actions happen synchronously and which are or might become asynchronous in the new world of PaymentIntents and SCA, and many other such questions. We’ll also wonder how any of this fits in with things like Dunning, which was the other big improvement we had hoped to make back when we first started reading about the latest APIs and contacted Stripe support for advice. One important thing you’d notice by the end of the story is that at no point did we ever discover what triggers step one on that very first documentation page to start with — is it a replacement for the old tokenization using Stripe.js, a replacement for the old Customer.create API call, something we have to do in addition to those things at some point?
This comment is already far longer than I had intended, but I hope that gives you some idea of how the current documentation and support systems are not working as well as they used to, from the perspective of a long-time Stripe merchant just trying to update their integration to the new APIs to maintain the equivalent of functionality we already had.
If I were tasked with improving the docs then I would start with an exercise to identify all of the explanatory pages for the new PaymentIntents API, SCA migrations, Dunning, and anything else related. Then I’d get someone, preferably someone who doesn’t already intimately understand how SCA works and Stripe’s API, to go through and highlight every concept or technical term that hasn’t yet been explained before it’s used. I suspect that would identify many points of potential confusion, but with several recurring themes. Next, I’d take a step back, look at how SCA works, look at how the Stripe data model and new APIs work, determine which are the foundational concepts that keep coming up but haven’t been explained first at the moment, and then write a one-page introduction to the big picture and how these concepts fit together. That is the key page that is completely missing at the moment. And then ideally, I’d go from there straight to the kind of walkthrough mentioned elsewhere, showing how to set up a subscription or a one-off charge using the new Stripe.js, APIs and webhooks with reference to the main concepts from that overview page. From that starting point, there is a frame of reference, and the more detailed explanatory pages and full API specs might make more sense to someone starting an integration essentially from scratch with little prior knowledge.
I'm glad I wasn't the only one who had issues with the "support circle".
Usually Stripe is on the ball but I dunno, I had a very non-productive back and forth with them. Non-productive in the sense that it took a long time to get anything that was in response to my initial email and that in the end I didn't learn anything I didn't know before I sent the first email.
Their first couple of replies just tried to get me to use their hosted checkout even though I mentioned needing coupon codes early on which is not supported by that. I also included a super detailed explanation of my workflow (bullet points, using headers, in depth break down of everything) and it was clear their hosted checkout was no way possible to use -- not even the automatic payment intents was viable due to the lack of validation I had to do server side when using automatic PI. Manual PI with a million hoops to jump through or forfeiting sales with Charges was the only option.
It really felt like the support person didn't read the request. It felt like they skimmed it for 5 seconds for keywords (or maybe this was algorithmic) and then made a copy / paste suggestion from a script just to make sure they hit a daily quota of "emails answered". It took a number of these until I started to get responses back from someone who sounded like they read the initial email.
I'm thankful Stripe exists but the worst possible thing you can ever do in support besides ignoring a customer is having the customer spend 45 minutes writing the most detailed request for help possible and then getting a canned response that was already deemed not able to be used in the original email that was sent. It's just in your face proof that support didn't even read it. Then you have to spend 5 back and forth emails over a week just repeating what you wrote in the first email.
I wish multi-billion dollar companies hired support people who cared as much about the company as the CEO. I guess this is why solo devs and smaller teams tend to offer the best support -- simply because the person answering emails is the person running the business or is massively invested in it.
If it’s of interest, our recent experience and the impression it created were very similar. We also somehow seemed to wind up with two or possibly three concurrent discussions going on, possibly because my initial contact went unanswered so I wound up chasing. We still use my business email address as our point of contact with Stripe, so if you look for chris.newton in your tracker, you should find all of the relevant discussions.
I just want to follow up with after emailing edwin, I was put in contact with someone who is on a different level than the support team I've talked with originally.
We got in touch late Friday so a resolution wasn't made (not enough time), but it's clear he spent more than 1 minute skimming the support message and it felt like he really put in serious effort to help me in my specific situation. I think everything will be crystal clear in the end after a couple of emails (and these aren't just repeating emails, it's to deal with moving forward with new info after implementation).
I wish this type of support was the default. It never would have happened without this post on HN happening. There's a lot of value in having in depth emails about specific problems because it leads to documentation improvements that benefit everyone (plus it makes your paying customers happy on the spot because they got help using your product).
I wonder whether that might also be what the last person from Stripe support meant when they mentioned sending us to some sort of specialist. Unfortunately by that point we’d already spent more than two weeks going back and forth with numerous people replying but no actionable advice, so we declined and made other arrangements. However, I did also send them some notes similar to my comments here, so perhaps the negative experience in our case could at least be helpful for improving their documentation for others in the future.
I had this exact experience recently too! Stripe was so easy at first so my estimate to upgrade was only a day, but the number of concepts and the muddled way they’re introduced meant day after day I was still working out if I really needed a payment intent, what would getting charge authority look like, do I even need any of this since I’m not doing business in Europe (in the end no, I migrated to the ‘old’ charges api, which the token api used to be). It ended up taking 5 days and causing quite a bit of angst with my cofounder due to a customer deadline
Combined with Stripe not refunding merchant fees, which was what triggered me to rewrite the payment process to delay processing until the last possible moment and making our own customer facing process more complicated, my most recent experience was less magical (like it was the first time) and more like dealing with a giant bank
I really like products like connect, and the original front end SDK (elements feels like overreach), but if someone hungrier came along they’d definitely get a look in
Yes, I feel Stripe has lost its edge with the new APIs. Interesting to hear 'demotivating' used as that's how I felt for a while. I needed many requests with Stripe support and could see the docs changing each time I returned to the task.
The interesting one for me is the way the client triggers the transaction, and the server has to asynchronously process that. I'm pretty sure I'm still having dreams at night about all the edge cases and whether I've truly covered them. Others are probably a more "that seems to work" style of development.
I was really happy with my idempotent IDs before....
I agree with everyone else re Payment Intents. I started using them in "beta3" last December(?) and did my last "upgrade" to PaymentIntents (really a full replacement of the Stripe integration) 2 weeks ago.
As others have said, the documentation is the major issue. PI takes time to understand, particularly if used to the old way. The documentation is improving but still a mess. Code examples miss steps, and I only made progress when I found this page: https://stripe.com/docs/payments/payment-intents/web-manual which 2 weeks ago wasn't clearly linked in the documentation (and https://stripe.com/docs/payments/payment-intents/migration where I kept ending up had contradictory code for the last stages). The split between automatic and manual confirmation isn't helpful.
Like others, each integration took longer than the 1 day I expected. I resorted to reading the API documentation at times to work out which JS method I needed - something I don't normally need with Stripe! handleCardPayment() vs handleCardAction() vs createPaymentMethod()... there's so many code snippets floating around in the docs for contradictory flows.
If Stripe really want to improve matters, a "What do you want to do?" wizard that asks questions like "When do you want to confirm?" and "Do you need to store the card?" and produces the right code snippets at the end would be helpful.
I also feel Stripe has dropped the ball in Europe. I was consulting with a client with not-insignificant turnover, and I recommended they switch to Stripe. The sales team took a week to reply to his enquiry, then didn't answer the questions but returned a boilerplate response. And this went on. It's not a good impression and made me look bad. I'm going to be less open to recommending Stripe to existing, established businesses now.
4-6 years ago Stripe was a shining example of a motivated sales and support team. Now - old and painful-to-integrate competitors like SagePay are doing better. Or shudder Braintree, who have arrived with discounted rates, terrible documentation, but an easy-to-drop-in JS widget for all payment methods.
Second that for having all of the API be public. Being able to purge test data via API in a single call is long overdue too and would be a delight compared to the process now - sign in and navigate to the delete page and wait however many hours it takes to finish deleting records individually or silently crash. During this time the API credentials are blocked too.
It would be really nice if there was a freeze on breaking API changes that amount to tweaking grammar too.
Yeah I wonder why the purge-test-data job is blocking and long-running. I suspect it's just low priority to fix it, but I imagine it would be doable to "unlink" the user's entire "test database", provision a new one, and wipe the old one in the background whenever convenient (and not even necessarily the same day).
I'm pretty nostalgic, so I do miss the old Charges API sometimes. But Charges assumed payments were binary—and we all know they're most definitley not. This also doesn't help with the new SCA regulations that started rolling out last Saturday (https://stripe.com/sca).
We've built Payment Intents to be future-proof. It tracks your customer's checkout flow, actually provides logic for retrying payments (subscriptions!), and also triggers authentication when necessary—so you'll meet SCA requirements.
Many have told us this has been pretty easy (and improved conversion too), so I'm really sorry that you got unhelpful advice earlier. (Would be great if you could forward that to me: edwin@stripe.com.)
I agree that Payment Intents is a lot more complicated than Charges - it's like a snowball effect where a small amount of extra complexity in an underlying API (SCA) gets exaggerated into ever more complexity with each API that added on top of it.
By the time it gets to our implementation it's horrible and occasionally (2% of the time?) we get a payment attempt that the client has handled and submitted to our server but isn't in succeeded state. We temporarily fix this by redirecting them back to the payment page but this time in 'Charges' mode. Which seems to work about 50% of the time
I wonder how much of this complexity is necessary - inevitable given SCA - and how much is because of Stripe's desire to support DD / bank-based payment methods in one integration. I guess we will see if, once SCA becomes widespread, other payment processors have simpler integrations...
Speaking of SCA, I really don't understand the motivation - it's not like higher fraud rates were hurting consumers, since those costs were borne by the merchants. My suspicion is that it is in the interest of card-alternatives like Sofort to add some friction to card payments, after all if every customer has to visit their bank for authentication anyway, why bother with a card payment at all?
That said, it is infuriating that after wasting all that time re-developing, SCA doesn't seem to have gone live at all. It reminds me of GDPR - the law abiding god-fearing types spend weeks worrying about compliance, disrupting their business; whereas the cowboys just take no notice - and get away with it.
It seems to be how the EU rolls: sweeping changes with terrifying penalties and sudden deadlines followed by minimal or selective enforcement.
Would be interesting to have an entirely separate 'Getting' section for folks on-boarding for first time just getting a handle on basics. Potentially even going as far as new 'Simple' APIs. Mention all the caveats up-front and direct them to documentation if they need more functionality. I'd imagine it would speed up adoption.
You can delete all of your test data by clicking a button in Settings > Data (/account/data). We also recently launched a feature that lets you delete multiple customers at a time, and hope to expand that to more different types of objects soon!
> I recently learned that I have customers with different currencies and it's not even something I had to consider or account for.
If your customers are at all price-sensitive, you might want to give this a little more consideration. Banks and payment processors always offer "We handle currency conversion for you! How convenient!", and they pretty much always do it by charging several times the normal conversion fee (in the form of converting at an extraordinarily unfavorable exchange rate).
I hate merchants who use those services; I have a credit card that will pay you in any currency and only charge me a 1% conversion fee. Please charge me in your currency, not my currency.
Please charge me in your currency, not my currency.
We did that initially, but you do discover a few downsides fairly quickly.
One is that if you also price in your (the vendor’s) currency, for any sort of recurring subscription or repeat purchase, exchange rates can cause noticeable and possibly surprisingly large changes in what your customers pay from one time to another. Naturally this is viewed favourably by your customer if the rate has moved one way but less so if it went the other.
Another is that not everyone’s cards charge as little as a 1% conversion fee. If you’re charging a typical consumer subscription of say £10 per month from here in the UK, some customers could easily wind up paying several pounds more by the time you add in the percentage and flat fees that some card providers seem to be charging for foreign currency transactions.
And finally, some people have never travelled much abroad and don’t really understand how things like currencies, exchange rates and conversion fees work at all. You’ll get someone who has signed up at £10/month, with the amount and currency clearly displayed at every step of the process, who will then email you to ask why they were charged $14.63 instead of the $10 they agreed to. Sometimes there isn’t much you can do at this point, no matter how much you try to explain that $10 and £10 are not the same, and that their card company has added a hefty surcharge for the conversion, and that this would have been explained in the credit card terms (which they probably never read) and isn’t something you have any control over as the merchant.
It’s a tricky area, because there’s usually nothing in it for a merchant to push a customer who does know what they’re doing and does have good terms into paying via the less favourable currency. On the other hand, if you start to provide explicit options for this sort of thing so each customer can choose for themselves, you risk making your payment process more complicated and losing conversions due to analysis paralysis. As ever, there’s not really a single “right answer” when you’re dealing with customers with very different arrangements on their side that you can’t even detect.
>their API is a little bit... bloated for simple needs
I used Stripe about 7 years ago. I used it because their APIs were simple and PayPal etc. was complex and bloated.
It seems that this cycle repeats throughout b2b startups. Is there now an opportunity to create yet another simple lightweight API but one that doesn't cover all use-cases?
Is there now an opportunity to create yet another simple lightweight API but one that doesn't cover all use-cases?
I think so.
One of my businesses has used Stripe since they launched in the UK, around the same time we were launching ourselves. Like many others, we appreciated the straightforward API, excellent documentation and easy integration. I’ve been happy to recommend Stripe personally on many occasions since then.
Recently, we were trying to update that original integration to take into account the new SCA rules that came in across the EU last weekend. Unfortunately, after reviewing Stripe’s current documentation site in its entirety and other SCA-related material, followed by a lot of discussion with Stripe’s support team, we were still struggling to understand the model of how SCA fits in with Stripe’s current API. That left us unclear about the structure that our integration needed in terms of Stripe.js, the API and webhooks. Essentially, after a lot of effort, we still didn’t really know where to start, and inevitably there came a point where it wasn’t viable to continue and we had to look at other options.
Of course Stripe has grown a lot more than we have in those intervening years and it’s understandable that their data models and APIs will have become a lot more complicated to meet the needs of their wider target audience. But sadly, the simple API, clear documentation and top-notch support that made them so attractive originally do seem to have been casualties along the way.
Given that SCA seems to be causing a lot of bother across the whole industry in Europe, to the point that several EU member states seem to be deferring its implementation because so many people aren’t ready for it despite years of advance notice, it does feel like there’s an opportunity for someone to disrupt the online card payments market in Europe now with a back-to-basics approach that is enough to meet the new regulatory requirements. One interesting question is whether it will actually be another card payment service that does so, given that a lot of other payment methods are popular in various European countries and some of them do have significant advantages including fewer complications due to SCA. We live in interesting times, as they say.
I am considering migrating from Braintree to Stripe.
It does look better, but I find some of the praise a bit too rosy. For example, the whole invoicing setup makes US-specific assumptions which are largely invalid where I operate (EU, specifically Poland), and I wonder if their recurring billing can be used without invoices. Also, there is no SAF-T (JPK FA in Poland) reporting for invoices, which means I can't even legally use their invoicing. Their E-mail templates are not customizable, which in my case makes all of their E-mail functionality useless. Then the PSD2 SCA (3d-Secure) flows seem to be hastily added and there is no good overview in the documentation (Braintree suffers from the same problem).
It still looks like the best option I have, though.
Yea, I'm pretty cool with this IPO as the company has built into filling quite a good niche while also putting pressure on MasterCard/Visa to clean up their monopoly softened act. I hope they find good success in the long term!
Edit: Oh please ignore my blindness, I didn't realize this was just a pure valuation announcement.
where does it say this is an ipo?
from the article: "Founded in 2010, Stripe is middle-aged by Silicon Valley standards, but Mr. Gaybrick and Stripe president John Collison said it had no plans to go public. "
I had the unfortunate opportunity to integrate with Adyen around 2016-2017 and it was super painful. The API didn't make much sense to me and the documentation was hard to navigate and understand. It all looked very rough and rushed to the market.
Granted it was "a long time ago" but I can still remember the pain.
Had a very similar experience around that same time. However, Adyen provided much nicer built in reporting features than Stripe at the time which made Finance happy.
A lot to live up to, but those Collison brothers are hella ambitious and execute like champs, the whole team at stripe is seriously world class. No surprise here and incredibly well deserved. Keep up the good work folks.
Before we start piling on about whether or not its really worth 35B just keep in mind how private companies are valued. Someone paid a lot of money for a chunk of stripe so thats what its “worth”.
Personally I think stripe is close to worth - as another commenter put it - half of goldman sachs. The recent launch of loans, credit card issuing, etc are all bets or exercises that put stripe in an incredible position to build platforms for financial capabilities.
Does the existence of other financial firms make Goldman Sachs worth any less? I don't think it does.
We're used to winner-take-all when it comes to these unicorns, but I'm not convinced it will stay that way. With many of these service niches, there's a ton of money to be made and enough needs / feature differentiation for competition.
Not the parent poster but I don't think that's what they were going after. I think they were asking whether the valuation is fair relative to other companies that are operating in a very similar space with similar ambitions. GS is an investment bank. A fairer comparison would be SQ, PayPal, Adyen or First Data.
Square's market cap is $25B today on the public markets with a 2019 estimated net revenue of $4.5B and almost $100B in transaction volume. I don't have any insight into Stripe's numbers, though I'd guess it's probably not 40% more than that? Willing to be surprised of course, it's a great company.
The real question being asked here is: "Is Stripe's valuation likely to hold up when they go public one day?"
Exactly. I've really liked Patrick Collison in interviews and I've long admired their API documentation. Square Capital was first to offer loans to SMBs that amortize over the transactions so Stripe isn't the first mover there. Some bigger companies like eBay and Burberry have chosen Adyen as a payment solution and I think Booking uses Braintree? Are there reasons outside of costs to choose Adyen or Braintree over Stripe?
Can Lyft develop their own payment tech because they only transact in the US and Canada, and global transactions are where things get complicated?
I like most things about Stripe, but Shopify is also growing like crazy, has an awesome founder, and provides the only alternative to Amazon right now and is valued at $35B.
> Are there reasons outside of costs to choose Adyen or Braintree over Stripe?
IMO costs are the worst reason to pick one of these providers at scale. They're all operating with a very similar cost basis, so you know they can each more or less match eachother, and if you come in with sufficient scale they'll offer custom pricing. Their costs are determined by the payment networks and their ability to mitigate risk and fraud. Stripe got a rep for being willing to match anyone even if they lost money in the process.
Payments traditionally has been very fragmented. I think the biggest winners will continue to be Mastercard and Visa as all of these ancillary services will continue to move payments towards digital both on the consumer and business side.
I haven’t used the two products, but is Stripe 50% better than Adyen? Why would I use one versus the other? How easy will it be for Lyft to develop its own payment technology?
I don't think "better" matters in current valuations. Nor does comparison to competitors really matter too much to the valuation - what matters are the revenue streams and potential for future earnings. So the number of current clients, and prospective clients, seems more relevant.
> How easy will it be for Lyft to develop its own payment technology?
Depends what you mean here. Any of these large companies are going to have their own merchant accounts (or should) processing payments for them. Stripe needs to either 1) take out the bottom of the market, which is what I thought they are competitors were doing and/or 2) come in cheaper and/or more convenient than maintaining your own payment services and such, which I think they do in some cases.
Stripe Connect's fee is 2.9% + 30¢ per transaction for all payment methods accepted; plus another fee of $2/user/mo for each active "merchant" on your platform.
Adyen's MarketPay fee varies depending on payment method and is about 1-5% + 12¢ per transaction. I've contacted them to ask what one could expect for MC and Visa, but Amex and Discover are 3.95%, so I imagine similar. No mention of any other fees.
So for smaller dollar transactions (~$5), Adyen appears to be cheaper. Also, they support ACH, which Stripe does not.
I quite like Stripe - but them forcing the recent switch to Checkout V2 has me a bit miffed.
Previously it was super simple to add dynamic card payments to a site - just drop the JS in, make a call to your server and then call Stripe from your server. Done. And it's all done in a popup on the same page (so no context switching UX for the user).
Now it seems they've killed the simplicity of that in favour of a more PayPal-like experience - where the user gets pushed out to the Stripe website to checkout. And it becomes more complex to implement too - due to everything being async and webhook based. At this point I think Paypal might actually be easier to implement for a certain class of simple one-off payments (although their sandbox servers are cripplingly slow).
I'm a little bit skeptical of this change because I think it's partially a strategic play by Stripe (with the smokescreen of SCA-compliance + Apple Pay support) to become more of a user-facing online "wallet", rather than just a behind-the-scenes payment processor.
A wallet isn't the intent. It's almost the opposite!
If you remember the previous version, your customers used their saved card within Checkout. The new version of Checkout lets your customers use whatever payment method is easiest for them, and wherever it is. That's why we're big fans of things like Apple Pay (some have seen a conversion increase of 250%!), local bank payments in Europe, or even saved cards in Chrome (rolling out now).
From its inception, Checkout was designed to be the fastest way to accept payments, and I think it's now faster (and even faster for customers). You can just drop in a single line of code—and that code doesn't have to be server-side. :)
> A wallet isn't the intent. It's almost the opposite!
But isn't that what you just described? Saving your payment details to Stripe (as opposed to just entering your card details like a standard payment processor). Stripe is now essentially a wallet where you store your payment details.
Was it a necessary change to push users out to Stripe to save their payment info? What differentiates that from what was there previously. Was it that the CC info was stored per-domain, rather than per customer across all sites?
To be clear, I think it could be an improvement for a lot of cases - just potentially not mine in particular!
> Checkout was designed to be the fastest way to accept payments, and I think it's now faster
Here's a pretty common scenario that definitely just got more complex to implement: dynamic pricing + instant fulfilment (i.e. selling digital goods online).
So that instantly rules out the "No server-side code" approach. Here's what had to be done in the old version:
1. Import checkout.js
2. User clicks pay + fills out details on Merchant site
3. Merchant js makes a call to Merchant server with Stripe token
4. Merchant server calls Stripe to charge the token
Now:
1. Import checkout.js
2. User clicks pay
3. User has to wait for loading spinner while a Stripe session is generated on the Merchant backend and passed to checkout.js
4. User is pushed out to Stripe website to pay + fills out details
5. Stripe backend calls Merchant webhook
6. Customer redirected to Merchant
7. Merchant server must check with Stripe to see if session was completed and customer has successful purchase.
Overall - that's a more complicated flow for the Merchant to implement, with more room for things to go wrong.
And it's not technically true that the flow will always be faster for users - if the customer had CC details saved in the old version, the flow would have been faster for them (less async calls + no redirect to Stripe).
For a certain segment of Merchant, I think there are definite improvements - but for the one-person operation selling software - PayPal is now the easer to implement option.
But the whole question of "which payment method do you want to use?" is unnecessary complexity if they're sitting there with a card in their hand. Wouldn't it be better to let the front end service handle that question, and then use the appropriate Stripe APIs in the front end?
The whole revelation of stripe was that if a customer was sitting there with a credit card, they just put it there into the same screen and it was done. It was the other crappy products that forced you out into a merchant gateway then back again
I'm never going to send retail customers out a payment gateway with someone else's brand/colors/html, mostly because it's just too confusing to introduce more concepts at that critical stage when they're about to actually make the payment
I'm never going to send retail customers out a payment gateway with someone else's brand/colors/html, mostly because it's just too confusing to introduce more concepts at that critical stage when they're about to actually make the payment
This is one of the concerns we have with SCA. By the nature of the additional authentication steps, they are necessarily hosted off-site in some situations. Handing your customer off to some other service in the middle of your payment flow and hoping they make it back is the only choice you have. It seems likely that this will reduce conversions, just as anything else that lengthens or complicates the payment flow usually does. What we don’t really know yet is how much difference it will make in practice.
This is one of the concerns we have with SCA. By the nature of the additional authentication steps, they are necessarily hosted off-site in some situations.
Is this a necessity though? Couldn't they just enter the 2FA code in the same manner that they enter their card details on the merchant site? i.e. After entering their card details, it will just prompt them for more info if necessary.
I’m not sure exactly what PSD2 requires in this respect without checking it again, but in practice I think all of the major schemes for card payments that actually exist do work that way, so it’s probably beyond the ability of any service like Stripe to avoid at the moment.
Developer love isn't everything. There are some projects on here that just as much dev love, but are not even able to fund a single person. There are also quite a few products I've used that have an amazing API but an otherwise awful product.
Yes, dev love is a big part of what allowed Stripe to become stripe, but it's probably not a good indicator whether Strip is worth $1B or $10B or $35B.
> Founded in 2010, Stripe is middle-aged by Silicon Valley standards, but Mr. Gaybrick and Stripe president John Collison said it had no plans to go public.
Why doesn't Stripe want to become a public company?
The point of an IPO is to A) create liquidity, and B) divest some of the risk to a bigger pool of investors. If you are cash flow positive, and have only long term investors, there’s no real monetary benefit. You’re giving away your dividends to other people.
It’s a question of whether you want to discount your own risk or hold it. IPOing allows you to price your risk and sell some of it off. But if you’re a long term investor there’s a good chance you value your risk higher than the market, which means you’ll lose money in the long term by selling it.
It also depends on your other investment opportunities. If you have other places to invest, then your money has a high time value and you’re paying more “interest”, so-to-speak, on the risk. If you don’t have anywhere better to park your money then the time value is very low and holding that risk is cheap.
There are other factors as well, like government limits on buying other assets, that could make a private investor want to hold.
While those are the "theoretical" reason for IPOs, let's not ignore a primary reason for an IPO, which is to let early investors and employees cash out (though these days many companies, e.g. Slack, are just doing a direct listing instead).
> Slack Technologies Inc. is set to go public on Thursday using a nontraditional process called a direct listing. Only one other big company, Spotify Technology SA, has gone public in this way.
It's a carefully worded answer. No plans != doesn't want to. And also, I'd read "no plans" as "no plans that we're gonna tell you about right this minute".
... which has absolutely nothing to do with going IPO, since they would cash out/in and get access to stockholders money at the exact day of their IPO, not "next year or two".
If you do not need to raise money there are limited reasons to go public, however you have much stricter reporting requirements, and general things you cannot do anymore since you are publicly traded, not to mention hostile takeovers, etc. Dell's story is a great example why you want to go public / go back private.
Visa makes a ton of money just off of necessary debit card transactions. As far as I know Stripe doesn't have a whole lot of groceries/gas stations/drug stores/doctors offices/etc as customers.
From what I've seen Stripe mostly has customers that are selling non-essential services and luxury goods. They'd be far more likely to suffer during a recession than Visa. I mean, Visa does around 1,700 transactions per second on average [1] and handled over 2 trillion dollars in a single quarter last year [2]
Why would you want to become a public company? Being public means more complex accounting, transparency, extra legal fees, focus on quarter-to-quarter profits, etc. Other than liquidity (especially for founders/VCs), I don't see much of a reason to and a lot of reasons not to.
Stripe is trying to capitalize for a capital intensive endeavor: Stripe Capital.
An IPO would have been one way to fund it, but likely would have involved a lot of financial scrutiny along the way, which would probably distract them from the main point of raising the funds.
A bold move which will hopefully work out for them and not overvalue the company before they attempt to go public later on.
Only ~10% of the world's GDP runs through the Internet right now, Stripe is working to raise that number and I fully support them. Their brand, their message, their product is stuff I study as I work on my own projects.
I feel this valuation is well-deserved. I rarely feel that way nowadays. This company will be around and still relevant a decade from now. I'd love to see them challenge the dinosaurs in the financial sector.
A couple thoughts on why this isn’t a fair comparison:
- Goldman is profitable but the employees extract most of it via compensation.
- Goldman has to rewin their business every year. Very little recurring revenue and they are one recession from imploding.
- You can’t really compute valuation on a very small investment. It’s not like the entire float is trading, and the small investment (relative to valuation) can have all kinds of liquidity preferences and special rights.
Privately traded companies and publicly traded companies use different terminology for the same things.
In the private markets "valuation" is a term that just means "someone bought a couple shares at this arbitrary price, here are the value of the other millions of shares at that same arbitrary price". Although the effects on all shareholder's balance sheets are real and useful, it is just broadcasted for marketing and hype.
In the public markets "marketcap" is the same term.
And finally, older public companies have low price to equity ratios because the hype has fizzled and they are predictable. It doesn't mean anything. Its not enough inputs alone for you to decide what the rest of the market will do.
I use STRIPE as my payment Processor for my 1 man shop. They are great. Stupid simple. They even offered me a cash advance. All i need now is for stripe to be my bank to keep all my money in there and pay my business bills from it. One stop shop to run my business, would be great! What would even be more useful to me then lending me money, is if they help me build my v2 and take a slice from my business. Finding engineers is hard and very expensive for a small online business like mine.
At Producteev, my old start-up, I implemented the payment system using Paypal, omg, it was so hard, and so painful for the following reason:
- poor documentation
- I never knew how to get an up to date documentation
- very slow api and website
- very hard to understand the meaning of the undocumented data etc.
Once, my co-founder @Ilan Abehassera sent me a link to an article about Stripe on Techcrunch:
I signed up to Stripe, within minutes I was able to charge my own credit card through a CURL bash call, everything was clear, recurring payment perfectly handled, discount, etc etc. And this was at the very beginning of Stripe. Then I had to come up with why we should quickly switch from Paypal to Stripe.
Anyway, very good memoery, you definitely set the standard for how an API should be designed and I can't thank you enough for that!
We implemented stripe as an add-on a little more than 6 years ago and left it mostly untouched. After some recent TLC we now facilitate $100 million a year through Stripe. Our next hurdle is trying to integrate Stripe terminal for thousands of customers but $300 a pop is a tough sell.
For huge Terminal device orders like that, we can help with a volume discount. Just email in to support@stripe.com with how many you need (feel free to CC me at edwin@stripe.com).
(BTW, if you didn't see, we have a $59 device too. We're also working on supporting more.)
It's not that I don't like Stripe, but was it really so difficult to process payments before? When I start working with online payments in 2007/2008 we had multiple easy to use solutions for processing at least credit and debit cards.
You could have a test account in less than an hour, and be ready to process real transactions in less than a week.
Stripe has plenty of competition, most of which have been around longer. You could argue that Stripe have a better API and that certainly has value.
Stripe is one of many services I would like to use but can't because they simply don't work in my country. I understand it can get somewhat complicated due to legalities I probably don't understand (or maybe the market is too small to even bother). But if your Navy can go through the country I live in, could you folks (in general and not directed at anyone) please try a little harder?
Where do you live? Our roadmap—literally—is quickly expanding to many more countries (we just launched in 8 new countries last week). And this new funding round will be put to use for that. :)
We announced a beta for this last week! You can send money to 45 countries. (We're turning this on for businesses in the US first, and we're working on more countries soon.) https://stripe.com/connect/payouts#request-invite
Stripe has made building payments related products fun for me when previously I had suffered through working directly with banks and various poorly designed gateways. Stripe is still the gold standard to me when it comes to developer APIs, documentation, and smart iteration. Kudos to everyone at Stripe!
> [Chief Product Officer] Mr. Gaybrick and Stripe president John Collison said it had no plans to go public.
How's that possible? At this valuation they aren't looking at acquisition, right? VC aren't investing to the tune of $250mm (in this round alone) without an exit strategy, right?
Not really. Some people infer value without any investment -- only based on P&L and year-over-year growth. (Stripe is consistently making money, after all)
Also I see little true (high-tech) innovation with the "SV Elite".
It seems that people are more interested in cornering markets than in creating exciting new things. The valuation doesn't surprise me because that's how you corner markets, by first building a huge pile of money.
There's two main incentives to go public: raising money and liquidity.
They don't need to tap public markets to raise money. And investors are likely OK holding off on liquidity if the valuation continues to rise.
Going public typically requires a significant amount of effort across the company, which can reduce focus on other initiatives key to growing the business.
Definitely. Some companies that have been private for a long time allow their employees to sell a percentage of their stock in these later private rounds.
It's not necessarily the same price you'd get on the public markets, but it can help give employees some liquidity.
Look at the valuation increases: Almost 2x year to year for quite a while. I don't expect most people seeing that kind of valuation increases looking to liquidate any part of their position unless they really can't help it.
If their fundamentals growth slowed to rates resembling the regular market, then sure, but as is, all a company with that growth rate might need is let tenured employees add, say 5% of their equity to the round so they can get a bit of liquidity to keep them quiet.
No one can predict what the price will be in a year. Diversifying before a possible recession would be prudent, especially since payment processing volume is presumably highly correlated with consumer spending.
>Look at the valuation increases: Almost 2x year to year for quite a while. I don't expect most people seeing that kind of valuation increases looking to liquidate any part of their position unless they really can't help it.
I'd rather take 2x whatever today than 0x nothing when the company folds tomorrow/in a month/in 5 years never having gone public.
That sounds a lot like investing based on the previous performance of the stock, which isn't a great investment strategy. I would never want a significant portion of my net worth in a single asset, regardless of how it has performed in the past.
Perhaps they needed some short term liquidity to make a new investment in something. Or perhaps they wanted to let some early investors/employees cash out.
I'm curious as to why they chose to raise $250M via VC instead of raising in the public markets? Of course there are trade offs and advantages to each, I'm just curious as to their calculus.
Congratulations to the Stripe team. Truly great product and company. The fact that WeWork truly thought that they were $12B more valuable than Stripe is insane to me.
> Still, a raft of younger startups, such as Checkout.com, are raising hundreds of millions of dollars in venture capital to challenge Stripe.
There is a paywall link for more details. I'm curious to know what they are looking to challenge (especially given the rave reviews that Stripe gets here at HN)
What do you mean? They look like they're on a fast path to disrupt like all of banking! The banking industry has to be bigger than the bed and breakfast advertising industry.
Linda Scott of Silicon Dales in the U.K. uses Stripe and isn’t surprised that the payment processor is in compliance. “We have found Stripe to be proactive and open around legislative changes.”
I will concede that perhaps I am wrong about AirBnB being less compliant than Stripe. Bravo to them for doing so in an environment that rapidly changes, sometimes designed to hem them in.
However, I will move the goalposts to rephrase my original point- AirBnB appears to operate in an environment that has more regulatory challenges, especially new ones, than Stripe, which operates in banking, which while regulations-heavy, which doesn't seem to be moving at nearly the same clip. And so my original point about AirBnB's problems still holds- the consequences of dealing with more lawsuits and having to spend more on lobbying.
Thanks to everyone here who took a chance on us in the beginning and shared helpful feedback over the years! How to serve startups/developers more effectively at scale is still the main thrust of our product focus. We've fixed and improved a lot of things since we launched here in 2011, but we also still have a lot of work to do. (Both "obvious things we want to fix" and "new functionality we want to build".) I always appreciate hearing from HN users (even if I don't always have time to respond): patrick@stripe.com.
For anyone thinking about what they should work on: I started building developer tools when I was 15 and "tools for creation" is still, IMO, one of the most interesting areas to work in.