Stripe’s new funding round values company at $35B(wsj.com)
wsj.com
Stripe’s new funding round values company at $35B
https://www.wsj.com/articles/fintech-company-stripe-joins-silicon-valley-elite-with-35-billion-valuation-11568912443?mod=rsswn
262 comments
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.
Generally consensus is a recession is going to happen in the next year or two, and the next good time to IPO won’t be for several years after it that.
Yep. That's why we've seen a glut of public offerings in the past 18 months, as CFOs push to get them out before the drought.
... 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.
https://www.forbes.com/sites/connieguglielmo/2013/10/30/you-...
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.
https://www.forbes.com/sites/connieguglielmo/2013/10/30/you-...
> which has absolutely nothing to do with going IPO
Sure it does. You can't do an IPO in a day. A company starting the process now risks having the recession start before the IPO goes live.
Sure it does. You can't do an IPO in a day. A company starting the process now risks having the recession start before the IPO goes live.
Visa IPO’d during the Great Recession in 2008.
Visa's underlying fundamentals didn't change due to a recession.
Stripe is also in the payments space. I wouldn't expect Stripe's financials to change any more than Visa's during a recession.
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]
[1] https://hackernoon.com/the-blockchain-scalability-problem-th...
[2] https://www.digitaltransactions.net/visa-surpasses-2-trillio...
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]
[1] https://hackernoon.com/the-blockchain-scalability-problem-th...
[2] https://www.digitaltransactions.net/visa-surpasses-2-trillio...
Incentivizes short-term thinking?
My main question then is how do you create liquidity for employees? Unclear if these rounds include secondary offerings for employees.
My main question then is how do you create liquidity for employees? Unclear if these rounds include secondary offerings for employees.
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.
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).
[deleted]
[deleted]
Those people are divesting of risk.
Or seeking liquidity. They can be related but I wouldn't say they're synonymous.
Many???
https://www.wsj.com/articles/the-ipo-shortcut-a-direct-listi...
> 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.
https://www.wsj.com/articles/the-ipo-shortcut-a-direct-listi...
> 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".
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.
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.
Well-deserved. One of the best dev platforms in existence right now with a clear value prop that is perfectly executed on at 100%.
I'm excited to see what the future holds for them.
I'm excited to see what the future holds for them.
Stripe is cool -- I use it every day -- but is it really worth, oh, half a Goldman Sachs?
I dunno man.
I dunno man.
Square is $25b and was trading at above $40b at some point within the last year.
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.
- 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.
I think your third point supports the OP original point. Stripe probably isn't "really" worth that much now.
EDIT: wanted to mention that my impression is that they're a great company, just not worth $35B.
EDIT: wanted to mention that my impression is that they're a great company, just not worth $35B.
They are great. Don’t undersell the benefit of recurring revenue. Compare the valuations of credit card companies vs GS too.
- Goldman has to rewin their business every year. Very little recurring revenue and they are one recession from imploding.
Haven't they weathered a fair few recessions already?
Haven't they weathered a fair few recessions already?
They weathered the last one. Lehman and Bear didn’t.
how often do you use goldman sachs?
PayPal is a $100 billion dollar company. They have roughly 1/3 the market share of PayPal.
Stripe is the better product.
Stripe is the better product.
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.
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.
Why is Stripe still private?
It would probably be safest to stay private and ride out the weather, the public markets are not exactly fun right now.
So VCs can capture every bit of value before its put on the public market.
Cause it's easier to be private. Look at what wall street is doing to Tesla and ask if they wished they we still private or not.
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.
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.
I'm not sure what Stripe's policy is on selling shares on secondary markets, but another reason is that at some point employees need liquidity too.
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.
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.
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.
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.
>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.
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.
Because they are wildly profitable already without outside capital investment. Also: much less paperwork to do.
If they're wildly profitable, why would they need this latest funding round?
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.
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.
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.
What about Stripe versus Adyen or Square?
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.
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?"
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.
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.
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.
Short term public company values are fickle. Much more so for high growth/money losing/tech companies. Shopify was worth $46B at times in August.
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 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?
> is Stripe 50% better than Adyen?
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.
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.
sources: https://stripe.com/pricing https://www.adyen.com/pricing/full-list
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.
sources: https://stripe.com/pricing https://www.adyen.com/pricing/full-list
Stripe supports ACH: https://stripe.com/docs/ach
Currency conversion fees are also quite cheaper on Adyen 1.2% vs 2% on Stripe
>Someone paid a lot of money for a chunk of stripe so thats what its “worth”
No, someone paid a lot of money in order to make even more using greater fool theory.
No, someone paid a lot of money in order to make even more using greater fool theory.
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.
Overall I'm really not surprised at the valuation. Stripe is one of the best products/services out there.
Why is it better than Adyen?
For starters I've never heard of Adyen until just now. So, perhaps better marketing?
It's pretty popular in the Europe and is a Dutch company.
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.
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.
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 [email protected] too.)
It would be great if the UI allowed you to mass-delete entries, at least in test mode.
Hi! I work at Stripe on the Dashboard.
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!
Thanks for the feedback, keep it coming :)
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!
Thanks for the feedback, keep it coming :)
>> "I work at Stripe on the Dashboard."
I thought I saw someone running around in there.
I thought I saw someone running around in there.
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.
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.
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.
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....
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....
>needed many requests with Stripe support
Could you forward one or two of those to me? [email protected]
Could you forward one or two of those to me? [email protected]
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.
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.
Thanks for the suggestion—you are right!
We're working on a walkthrough that'll help with this now. Stay tuned.
We're working on a walkthrough that'll help with this now. Stay tuned.
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.
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.
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 [email protected] (and feel free to CC [email protected]).
[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'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.
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.
Not good. Sorry about that. Could you forward me that support thread ([email protected]) and I can look into what went wrong?
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).
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).
Interesting comment. I hope it works out for you.
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 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
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
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.
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.
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).
Email sent!
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: [email protected].)
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: [email protected].)
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.
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.
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.
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. "
>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?
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?
Always, in every part of the stack.
The world of software APIs breathes in and out in waves of complexity.
The world of software APIs breathes in and out in waves of complexity.
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 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 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.
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.
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.
Off tangent but this is the kind of comment that I come to for HN regularly. Personal insight and experience.
> Yeah their API is a little bit... bloated for simple needs since they're covering for many different use-cases
You're right. We're fixing this. Stay tuned.
You're right. We're fixing this. Stay tuned.
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.
* SCA = strong customer authentication
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.
* SCA = strong customer authentication
Elements is not a requirement to create a PaymentMethod. The recommended path factors in PCI stuff etc. Feel free to email me to [email protected]
Uhm... got a link?
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?
[1] https://stripe.com/docs/stripe-js/reference#stripe-create-pa...
[2] https://stripe.com/docs/stripe-js/reference#stripe-create-to...
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?
[1] https://stripe.com/docs/stripe-js/reference#stripe-create-pa...
[2] https://stripe.com/docs/stripe-js/reference#stripe-create-to...
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: {…}}}`
[0] https://stripe.com/docs/security#validating-pci-compliance
[1] https://stripe.com/docs/api/payment_methods/create#create_pa...
[2] https://stripe.com/docs/stripe-js/reference#stripe-handle-ca...
[0] https://stripe.com/docs/security#validating-pci-compliance
[1] https://stripe.com/docs/api/payment_methods/create#create_pa...
[2] https://stripe.com/docs/stripe-js/reference#stripe-handle-ca...
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.
That's the flow we had with the v2 and that's what we can't replicate with the v3.
disclaimer: not recommended, etc... but ¯\_(ツ)_/¯
https://runkit.com/lxmedina/5d863141b387ad00138e273f
Gracias :)
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.
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.
Great company but it’s too hard to infer value from such a small investment.
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)
That’s not what the listed valuation is based on.
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.
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.
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.
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.
No way that’s worth as much as Airbnb
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.
Not to mention they are more regulatory compliant, and so likely deal with fewer lawsuits and have to spend less on lobbying.
> Not to mention they are more regulatory compliant
Source?
Source?
Here's a few:
https://www.jotform.com/blog/is-stripe-psd2-compliant/
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.”
https://www.paymentssource.com/news/stripes-next-step-is-bui...
Stripe hasn't exactly been in the news for lawsuits or controversy, unlike AirBnB.
https://www.jotform.com/blog/is-stripe-psd2-compliant/
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.”
https://www.paymentssource.com/news/stripes-next-step-is-bui...
Stripe hasn't exactly been in the news for lawsuits or controversy, unlike AirBnB.
Not being in the news has nothing to do with being regulatory complaint.
You’ve provided articles that Stripe is compliant, which is fine, but nothing there indicates that Airbnb isn’t compliant.
What regulations specifically is Airbnb breaking that Stripe isn’t?
You’ve provided articles that Stripe is compliant, which is fine, but nothing there indicates that Airbnb isn’t compliant.
What regulations specifically is Airbnb breaking that Stripe isn’t?
https://www.bloomberg.com/news/articles/2019-09-19/airbnb-ip...
https://www.wired.com/story/inside-airbnbs-guerrilla-war-aga...
https://www.epi.org/publication/the-economic-costs-and-benef...
https://www.wired.com/story/inside-airbnbs-guerrilla-war-aga...
https://www.epi.org/publication/the-economic-costs-and-benef...
First link: That's hosts not complying with the law, not Airbnb. There is a big difference between the two.
Second link: Still not in non-compliance with regulation, this is a story about lobbying.
Third link: Still not breaking any current regulations, it's about lawmakers considering regulating the business in the future.
Still looks like Airbnb is compliant with current regulations. Same as Stripe.
Second link: Still not in non-compliance with regulation, this is a story about lobbying.
Third link: Still not breaking any current regulations, it's about lawmakers considering regulating the business in the future.
Still looks like Airbnb is compliant with current regulations. Same as Stripe.
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.
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.
agree. Airbnb is overvalued.
[Stripe cofounder]
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): [email protected].
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.
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): [email protected].
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.
Congrats on Stripe. Producing and marketing for developers first is indeed a passionating topic.
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?
Well deserved. Stripe is and has been best in class and best in industry for years.
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.
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 [email protected] (and my email's [email protected]).
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 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?
[deleted]
Are the telecom and networking sectors subject to significantly more fraud than average? That seems... surprising
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.
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.
Grey market VoIP fraud
Twilio uses Stripe. So "telecom" per se is not banned.
Twilio almost certainly has a different agreement with Stripe than is standard, and Stripe commonly bans Telecom related services: https://news.ycombinator.com/item?id=20012656
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.
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.
What business are you in?
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.
SignalWire too should be able to use Stripe.
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.
SignalWire too should be able to use Stripe.
Here is Nitzan of Future Nine (a pure-VoIP company) stating that Stripe does not service VoIP providers: https://www.dslreports.com/forum/r29552956-
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."
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."
This is from 2014. I know several VoIP companies today that are using Stripe successfully.
Edwin (with Stripe) did just re-enable our account, I don't think we will use it, but its nice to not be banned!
You're welcome :)
one of the few that actually deserves it. thank you.
Besides your product, I thank you all at Stripe for setting an example of what real API/SDK documentation is.
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 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 had the same experience my first go at integrating Stripe.
I was able to accept donations in all the ways I wanted:
https://github.com/revddit/revddit/blob/master/lambda-src/do...
https://github.com/revddit/revddit/blob/master/src/pages/com...
I was able to accept donations in all the ways I wanted:
- using Netlify (free hosting, includes lambda)
- custom amounts
- one-time payment or recurring
- form on my own site
https://github.com/revddit/revddit/blob/master/lambda-src/do...
https://github.com/revddit/revddit/blob/master/src/pages/com...
> 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.
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.
Totally agree. I implemented stuff like Paypal and Adyen. Bit of a horror show. But even Stripe's API has some gotcha's.
I documented how I implemented Stripe for the SaaS I run quite extensively at https://blog.checklyhq.com/our-stripe-billing-implementation...
I documented how I implemented Stripe for the SaaS I run quite extensively at https://blog.checklyhq.com/our-stripe-billing-implementation...
A quick look at the documentation and I'm impressed and a little jealous. Do you know if this is a proprietary API doc generator similar to Swagger?
As far as I can tell, Stripe invented this type of documentation that you see everywhere else now.
Here’s a framework that helps generate documentation similar to Stripe’s: https://github.com/slatedocs/slate
> 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 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.
Meanwhile, PayPal’s CSV transaction export feature is still underdocumented and shows that an account’s transaction history is not immutable: https://money.stackexchange.com/questions/65917/calculating-...
> 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.
I completely agree - I consider Stripe the gold standard for an API. Best I've ever used.
Now if the fee was under 3% instead of being the very same price as Paypal, that would be a nice welcome bit of competition.
Their newly announced corporate credit card has good benefits (US only): https://stripe.com/en-ca/corporate-card
At least you get some cash back from expenses.
At least you get some cash back from expenses.
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.
Just listened to the How I Built This with you and your brother. Thanks for sharing your story there. Big fan of Stripe!
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!"
Customers still want PayPal though :(
Can't wait for Stripe to integrate PayPal as one of the options. Seems unlikely to happen, but I keep my fingers crossed.
Can't wait for Stripe to integrate PayPal as one of the options. Seems unlikely to happen, but I keep my fingers crossed.
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 ...
Their API is actually not bad.
The problem is with their libraries, sandbox and testing tools. Also, their support is a complete and utter clusterfuck.
But the API is OK.
The problem is with their libraries, sandbox and testing tools. Also, their support is a complete and utter clusterfuck.
But the API is OK.
I respect the scale of your ambition and the suite of services/products you guys offer to realize it.
I love the copy on Stripe's website. Who wrote it?
Godspeed.
I love the copy on Stripe's website. Who wrote it?
Godspeed.
> I love the copy on Stripe's website. Who wrote it?
It's not available at Stripe's home page. Would you mind sharing it? Thx
It's not available at Stripe's home page. Would you mind sharing it? Thx
"Copy" in this context is the text: https://en.wikipedia.org/wiki/Copy_(written)
So yes, it is available on the home page - it's the most important thing there!
So yes, it is available on the home page - it's the most important thing there!
What was your MVP that you were charging cards in a few weeks of start?
Kudos to Stripe on an amazing journey! Interesting to revisit the original HN submission of Stripe's launch:
https://news.ycombinator.com/item?id=3053883
https://news.ycombinator.com/item?id=3053883
Incredibly the API links from 2011 still work. Just followed one mentioned in that old discussion:
https://news.ycombinator.com/item?id=3054726
https://news.ycombinator.com/item?id=3054726
> Incredibly the API links from 2011 still work.
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.
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.
Just want to say your Connect product is INCREDIBLE. Our company couldn't function (at least not well and at scale) without it!
[deleted]
Patrick, the way Stripe continues to engage with Hacker News and remains true to its roots is an inspiration. Congratulations!
Thanks @pc for the last words!
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.
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.
Patrick, how do you approach reconciliation at Stripe?
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
Never had the chance to use Stripe, however back in the day I played stripe ctf. Best and most fulfilling 8 hours without a single break.
Thank you for the t-shirt and the most enjoyable ctf I had a chance to play!
Thank you for the t-shirt and the most enjoyable ctf I had a chance to play!
I've always heard Stripe is a great place to work as well. Have been considering applying for one of your remote positions. Congrats and keep it up!
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.
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.
Thanks
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.
Thanks
Federal legislation is required.
Not true.
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?
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?
I think the international expansion is still your weakest point. We've been waiting for Stripe in Romania for years now, and it's an EU country...
[deleted]
> 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.
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.
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.
[deleted]
What do you feel like you need if Stripe gives you capital for your future receivables for you to go hire more engineers?
They offered me capital. I'd prefer Stripe engineering in exchange for equity.
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...
[1] https://tomotcha.com for those interested.
[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).
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...
[1] https://tomotcha.com for those interested.
[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).
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.
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.
The rates themselves show on your receipts? Are you using some sort of plug-in? Could you forward me a receipt at [email protected]?
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.
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.
This is on top of my head, but I will forward you the relevant and exact information.
Some banks are extremely greedy and charge you for forex just because the merchant is not located in the same country, regardless of currency.
“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.
I know right?
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?
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?
> 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."
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."
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.
[deleted]
> [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?
What exit strategy if not IPO?
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?
What exit strategy if not IPO?
They're not ruling out an IPO in the future. They just don't have plans to do it right now.
I have no plans to buy ice cream, but that doesn't mean I'll never buy ice cream. In fact, it's highly likely I will buy ice cream at some point.
I have no plans to buy ice cream, but that doesn't mean I'll never buy ice cream. In fact, it's highly likely I will buy ice cream at some point.
Your competitor Adyen sits a few streets away from me in Amsterdam. Seems like a very thriving and interesting market you both operate in.
Congrats and best of luck!
Congrats and best of luck!
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.
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? [email protected]
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.
American banks are something else entirely.
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.
American banks are something else entirely.
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. :)
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. :)
> 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.
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 wonder if that's the reason they launched Braintree with a more sane API.
Nevermind, Braintree was acquired by Paypal in 2013.
Nevermind, Braintree was acquired by Paypal in 2013.
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.
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).
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 keeps your 2.9% also [1].
> 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.
[1]: https://stripe.com/docs/refunds
> 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.
[1]: https://stripe.com/docs/refunds
I know Stripe is in beta in India, but I don't see any other alternative better than PayPal. Or is there something?
> Or is there something?
Razorpay. It’s also a YC company. I think of it as essentially an India-focused Stripe clone, with UPI, netbanking, etc.
Razorpay. It’s also a YC company. I think of it as essentially an India-focused Stripe clone, with UPI, netbanking, etc.
That's awesome! Thanks.
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!
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!
I've always wondered: What was Stripe's actual MVP when they started? How did they MVP in a few weeks, and start charging cards?
[Random techie]
This makes total sense. Stripe is driving the example for OSS for all countries to follow.
Thank you Stripe Co-founders. I appreciate your work and effort to bring GH where it is today.
This makes total sense. Stripe is driving the example for OSS for all countries to follow.
Thank you Stripe Co-founders. I appreciate your work and effort to bring GH where it is today.
Anybody who doubts whether Stripe is worth $35B just needs to read this comments section
I don't think I've seen a unicorn get this much love from developers
I don't think I've seen a unicorn get this much love from developers
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.
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.
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.
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. :)
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 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
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. 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.
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.
[deleted]
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.
Amazing and congrats! I'm curious if anyone knows how much revenue/profit Stripe is making? Or is it all still under wraps?
Please allow international, independent charges/transfers. This is a huge pain point in our Stripe experience.
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!
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.
Can get a higher multiple from VCs probably.
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. :)
I wasn't expecting a reply, but it was nice to get one. I was just venting my frustration.
Panama, Central America. I signed up for the email notification - years ago :)
Panama, Central America. I signed up for the email notification - years ago :)
Not OP but I know a bunch of South African makers who'd love to be using Stripe instead of our alternatives.
Romania is waiting for Stripe too! Guys, please. What is the hold-up?! It's all EU anyway...
Well deserved. They are actually trying to do good + interesting scaling challenges by enabling small business all over the world.
Here's their original Hacker News post, which is always a fascinating read: https://news.ycombinator.com/item?id=3053883
> 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)
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)
So their business is still not sustainable without outside funding? Why do they need training wheels?
I still wish I could accept multiple currencies with strip without conversion and spend them via a CC. Only reason I am still with PayPal
I'm calling it now. New bubble.
also their support for startups via their communities, atlas, and weekly free feeback is what truly makes them shine. keep up the great work!
This is a very reasonable value.
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 [email protected] with how many you need (feel free to CC me at [email protected]).
(BTW, if you didn't see, we have a $59 device too. We're also working on supporting more.)
(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.
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.
Why doesn't Stripe want to become a public company?