Building a Developer Cult(subvert.substack.com)
subvert.substack.com
Building a Developer Cult
https://subvert.substack.com/p/stripe-building-a-developer-cult
131 comments
This article read like a puff piece that I got little more out of than "value your users and build good software". It didn't seem like it offered much substantial or specific advice.
Agreed. There's very little evidence to support the claims about what is discussed here is what made Stripe successful. Intuitively many of the claims seem true but where is the data?
There has been a huge influx of articles from substack lately. I think they are trying to grow their brand.
Substack is just a publishing platform, it's not editorial.
Doesn't mean they're not submitting articles around to grow awareness of the platform/their brand.
There's probably a bit of "know who your users are".
Ultimately the "ease of use" thing is valuable to the developers (the stakeholders above couldn't care less), and Stripe seemed to identify that getting developer buy-in is super valuable for at least one segment of the population
Ultimately the "ease of use" thing is valuable to the developers (the stakeholders above couldn't care less), and Stripe seemed to identify that getting developer buy-in is super valuable for at least one segment of the population
What makes Stripe good now is what made it good way back when they first launched: Handling payments sucks and they make it suck less.
The design, etc. is the gravy on top of a successful runaway train.
The design, etc. is the gravy on top of a successful runaway train.
The remarkable thing about the culture around Stripe is that they still get the credit for the things they did well in those early days, even though they are far from the same service now that they've scaled up.
Objectively, today's Stripe is often a relatively expensive and unreliable way to collect money from your customers. The API and developer documentation are no longer as simple and effective as they once were, particularly if you need things like PSD2. Something fundamentally changed about Stripe's support a few years ago, and it seemed like almost overnight they went from routinely having knowledgeable people replying with helpful suggestions to having people who can't even be bothered to read your message before hitting whatever button sends boilerplate reply #74 with platitudes #27 and #53 at the start and end.
Much of this is understandable. Obviously you're not going to get senior people from an organisation the size of Stripe today personally responding to messages the way they used to. Some of the complexity due to PSD2 itself has been forced on them. Appealing to a wider range of merchants with more diverse needs is inevitably going to make some parts of the system more complicated.
However, the hero worship they still seem to enjoy in various forums, including this one, is remarkably cult-like now. Recommending the Stripe you remember from days gone by, particularly if you haven't recently used any of the other services now competing for the online payments market, might even be harmful to those starting small businesses today, who might be better served by one or more of the alternatives and should at least be considering the full range of options available to them.
Objectively, today's Stripe is often a relatively expensive and unreliable way to collect money from your customers. The API and developer documentation are no longer as simple and effective as they once were, particularly if you need things like PSD2. Something fundamentally changed about Stripe's support a few years ago, and it seemed like almost overnight they went from routinely having knowledgeable people replying with helpful suggestions to having people who can't even be bothered to read your message before hitting whatever button sends boilerplate reply #74 with platitudes #27 and #53 at the start and end.
Much of this is understandable. Obviously you're not going to get senior people from an organisation the size of Stripe today personally responding to messages the way they used to. Some of the complexity due to PSD2 itself has been forced on them. Appealing to a wider range of merchants with more diverse needs is inevitably going to make some parts of the system more complicated.
However, the hero worship they still seem to enjoy in various forums, including this one, is remarkably cult-like now. Recommending the Stripe you remember from days gone by, particularly if you haven't recently used any of the other services now competing for the online payments market, might even be harmful to those starting small businesses today, who might be better served by one or more of the alternatives and should at least be considering the full range of options available to them.
> Something fundamentally changed about Stripe's support a few years ago, and it seemed like almost overnight they went from routinely having knowledgeable people replying with helpful suggestions to having people who can't even be bothered to read your message before hitting whatever button sends boilerplate reply #74 with platitudes #27 and #53 at the start and end.
I've found that their email support is far better than their live chat support (and I assume phone support too). The last time I used their live chat support I had a confusing back and forth until being told to just use email support.
I've found that their email support is far better than their live chat support (and I assume phone support too). The last time I used their live chat support I had a confusing back and forth until being told to just use email support.
> Something fundamentally changed about Stripe's support a few years ago, and it seemed like almost overnight they went from routinely having knowledgeable people replying with helpful suggestions to having people who can't even be bothered to read your message before hitting whatever button sends boilerplate reply #74 with platitudes #27 and #53 at the start and end.
That's definitely my experience with Stripe support over the years, too. A definite degradation. Really annoying.
That's definitely my experience with Stripe support over the years, too. A definite degradation. Really annoying.
> The remarkable thing about the culture around Stripe is that they still get the credit for the things they did well in those early days, even though they are far from the same service now that they've scaled up.
This describes the broader Silicon Valley tech scene quite well too.
People worship others for founding/funding X company, being employee #Y at a certain unicorn, creating a cool feature 5+ years ago for a dead app, etc.
This describes the broader Silicon Valley tech scene quite well too.
People worship others for founding/funding X company, being employee #Y at a certain unicorn, creating a cool feature 5+ years ago for a dead app, etc.
This is my experience too.
> who might be better served by one or more of the alternatives and should at least be considering the full range of options available to them.
Which alternatives should I consider, if I need PSD2? I've written about my experience with Braintree above; there's SagePay but every client has been pleased to move away from them.
> who might be better served by one or more of the alternatives and should at least be considering the full range of options available to them.
Which alternatives should I consider, if I need PSD2? I've written about my experience with Braintree above; there's SagePay but every client has been pleased to move away from them.
PSD2 implies Europe, so my first question is whether to accept cards as the primary means of payment at all. The various direct payment schemes are typically cheaper, more reliable and, in some countries, much more widely used. If you are handling recurring billing via a Direct Debit scheme then you are probably also outside the scope of the SCA rules that are going to interrupt payment flows using cards whenever the EU member states finally insist on following them.
I've used GoCardless to do some of this, but depending on where you are based, there seem to be quite a few other services now that offer some or all of the relevant schemes.
I've used GoCardless to do some of this, but depending on where you are based, there seem to be quite a few other services now that offer some or all of the relevant schemes.
UK based here, so for most projects I/clients want cards as the primary payment method due to the audience as they are one-off payments.
I've used GoCardless on one project; as the developer I didn't enjoy the experience at all. Setting up testing for all states was painful (as was getting items to the right state to use their scenario simulator). I see Stripe have rolled out UK Direct Debit support now; hopefully their documentation and testing story are better than GoCardless.
I've used GoCardless on one project; as the developer I didn't enjoy the experience at all. Setting up testing for all states was painful (as was getting items to the right state to use their scenario simulator). I see Stripe have rolled out UK Direct Debit support now; hopefully their documentation and testing story are better than GoCardless.
I certainly agree that testing these integrations is unnecessarily painful, but given that both Stripe and GoCardless offer much the same facilities -- a single sandbox environment, but without comprehensive simulation of all important scenarios and with nothing useful for either automated integration testing or offline simulation at the developer's desk -- I'm not sure I'd say either is much better than the other. The only major difference I can think of is that since they simulate roughly realistic timing as well, GoCardless can also take several days to complete a test run for a new integration or bug fix, which is obviously absurd.
This is mostly it.
Before Stripe payment processing was abysmal. There was no thought at all given to the developer/implementer experience.
Stripe basically put a clean and straight forward API and product around the mess.
I know java is 'not cool' but it feels like javadocs in 2002 which are generally well organised by virtue of myriad of conventions, as opposed to docs in some other langs. which can be hit and miss, though getting better.
Stripe is a pretty good example of good product experience for those having to 'do the work', because they will likely have a lot of say in it, in the long run.
Before Stripe payment processing was abysmal. There was no thought at all given to the developer/implementer experience.
Stripe basically put a clean and straight forward API and product around the mess.
I know java is 'not cool' but it feels like javadocs in 2002 which are generally well organised by virtue of myriad of conventions, as opposed to docs in some other langs. which can be hit and miss, though getting better.
Stripe is a pretty good example of good product experience for those having to 'do the work', because they will likely have a lot of say in it, in the long run.
I second that!
Look, I know that the idea of being customer focused might seem trite, but I wanted to focus on one thing: it's the little things.
"What actually differentiates stripe from the rest of the bunch though? It’s the little things.Stripe obsesses over creating a seamless CX. Small annoyances in applications compound. A user might not churn immediately because you have a bunch of unoptimized functionality or crappy UX, but it’s a recipe to create a grumpy user. And grumpy users aren’t loyal users."
This is an idea I've been turning over in my head a bunch recently: the compounding effects of delighting your users. That cumulative innovation that comes from building for your customers....I sometimes get asked "what's the killer idea behind [company X]". But there isn't one big thing. There are many, many small things built on having a relentlessly customer-back attitude. You can't just copy the "idea", you have to copy the way of working and thinking. That's a lot harder.
Let's take Brex as another example. It's the segmentation, UX, marketing, rewards, underwriting, etc. It's each of those things broken up into a hundred subcomponents and iterated on. It's an entire ethos and operating model. That's cumulative innovation...not a single idea.
"What actually differentiates stripe from the rest of the bunch though? It’s the little things.Stripe obsesses over creating a seamless CX. Small annoyances in applications compound. A user might not churn immediately because you have a bunch of unoptimized functionality or crappy UX, but it’s a recipe to create a grumpy user. And grumpy users aren’t loyal users."
This is an idea I've been turning over in my head a bunch recently: the compounding effects of delighting your users. That cumulative innovation that comes from building for your customers....I sometimes get asked "what's the killer idea behind [company X]". But there isn't one big thing. There are many, many small things built on having a relentlessly customer-back attitude. You can't just copy the "idea", you have to copy the way of working and thinking. That's a lot harder.
Let's take Brex as another example. It's the segmentation, UX, marketing, rewards, underwriting, etc. It's each of those things broken up into a hundred subcomponents and iterated on. It's an entire ethos and operating model. That's cumulative innovation...not a single idea.
I'll warn against getting way too focused on this as an early company.
Getting something up and running is often waaaaaay more valuable then achieving Stripe level UX from the outset, and then as time progresses you must make a conscious effort to improve. Remember, Stripe has been an app for about a decade. That's a decade's worth of learning what users care about and what details matter. And clearly that's a decade to polish a product to near perfection.
A trap I've fallen in myself, and I see /a lot/ is that people focus on delighting their users before they even know what delights their users or what their users care about. Often you'll only learn that by having a product that works and customers need from the outset.
Getting something up and running is often waaaaaay more valuable then achieving Stripe level UX from the outset, and then as time progresses you must make a conscious effort to improve. Remember, Stripe has been an app for about a decade. That's a decade's worth of learning what users care about and what details matter. And clearly that's a decade to polish a product to near perfection.
A trap I've fallen in myself, and I see /a lot/ is that people focus on delighting their users before they even know what delights their users or what their users care about. Often you'll only learn that by having a product that works and customers need from the outset.
That's fair and valid, but shifting your culture from one that's laser-focused on shipping features that work to one that cares about shipping polished features that delights users definitely gets exponentially harder as your company scales in size.
The sweet-spot for making that transition is essentially as soon as you've found product-market fit, no later and no sooner, and missing that sweet spot even a little bit can make the transition very difficult and very costly. But the dilemma is, as most successful founders will likely tell you, we're only good at identifying product-market fit in hindsight, long after it happens (and it may never actually happen).
I've worked at plenty of companies that pay lip service to wanting to ship polished features that delight users while still overwhelmingly shipping features in a very utilitarian, timeline dominated fashion, long past the point where they've demonstrated product market fit.
As with anything in product/engineering/design, it's all about tradeoffs and striking the right balance, and where the right balance stands will always keep shifting under your feet as you make progress...
The sweet-spot for making that transition is essentially as soon as you've found product-market fit, no later and no sooner, and missing that sweet spot even a little bit can make the transition very difficult and very costly. But the dilemma is, as most successful founders will likely tell you, we're only good at identifying product-market fit in hindsight, long after it happens (and it may never actually happen).
I've worked at plenty of companies that pay lip service to wanting to ship polished features that delight users while still overwhelmingly shipping features in a very utilitarian, timeline dominated fashion, long past the point where they've demonstrated product market fit.
As with anything in product/engineering/design, it's all about tradeoffs and striking the right balance, and where the right balance stands will always keep shifting under your feet as you make progress...
There is one way to make sure the product improves after shipping a quick-and-dirty first version: dog-fooding.
Be a user, for real. Many seem to think that just using the product equals dog-fooding, but real dog-fooding is when you can honestly say you get real value out of using the product. It is when you'd pay to use it.
When you use your own product and gets value out of doing so, you have true customer perspective and your needs are aligned with your customers needs.
Be a user, for real. Many seem to think that just using the product equals dog-fooding, but real dog-fooding is when you can honestly say you get real value out of using the product. It is when you'd pay to use it.
When you use your own product and gets value out of doing so, you have true customer perspective and your needs are aligned with your customers needs.
> A trap I see /a lot/ is that people focus on delighting their users before they even know what delights their users or what their users care about.
That's odd. The point of focusing on users is to discover what users want. If you're not doing then you're not really focused on users.
That's odd. The point of focusing on users is to discover what users want. If you're not doing then you're not really focused on users.
But "focusing on users" != "focus on delighting their users". The former is the process of discovering what delights their users, the latter is the actual "delighting" process.
Also, +1 to the parent comment. I worked at a startup where we made exactly that mistake - we delayed releases until it met a high standard of UX - took us more than couple of years. By this time, competitors that built a _much_ crappier product got userbase, and hence funding, and then used that to get their UX up to par (sometimes they wouldn't even have the features, they just faked it). We realized our mistake, adapted and stayed in business - but it was a difficult and painful process.
So basically - first get things up and running FAST, then worry about polish and laser-cut UX.
Also, +1 to the parent comment. I worked at a startup where we made exactly that mistake - we delayed releases until it met a high standard of UX - took us more than couple of years. By this time, competitors that built a _much_ crappier product got userbase, and hence funding, and then used that to get their UX up to par (sometimes they wouldn't even have the features, they just faked it). We realized our mistake, adapted and stayed in business - but it was a difficult and painful process.
So basically - first get things up and running FAST, then worry about polish and laser-cut UX.
> But "focusing on users" != "focus on delighting their users". The former is the process of discovering what delights their users, the latter is the actual "delighting" process.
If these two things are not equal then you're doing it wrong.
If these two things are not equal then you're doing it wrong.
I think the point is you can easily get so focused on making the experience "delightful" that you work on things that would delight you, but that your users actually don't care about so much. And you need to take a step back, build something functional but not necessarily completely "delightful" & then figure out what your initial users actually do care about and iterate from there
I think of it like listen to your users, but don’t do everything they ask. Use your judgement to make sure it aligns with your goals, and hopefully you have a goal beyond ‘make monies’.
Additionally, think about why they're asking for a certain thing, and whether their request is really the best way to solve the underlying problem they want solved
“Treat your users as you would a class of pre-school children. If they’re all screaming for a snack you don’t necessarily give them one, perhaps a healthy lunch would be better for the underlying need.”
I don't think pre-school children are the only people who are poor at recognising or expressing what they really want, I think that's a fairly universal thing. It's very easy to get an idea about what the solution should be & make a request based on that rather than basing the request on the problem you're facing.
A good analogy I heard recently (more to do with planning your own projects than requesting stuff in other people's, but I think it still works): imagine you have a large patch of grass and it is taking too long to cut. There are a couple of ways to define that problem:
* I need a better lawnmower
* I need a better way to cut grass
The first locks you in to a particular solution (lawnmower), but there may be a better possible solution out there, and the second statement opens it up a bit. So bringing that back to the user request thing, if your user requests a better lawnmower, make sure there isn't some better way to have the grass cut instead.
A good analogy I heard recently (more to do with planning your own projects than requesting stuff in other people's, but I think it still works): imagine you have a large patch of grass and it is taking too long to cut. There are a couple of ways to define that problem:
* I need a better lawnmower
* I need a better way to cut grass
The first locks you in to a particular solution (lawnmower), but there may be a better possible solution out there, and the second statement opens it up a bit. So bringing that back to the user request thing, if your user requests a better lawnmower, make sure there isn't some better way to have the grass cut instead.
I have understood over years that, below listed things typically lead to "grand success" or "cults" [ tech or otherwise - but then, eveyrthing is "tech" now anyway!]
1. Enterprise readiness (in order of precedence: real business value [either brings money or saves good chunk of money], robustness, usability, integration capabilities, ease of on-onboarding, simpelr path to value-maximization. Good to haves: delightful user experience, great documentation)
2. Developer delight: The ecosystem (=> tools, platforms, training, autonomy, agency, motivation via empathetic management) offered to developers, in order to make them super effective, productive and efficient - to cater to the above listed. Note: "Developers" include Ops and Tech Support personnel too!
3. Customer delight: The above two leads to "customer delight" They see that the tool/solution clearly brings value, and that the support team is able to deliver the same as well - sustainably and happily.
This leads to a great win - for vendor and customer.
Building such an ecosystem is not a trivial or simple thing. Takes years, decades even.
In the end, that cutl gets formed - thanks to those ingredients that continuously keep "wow"ing the makers and the users. The "stuff" takes the limelight, but that's just proxy for the makers, their tools, skills and motivation.
This applies not just for software, but for many others! People value Toyota because Toyota's entire organization structure and inclination is on those lines - to 'drive' better value for consumers and their own people who offer'em.
1. Enterprise readiness (in order of precedence: real business value [either brings money or saves good chunk of money], robustness, usability, integration capabilities, ease of on-onboarding, simpelr path to value-maximization. Good to haves: delightful user experience, great documentation)
2. Developer delight: The ecosystem (=> tools, platforms, training, autonomy, agency, motivation via empathetic management) offered to developers, in order to make them super effective, productive and efficient - to cater to the above listed. Note: "Developers" include Ops and Tech Support personnel too!
3. Customer delight: The above two leads to "customer delight" They see that the tool/solution clearly brings value, and that the support team is able to deliver the same as well - sustainably and happily.
This leads to a great win - for vendor and customer.
Building such an ecosystem is not a trivial or simple thing. Takes years, decades even.
In the end, that cutl gets formed - thanks to those ingredients that continuously keep "wow"ing the makers and the users. The "stuff" takes the limelight, but that's just proxy for the makers, their tools, skills and motivation.
This applies not just for software, but for many others! People value Toyota because Toyota's entire organization structure and inclination is on those lines - to 'drive' better value for consumers and their own people who offer'em.
You need both; you need a solid core, a reliable and fast service - both in the literal sense (e.g. back-end services) and in the figurative (your business process, so to speak), and on top of that you need to build a solid user experience.
And that's still not all, you ALSO need to do marketing and sales.
To take an example, there's about a bajillion 'todo' or 'notes' apps, I think because they are easy - simple data models, at the core. Because that is finished quickly, developers focus on the UI / UX, which is extra emphasized because they often live in the Mac / iOS atmospheres.
Some will do marketing on top of that, pretty landing pages, get featured in the app store and the low effort app news sites. But there's a lot (on HN for example) that miss out on that.
But that's just one highly competed area, there's not much you can do now to get a foot in the door - it's not a market "ripe for disruption" as the HN crowd likes to say.
Financial transactions on the other hand is really hard to get right at the core. Adyen is doing a pretty decent job there, I'm sure Stripe does as well, but they emphasize more on the UX and smaller customers. There's also others like Buckaroo, Icepay, MultiSafepay, and a couple others.
And that's still not all, you ALSO need to do marketing and sales.
To take an example, there's about a bajillion 'todo' or 'notes' apps, I think because they are easy - simple data models, at the core. Because that is finished quickly, developers focus on the UI / UX, which is extra emphasized because they often live in the Mac / iOS atmospheres.
Some will do marketing on top of that, pretty landing pages, get featured in the app store and the low effort app news sites. But there's a lot (on HN for example) that miss out on that.
But that's just one highly competed area, there's not much you can do now to get a foot in the door - it's not a market "ripe for disruption" as the HN crowd likes to say.
Financial transactions on the other hand is really hard to get right at the core. Adyen is doing a pretty decent job there, I'm sure Stripe does as well, but they emphasize more on the UX and smaller customers. There's also others like Buckaroo, Icepay, MultiSafepay, and a couple others.
I think you might be missing the point the article was trying to make when you took the negative emotion which the author was describing (“annoyances”) and turned it into a positive one (“delight”). I don’t think you can simply say delight is the absence of annoyance, and that good applications are ones which delight their users.
Because while delightful interactions can wow your users and get them to tweet about your application, the mark of a great user experience is that it goes largely unnoticed by the user. You don’t notice a door when you walk through it; you’d only notice it if you couldn’t get through it. We only pay attention to tools when things go wrong; as developers we are keenly aware of this fact whenever we have to debug code which stops working.
A seamless user experience should actually be imperceptible to the user, and I’m not sure this has anything to do with delightfulness or juiciness or any of the other stretch goals UI people come up with. The fact of the matter is, not annoying the user isn’t as sexy, and boils down to competence (writing bug-free code) and consent (not using dark patterns to get the user to do shit they don’t want to do).
Because while delightful interactions can wow your users and get them to tweet about your application, the mark of a great user experience is that it goes largely unnoticed by the user. You don’t notice a door when you walk through it; you’d only notice it if you couldn’t get through it. We only pay attention to tools when things go wrong; as developers we are keenly aware of this fact whenever we have to debug code which stops working.
A seamless user experience should actually be imperceptible to the user, and I’m not sure this has anything to do with delightfulness or juiciness or any of the other stretch goals UI people come up with. The fact of the matter is, not annoying the user isn’t as sexy, and boils down to competence (writing bug-free code) and consent (not using dark patterns to get the user to do shit they don’t want to do).
If you work in an organization where this isn't the norm-- do you try and change it, or is it best to move on? Sometimes, it feels difficult knowing I made one corner of the product great when there's glaring issues elsewhere, and my team doesn't have the bandwidth (or jurisdiction) to fix all of it.
If this is a result of poor execution then I'd stay and change it. If instead it's a result of a cultural or company vision that does not embrace focusing on the customer, their problem (not just your opinion of it), and working constantly towards solving the problem then you should bail.
I spent a lot of years in several companies thinking I could correct a bad vision or culture, and unless you're the CEO you can't. Poor execution of a good vision/culture is always correctable, although you should consider what is the root cause of that poor execution... often it's personnel.
I spent a lot of years in several companies thinking I could correct a bad vision or culture, and unless you're the CEO you can't. Poor execution of a good vision/culture is always correctable, although you should consider what is the root cause of that poor execution... often it's personnel.
Was hoping to read about developers participating in Stripe themed rituals that resemble Eyes Wide Shut, a UFO cult, or an End-of-Days Revelation cult. Instead, it's just something about executing business processes with customers and good documentation. American business culture is something to behold.
Building developer enthusiasm and passion? that's great. That's what Stripe is doing, and I'm happy about that.
Please don't call that a cult though.
Please don't call that a cult though.
Indeed. It is very off-putting. Developer cults do more damage to the developer community than not.
I love stripe and they really do have some excellent designs, but that one screenshot is pretty awful. The contrast between the text and the rainbow image is so poor that it looks like a mistake rather than an intentional design choice.
Agree, I think they accidentally swapped the layers in Sketch or Photoshop or something. Or maybe that’s some cult thing!
It's one of those weird swirly gradient things, not really my cup of tea, but it looks _a lot_ better animated, on the page than the still.
https://stripe.com/, though I don't suppose anyone is going to have difficulty finding the stripe homepage.
https://stripe.com/, though I don't suppose anyone is going to have difficulty finding the stripe homepage.
It's a bit weird but the point was that it was striking rather than a dull flat design with a lot of dark colors
There was a long time when Stripe was taking a significantly higher transaction fee than most other merchants for cc transactions yet there still was fervent developer push to use it anyways (Note, this hasn't been true for a few years and was only true during the first year or two of Stripe's life).
People made all kinds of rationalizations to themselves for using stripe at a much higher cost simply because they didn't want to spend a couple more hours using crappier API's or digging through crappier API documentation.
It made no sense to me at the time because while Stripe was nice, it was usually only a matter of a couple hours/days to implement any of the other big payment processors of the time. I guess that shows what the power of cultish developer zeitgeist can do.
People made all kinds of rationalizations to themselves for using stripe at a much higher cost simply because they didn't want to spend a couple more hours using crappier API's or digging through crappier API documentation.
It made no sense to me at the time because while Stripe was nice, it was usually only a matter of a couple hours/days to implement any of the other big payment processors of the time. I guess that shows what the power of cultish developer zeitgeist can do.
My first business that used Stripe was with them from their early days in the UK, and my recollection is very different to yours. They were potentially a bit more expensive in terms of fees than getting a separate merchant account and payment gateway set up, but not hugely so and at least they were consistent and transparent about those fees.
Moreover, they were vastly different in terms of the ease of integration. To take card payments via the traditional big banks and other established services, you didn't just have to put up with awful APIs and worse documentation, you also had to put up with onerous application processes that could take days to collect the required information to apply, then weeks to approve (or not), and even then often imposed severe restrictions for businesses with no trading history up to and including piercing agreements for company officers, large and long-lasting reserves being withheld, etc. The only other game in town for setting up online card payments reasonably quickly and easily at that time was PayPal, which had a reputation somewhere between Satan and the devil even then.
Of course none of this is unique today, and there are now many other services available for taking payments via card or many other methods. But in those days, it truly was a game-changer. As much as I criticise Stripe for its more recent failures, I also give credit where it's due: many small businesses, including at least one of my own, would not have gotten off the ground as early as they did without Stripe.
Moreover, they were vastly different in terms of the ease of integration. To take card payments via the traditional big banks and other established services, you didn't just have to put up with awful APIs and worse documentation, you also had to put up with onerous application processes that could take days to collect the required information to apply, then weeks to approve (or not), and even then often imposed severe restrictions for businesses with no trading history up to and including piercing agreements for company officers, large and long-lasting reserves being withheld, etc. The only other game in town for setting up online card payments reasonably quickly and easily at that time was PayPal, which had a reputation somewhere between Satan and the devil even then.
Of course none of this is unique today, and there are now many other services available for taking payments via card or many other methods. But in those days, it truly was a game-changer. As much as I criticise Stripe for its more recent failures, I also give credit where it's due: many small businesses, including at least one of my own, would not have gotten off the ground as early as they did without Stripe.
U.K. was probably different, but in my mind both Authorize.net and PayPal were the established players in the US market for online credit card transactions before Stripe.
Authorize.net was (and still is) a "gateway" - you pick the merchant and use Authorize.net for the actual technical layer of processing a transaction - which was kind of a confusing concept, but there were plenty of merchants on authorize.net's marketplace that had much better rates than Stripe. I don't recall there being an onerous application process or the restrictions you mentioned, but it could be that I was shielded from that side of things.
Both Authorize.net and PayPal had pretty gross API's (and documentation) but they were pretty solid once you got them working. Obviously it depends on the nature of your business, but saving even 10 cents per transactions goes a long ways for many and quickly justifies a day or even a week of additional coder time. It wasn't that onerous of a task to implement one of the non-Stripe options.
Paypal of course was it's own beast with it's insanely draconian policies towards account holders, but I never had to deal with that (luckily).
Authorize.net was (and still is) a "gateway" - you pick the merchant and use Authorize.net for the actual technical layer of processing a transaction - which was kind of a confusing concept, but there were plenty of merchants on authorize.net's marketplace that had much better rates than Stripe. I don't recall there being an onerous application process or the restrictions you mentioned, but it could be that I was shielded from that side of things.
Both Authorize.net and PayPal had pretty gross API's (and documentation) but they were pretty solid once you got them working. Obviously it depends on the nature of your business, but saving even 10 cents per transactions goes a long ways for many and quickly justifies a day or even a week of additional coder time. It wasn't that onerous of a task to implement one of the non-Stripe options.
Paypal of course was it's own beast with it's insanely draconian policies towards account holders, but I never had to deal with that (luckily).
I am sure many developers don't remember just how much crappier the "crappier APIs" were. Back when Stripe became popular the alternative was XML and SOAP, documented in an outdated PDF that would get emailed to you, or if you're lucky, hosted behind 3 login walls. Then, once you start integrating, you realize that their dev environment is offline every other request, and doesn't match the production environment. So you just do the work blindly and hope for the best.
Having a decent publicly documented API was revolutionary.
Having a decent publicly documented API was revolutionary.
That’s not really true though. Both PayPal and Authorize.net had a REST API when Stripe came out.
I recently built a Stripe integration, and can't say I'm especially impressed.
Unless I completely missed some aspects, it mostly just seems like an interface to their database. While this is great for some advanced workflows, the vast majority of use cases are all very similar: "create subscription and customer", "change subscription", etc. Common workflows require quite some coding, and there's no support for transactions! IMO a good API design should be more thoughtful than providing an interface to your database.
I don't think the documentation is especially well written, although it's not bad either. What's worse is that the stripe API docs hijacks my CTRL+F key so using my browser search is a massive PITA. This is such a fucking annoying fucking thing that I'll break my "don't say fuck on discussion forums"-rule for this. I fucking hate it. I tried disabling JS but that results in every navigation doing a full page refresh which easily takes over 5 seconds.
Also, browsing the docs isn't super slow or anything, but it's also not quite fast enough to feel "natural".
The checkout docs actually are pretty meh. Much of it is written in "tutorial" form and unclear on details.
As for the site design ... it often takes >5 seconds to load anything after clicking and it easily uses more than 100M of memory per tab. I recently wanted to load a bunch of customers so I opened them in about 10 different and my entire laptop just ground to a halt. I've actually been procrastinating on some Stripe stuff I need to do for the last week because I dislike using the UI so much.
Is it all absolutely terrible? No; it's passable, I guess. But do I share any of the enthusiasm in this article? Not even close.
Unless I completely missed some aspects, it mostly just seems like an interface to their database. While this is great for some advanced workflows, the vast majority of use cases are all very similar: "create subscription and customer", "change subscription", etc. Common workflows require quite some coding, and there's no support for transactions! IMO a good API design should be more thoughtful than providing an interface to your database.
I don't think the documentation is especially well written, although it's not bad either. What's worse is that the stripe API docs hijacks my CTRL+F key so using my browser search is a massive PITA. This is such a fucking annoying fucking thing that I'll break my "don't say fuck on discussion forums"-rule for this. I fucking hate it. I tried disabling JS but that results in every navigation doing a full page refresh which easily takes over 5 seconds.
Also, browsing the docs isn't super slow or anything, but it's also not quite fast enough to feel "natural".
The checkout docs actually are pretty meh. Much of it is written in "tutorial" form and unclear on details.
As for the site design ... it often takes >5 seconds to load anything after clicking and it easily uses more than 100M of memory per tab. I recently wanted to load a bunch of customers so I opened them in about 10 different and my entire laptop just ground to a halt. I've actually been procrastinating on some Stripe stuff I need to do for the last week because I dislike using the UI so much.
Is it all absolutely terrible? No; it's passable, I guess. But do I share any of the enthusiasm in this article? Not even close.
I think you're seeing what the benefit is, though: it feels like you're just using an API to some company's DB.
Payment processing is one area is that just a complete nonstarter to homebrew on your own. It's fucking awful. There's no choice. Bank's still require you to transfer them files via ftp to make transactions.
And god forbid the legal, and technical mess when you want to accept foreign currency, or even multiple CC providers.
Payment processing is one area is that just a complete nonstarter to homebrew on your own. It's fucking awful. There's no choice. Bank's still require you to transfer them files via ftp to make transactions.
And god forbid the legal, and technical mess when you want to accept foreign currency, or even multiple CC providers.
Work in fintech, can confirm. Moving money around the global banking system is a pus-drenched no man's land of technological anguish and despair. Every time you think you've seen the worst of it, you find out you were wrong.
Agreed. I had to implement a transaction audit using SOAP in 2019.
We actively maintain multiple SOAP servers so an OEM can connect as a client, and send us data.
The OEM required us to stand-up the servers so they could send us the data.
We also still use FTP for some vendors (we host).
The OEM required us to stand-up the servers so they could send us the data.
We also still use FTP for some vendors (we host).
Cryptocurrency gets a bad rap here (most of it rightfully so), but one thing is for sure, once you use it you realize how broken digital payment infrastructure is. With crypto, I can trivially send any amount of money very cheaply across any sort of borders. Also, accepting crypto as a merchant is extremely easy even to roll your own custom solution.
Yeah, I have no doubt that it's better than what the banks are offering.
"Homebrew on your own" is more or less what Stripe's API felt like though; the perspective I'm coming from is that I run a little one-person SaaS company with a simple and fairly standard subscription model, and I was surprised by the amount of "plumbing" you need to do for this.
"Homebrew on your own" is more or less what Stripe's API felt like though; the perspective I'm coming from is that I run a little one-person SaaS company with a simple and fairly standard subscription model, and I was surprised by the amount of "plumbing" you need to do for this.
That's why companies like Paddle.com exist.
I used them for a side project. Once you find the right documentation it's straightforward to integrate, but finding it took 3 days and 2 support requests.
I used them for a side project. Once you find the right documentation it's straightforward to integrate, but finding it took 3 days and 2 support requests.
(Edwin from Stripe here.) Most people like our built-in search since it lets you quickly navigate and see related things. But if you don't, you can hit Ctrl+F+F to use native browser search. You can turn it off entirely by unchecking "Open on Ctrl-F."
Docs now save to your cache, so loading should feel pretty immediate.
What should we be more clear about in the Checkout docs? We're working on improving them, but it'd be useful to hear what you think. (Could you email me [[email protected]] and [email protected]?)
We also made the Stripe Dashboard 20% faster since March. There's more work to be done here, though—and performace (specifically the customer page) is at the top of the list.
Docs now save to your cache, so loading should feel pretty immediate.
What should we be more clear about in the Checkout docs? We're working on improving them, but it'd be useful to hear what you think. (Could you email me [[email protected]] and [email protected]?)
We also made the Stripe Dashboard 20% faster since March. There's more work to be done here, though—and performace (specifically the customer page) is at the top of the list.
Hi Edwin. Will you guys ever add the ability to "pause" subscriptions? The only way to do that right now is to resort to various "hacks", such as adding a 100% discount coupon and then taking it off when unpausing.
Yes! We added this in March: https://stripe.com/docs/billing/subscriptions/pause.
I just started implementing checkout in Rails on a side project and the step by step docs don't cover CORS and CSP. I get a bunch of errors. Really the docs should cover every little detail leaving nothing to be researched. Any time I follow a how to doc that leaves details out I lose flow which in turns slows me down and makes me less happy.
As much as I love Stripe, I agree with you. Just did a Stripe Checkout implementation :
- Checkout docs are definitely not good, there is a "Getting started" and then good luck
- the CTRL+F hijack is the most annoying thing I've stumbled upon recently. Please don't do that.
- Checkout docs are definitely not good, there is a "Getting started" and then good luck
- the CTRL+F hijack is the most annoying thing I've stumbled upon recently. Please don't do that.
If you cmd+f twice in a row that should bypass you to your browser’s native search. There’s also a toggle in the search UI so that you can opt out of the modal entirely and go straight to browser search every time. It’s in the bottom right corner of the search modal iirc (writing this comment from mobile).
Disclosure: I work at Stripe. Will pass this feedback along :)
Disclosure: I work at Stripe. Will pass this feedback along :)
" it mostly just seems like an interface to their database. "
Payments are a huge, institutional mess under the hood, what they offer is light years better than what was there previously.
Honestly it's what 'you don't see' that's the good part.
Payments are a huge, institutional mess under the hood, what they offer is light years better than what was there previously.
Honestly it's what 'you don't see' that's the good part.
It helps that basically the only other option, PayPal, is a complete disaster.
So, even if Stripe is suboptimal, everybody is so much happier to be away from PayPal that they're ecstatic.
It's the equivalent of having a mediocre sandwich when you're starving.
So, even if Stripe is suboptimal, everybody is so much happier to be away from PayPal that they're ecstatic.
It's the equivalent of having a mediocre sandwich when you're starving.
People forget Braintree Payments from PayPal.
While the docs are confusing and the API info incomplete, once past that the experience has been good. Having a pre-written embeddable JS widget that takes care of adding support for credit cards/PayPal/Apple Pay/Google Pay was a real time saver over Stripe.
The kicker is the default fees are higher than Stripe, but Braintree will negotiate.
While the docs are confusing and the API info incomplete, once past that the experience has been good. Having a pre-written embeddable JS widget that takes care of adding support for credit cards/PayPal/Apple Pay/Google Pay was a real time saver over Stripe.
The kicker is the default fees are higher than Stripe, but Braintree will negotiate.
I've been happy with strip. The only other payment processor I've used is PayPal, which is a nightmare.
What do you mean by "there's no support for transactions"?
What do you mean by "there's no support for transactions"?
I haven't really worked with PayPal, so I can't really compare. I did some payments years ago with ... I forgot, so I can't really compare it to other competitors.
With transactions I mean that if I send two or more API requests to complete a single action (e.g. "create customer and subscribe to plan", but there are many more advanced workflows like accepting multiple currencies etc.) then I'd like to have all of them succeed, or none of them succeed, similar to "BEGIN [..] COMMIT" in SQL.
Right now, a network error, programming error, wrong data, or whatnot on the second request means I'll be left with a "dangling" customer. As far as I know, there isn't any good way to solve this other than either deleting the customer on errors or changing the first request to a "create if not exists"-type request. It works, but it's a lot less smooth than it could be.
There are also some other concern with this; what if I send the same series of requests at the same time? The first might create object A, the second "create or get" might get the object created in the first series, and it all becomes messy and complicated.
The only things Stripe offers now is "Idempotency-Key", which is not even a "poor man's transactions".
With transactions I mean that if I send two or more API requests to complete a single action (e.g. "create customer and subscribe to plan", but there are many more advanced workflows like accepting multiple currencies etc.) then I'd like to have all of them succeed, or none of them succeed, similar to "BEGIN [..] COMMIT" in SQL.
Right now, a network error, programming error, wrong data, or whatnot on the second request means I'll be left with a "dangling" customer. As far as I know, there isn't any good way to solve this other than either deleting the customer on errors or changing the first request to a "create if not exists"-type request. It works, but it's a lot less smooth than it could be.
There are also some other concern with this; what if I send the same series of requests at the same time? The first might create object A, the second "create or get" might get the object created in the first series, and it all becomes messy and complicated.
The only things Stripe offers now is "Idempotency-Key", which is not even a "poor man's transactions".
I see what you mean, but I've never used an API where you could wrap arbitrary sets of API calls in a transaction on the remote side. In general once you are in the distributed systems world there are no transactions.
I think that would make for a very hard to use API. You would need to send all the API calls at once without receiving responses for the individual calls. So if you were doing something that requires 4 api calls you would need to send all 4, even if the first one is going to fail anyway.
So you wouldn't be able to get/create a customer ID and use it in the next API call to create a subscription. You would need to generate all the IDs locally first.
Even after all that, the transaction could commit on the stripe side, and you still might not get a response back that it worked. So how would you ask stripe "did this collection of API calls work?"
With their API you either get a customer id back, or you get an error, or you get nothing back. Then you either get a subscription id back, or you get an error, or you get nothing back.
* If you get a customer id back you go on to create the subscription. * If you get an error or nothing back you keep retrying until you get a customer id back. Then you go on to create the subscription following the same retry logic.
The impotency key ensures when you get the subscription id back you have created the customer exactly once, and the subscription exactly once.
Having a "dangling customer" is not a problem - when you fix whatever is wrong with your "create subscription" call you don't create a new customer - you just link that existing customer to the subscription. You'll have the customer ID at that point.
I think that would make for a very hard to use API. You would need to send all the API calls at once without receiving responses for the individual calls. So if you were doing something that requires 4 api calls you would need to send all 4, even if the first one is going to fail anyway.
So you wouldn't be able to get/create a customer ID and use it in the next API call to create a subscription. You would need to generate all the IDs locally first.
Even after all that, the transaction could commit on the stripe side, and you still might not get a response back that it worked. So how would you ask stripe "did this collection of API calls work?"
With their API you either get a customer id back, or you get an error, or you get nothing back. Then you either get a subscription id back, or you get an error, or you get nothing back.
* If you get a customer id back you go on to create the subscription. * If you get an error or nothing back you keep retrying until you get a customer id back. Then you go on to create the subscription following the same retry logic.
The impotency key ensures when you get the subscription id back you have created the customer exactly once, and the subscription exactly once.
Having a "dangling customer" is not a problem - when you fix whatever is wrong with your "create subscription" call you don't create a new customer - you just link that existing customer to the subscription. You'll have the customer ID at that point.
He means database transactions. I.e. the ability to do a series of operations atomically.
A "cult" is an entity with blind followers who would go over the edge like lemmings.
Stripe is not that. They just built a good API, have made it more functional and easier to use over time, and have great developer support (go on IRC any time to chat with them). They accept criticism and fix problems. Cults don't do that.
Stripe is not that. They just built a good API, have made it more functional and easier to use over time, and have great developer support (go on IRC any time to chat with them). They accept criticism and fix problems. Cults don't do that.
> Anyone, anywhere can rebel against the system with Stripe.
If you consider working with a system that the government has perfect transparency into and that is deeply integrated into every major financial institution in the world rebellious, I just don't even know what to say.
If you consider working with a system that the government has perfect transparency into and that is deeply integrated into every major financial institution in the world rebellious, I just don't even know what to say.
I liked this article. Is a prime example of how a shameless asskissing article should look like, this should be on top of every campaign manager as a must read for upcoming election battle.
If we are taking about Stripe, we should mention the silent competitor barely anyone talks or knows about outside the payments industry: Adyen.
Stripe’s current, (private) valuation is $36B. Developers love them. Adyen’s current, public valuation is $43B (they IPO’d amongst little press coverage). Most developers don’t know about them.
So what is the difference? Market strategy. Adyen only goes after large businesses and has something many others, including Stripe cannot compete with efficiently: (far) lower pricing, higher market coverage.
The developer experience for Adyen is decent - no complaints, perhaps a bit less “magical”. They will definitely have a fraction of the customers, but those customers are huge. They get and seek little to no publicity compared to Stripe, yet have built a similarly sized business from the Amsterdam, the Netherlands, which is remarkable.
It’s a completely different market strategy, and company strategy. Read the Adyen values to see how different the two companies are[1] - Adyen putting “merchants” first, with a mention of support, while Stripe prioritizing developers and small businesses. And company culture could not be more different either - saying this as someone who knows both Adyen and Stripe employees. Both are companies to admire, and show that there is no “one” good way to build immense value.
It will be fascinating to see what happens as these two companies expand to compete with each other (meaning Adyen starting to go after small businesses, and Stripe after the largest merchants, with a differentiated pricing model).
[1] https://www.adyen.com/about
Stripe’s current, (private) valuation is $36B. Developers love them. Adyen’s current, public valuation is $43B (they IPO’d amongst little press coverage). Most developers don’t know about them.
So what is the difference? Market strategy. Adyen only goes after large businesses and has something many others, including Stripe cannot compete with efficiently: (far) lower pricing, higher market coverage.
The developer experience for Adyen is decent - no complaints, perhaps a bit less “magical”. They will definitely have a fraction of the customers, but those customers are huge. They get and seek little to no publicity compared to Stripe, yet have built a similarly sized business from the Amsterdam, the Netherlands, which is remarkable.
It’s a completely different market strategy, and company strategy. Read the Adyen values to see how different the two companies are[1] - Adyen putting “merchants” first, with a mention of support, while Stripe prioritizing developers and small businesses. And company culture could not be more different either - saying this as someone who knows both Adyen and Stripe employees. Both are companies to admire, and show that there is no “one” good way to build immense value.
It will be fascinating to see what happens as these two companies expand to compete with each other (meaning Adyen starting to go after small businesses, and Stripe after the largest merchants, with a differentiated pricing model).
[1] https://www.adyen.com/about
> Adyen only goes after large businesses and has something many others, including Stripe cannot compete with efficiently: (far) lower pricing, higher market coverage.
The reason is: larger businesses will require more payment options than Stripe offers.
India? Adyen got you covered: [1] Philippines? Yup, everything [2], including offline payments in stores [3]. Mobile payments in Africa? No worries [4] And so on and so forth. On their payment site they don't even list all payment methods, there are so many. You search for a country or a payment method, and they show what's available.
Stripe has a very long way to go to realistically compete with Adyen.
[1] https://www.adyen.com/payment-methods#pmx=india
[2] https://www.adyen.com/payment-methods#pmx=the-philippines
[3] https://www.adyen.com/payment-methods#pmx=convenience-stores...
[4] https://www.adyen.com/payment-methods#pmx=mobile-network-ope...
The reason is: larger businesses will require more payment options than Stripe offers.
India? Adyen got you covered: [1] Philippines? Yup, everything [2], including offline payments in stores [3]. Mobile payments in Africa? No worries [4] And so on and so forth. On their payment site they don't even list all payment methods, there are so many. You search for a country or a payment method, and they show what's available.
Stripe has a very long way to go to realistically compete with Adyen.
[1] https://www.adyen.com/payment-methods#pmx=india
[2] https://www.adyen.com/payment-methods#pmx=the-philippines
[3] https://www.adyen.com/payment-methods#pmx=convenience-stores...
[4] https://www.adyen.com/payment-methods#pmx=mobile-network-ope...
Many many countries have payment methods that only exist in that country, but make up a large percentage of online payments within that country. I’ve personally seen Adyen chosen over Stripe at a few companies that were aggressively expanding internationally for exactly that reason.
Adyen seems to implement every payment method you can think of. And if you don’t want to implement them, their white label payment page is able to dynamically show payment methods based on user location and merchant preferences.
Adyen seems to implement every payment method you can think of. And if you don’t want to implement them, their white label payment page is able to dynamically show payment methods based on user location and merchant preferences.
This is seriously lacking in terms of what's available on the market in Japan now.
No support for point payments (like RakutenEdy payment), neither Linepay, Rakupay, Merpay, Paypay and other QR payment providers, nor Suica or Pasmo pay, and this is still just the tip of the iceberg what's available in Japan and missing in Adyen (Nanaco, Waon, dPay, auPay, etc). Just saying, before you drink too much of that kool-aid.
I would assume it's lacking similarly in other markets too.
No support for point payments (like RakutenEdy payment), neither Linepay, Rakupay, Merpay, Paypay and other QR payment providers, nor Suica or Pasmo pay, and this is still just the tip of the iceberg what's available in Japan and missing in Adyen (Nanaco, Waon, dPay, auPay, etc). Just saying, before you drink too much of that kool-aid.
I would assume it's lacking similarly in other markets too.
Yeah, and how many payment providers provide all that and all the rest that Adyen provides?
I'm drinking Adyen kool-aid because I worked for a company that needed payment methods in Japan, and in India, and in Korea, and in Latin America, and in Europe.
Adyen provides all that. Yes, they will not have 100% of local providers, but it's still 100% better than any competition.
I'm drinking Adyen kool-aid because I worked for a company that needed payment methods in Japan, and in India, and in Korea, and in Latin America, and in Europe.
Adyen provides all that. Yes, they will not have 100% of local providers, but it's still 100% better than any competition.
GMO PG is famous option for EC but more enterprisey.
https://www.gmo-pg.com/en/service/mulpay/
International is actually really important. It's not just that you are currently international, it's do you have any plans to go international ever? Because if so, you might have to rewrite your entire payment stack at that point.
I can't say much but I'll say that Adyen is light years ahead of their competition much more than they let on.
Source: Worked in software for payments processing a couple billions a year.
Source: Worked in software for payments processing a couple billions a year.
Can you say a little bit more? I'm intrigued!
Example would be intelligent acquirer routing based off historical information and that individual transaction. Most of what is done in the industry usually refers to this as bin routing.
This is much more known now but not as known 6-10 years ago and guess who was very aggressive at maximizing this before I saw Stripe make a solid effort at this...
They've also got some of the highest quality transaction volume, who is doing a chargeback on Netflix? Nobody. Lot of possibilities down the road when you have access to this kind of volume.
This is much more known now but not as known 6-10 years ago and guess who was very aggressive at maximizing this before I saw Stripe make a solid effort at this...
They've also got some of the highest quality transaction volume, who is doing a chargeback on Netflix? Nobody. Lot of possibilities down the road when you have access to this kind of volume.
Some realities manifest at different scales. Once you're in the largest tier, the "where is the money" reality affects things.
Large corporations are the larger, wealthier segment.
A big chunk of "startup business strategies" ignore this market. This makes a lot of sense for a startup. You don't really care what the bigger market is as a startup, you care what market is easier to access. Assuming the market is big (eg online payments), the size of the market isn't a limiting factor.
That works in-context. I'f you're trying to build a startup, landing a multi-year contract with a big company is a bad angle for multiple reasons. Not always, but mostly in the generic case. Long sales cycles. Checklist feature demands. Custom features. Besides being hard for most founders, it pushes in the wrong directions. Meanwhile, who cares if you're addressing a $3bn market or a $800bn market. Both of those are big enough for a startup aiming for $8m in revenue. Your problem is sucking and failure, not pyrrhic victories.
Also, if you are successful enough, small markets become big markets. When Google IPO-ed, they competed with yellow pages for mom-n-pop business & such.
OTOH, most of the market is large companies, governments, etc. That's reality, and it means something. Now that VCs fund startups so generously, a common pattern is bootstrapping in a shallow pond... then jumping into the main pond once you have momentum.
EG, Having a "developer cult" mentality, like stripe, at your base will serve you in the long term. Enterprise developers do have influence. It's never what makes a decision, but it can be a favourable wind.
Large corporations are the larger, wealthier segment.
A big chunk of "startup business strategies" ignore this market. This makes a lot of sense for a startup. You don't really care what the bigger market is as a startup, you care what market is easier to access. Assuming the market is big (eg online payments), the size of the market isn't a limiting factor.
That works in-context. I'f you're trying to build a startup, landing a multi-year contract with a big company is a bad angle for multiple reasons. Not always, but mostly in the generic case. Long sales cycles. Checklist feature demands. Custom features. Besides being hard for most founders, it pushes in the wrong directions. Meanwhile, who cares if you're addressing a $3bn market or a $800bn market. Both of those are big enough for a startup aiming for $8m in revenue. Your problem is sucking and failure, not pyrrhic victories.
Also, if you are successful enough, small markets become big markets. When Google IPO-ed, they competed with yellow pages for mom-n-pop business & such.
OTOH, most of the market is large companies, governments, etc. That's reality, and it means something. Now that VCs fund startups so generously, a common pattern is bootstrapping in a shallow pond... then jumping into the main pond once you have momentum.
EG, Having a "developer cult" mentality, like stripe, at your base will serve you in the long term. Enterprise developers do have influence. It's never what makes a decision, but it can be a favourable wind.
If you are a startup, courting a large customer can compromise the integrity of your project. You have no leverage at all, which means the product will start to look like what they want it to be.
And because you made a deal with them when you had no leverage, the terms will also be awful, and difficult to renegotiate. So you have to go try to increase margins off of smaller customers, all with a product that looks like what the person you aren't making money off of wanted it to look like.
Hypothetically speaking, of course. Because I definitely for sure did not work for a place who tried to go big too soon and ended up with a modest exit.
And because you made a deal with them when you had no leverage, the terms will also be awful, and difficult to renegotiate. So you have to go try to increase margins off of smaller customers, all with a product that looks like what the person you aren't making money off of wanted it to look like.
Hypothetically speaking, of course. Because I definitely for sure did not work for a place who tried to go big too soon and ended up with a modest exit.
It's reasonable to look at this from a short-term vs. long-term perspective as well.
Stripe dominates the hobby & startup segments with the hope that those companies will, someday, become very successful. Now, any company at a certain size will be able to switch between payment processors with little cost, but Stripe still has that initial relationship. They certainly have the opportunity to grow business with their current relationships over time, and in some ways more than Adyen can.
Additionally, Stripe will always work to get more payment methods & exist in more countries. It's always some work to do so, but number of payment methods isn't insurmountable, and it's only a matter of time before Stripe & Adyen are difficult to distinguish between their offerings.
Lastly, Stripe has a lot of breadth of products compared to Adyen. Stripe Sigma alone is a huge value add that a regular "insights platform" lacks. There's a lot here to unpack, for sure.
Stripe dominates the hobby & startup segments with the hope that those companies will, someday, become very successful. Now, any company at a certain size will be able to switch between payment processors with little cost, but Stripe still has that initial relationship. They certainly have the opportunity to grow business with their current relationships over time, and in some ways more than Adyen can.
Additionally, Stripe will always work to get more payment methods & exist in more countries. It's always some work to do so, but number of payment methods isn't insurmountable, and it's only a matter of time before Stripe & Adyen are difficult to distinguish between their offerings.
Lastly, Stripe has a lot of breadth of products compared to Adyen. Stripe Sigma alone is a huge value add that a regular "insights platform" lacks. There's a lot here to unpack, for sure.
When doing B2B with big corps developers opinion is not of such huge importance, they're not making any calls about closing the deal. Also integration will almost always be a part of the deal, so again devs care less, they'll have someone to come over and help set it up. It's in a big contrast with startups and small teams where it's usually up to devs to choose which payment processor will be used and how, and they'll be the ones expected to integrate it.
My experience is that developer opinions don't matter "today", but today's ICs move up the ladder and matter "tomorrow". Much as how consumer brands work so hard to capture teenagers, because brand loyalty acquired in that period can last for decades.
Developpers opinion doesn't matter much, but developpment cost and reliability does. If a project takes 6 months vs 3 weeks, it's a completely different game.
Even for big B2B corps, it's the difference between a project you can lead on your own and get credit for it, or something that will go upper in the chain because of all the approvals you need for it.
In a previous life, to get an Adyen contract and dev. environment and then the prod credentials, it took us something like 3 months, and we had a smaller PSP integrated for a different project in the meantime. That meant that for any project we didn't have as much volume, we'd go though faster PSPs instead of reusing the Adyen connection.
Even for big B2B corps, it's the difference between a project you can lead on your own and get credit for it, or something that will go upper in the chain because of all the approvals you need for it.
In a previous life, to get an Adyen contract and dev. environment and then the prod credentials, it took us something like 3 months, and we had a smaller PSP integrated for a different project in the meantime. That meant that for any project we didn't have as much volume, we'd go though faster PSPs instead of reusing the Adyen connection.
> Adyen’s current, public valuation is $43B (they IPO’d amongst little press coverage)
Actually looks like 43B EUR, so $50B.
Actually looks like 43B EUR, so $50B.
> So what is the difference? ... The developer experience for Adyen is decent.
That hasn't been our experience at all. In our case (a few years back, they might've improved in the meantime) Adyen experience was pretty lousy. Not especially bad, but average - considering many payment gateway APIs were as bad.
In contrast, Stripe was (at the same time, and continues to this day) miles ahead, a pure developer delight. Properly documented, with working API wrappers, working examples, correct API responses. It just worked as expected and was easy to understand.
Unfortunately I don't recall specifics with Adyen as it was a while back, but I know we were pretty unhappy with it. To this day I've never looked at it again, while I recommend Stripe to anyone in position to use it.
That hasn't been our experience at all. In our case (a few years back, they might've improved in the meantime) Adyen experience was pretty lousy. Not especially bad, but average - considering many payment gateway APIs were as bad.
In contrast, Stripe was (at the same time, and continues to this day) miles ahead, a pure developer delight. Properly documented, with working API wrappers, working examples, correct API responses. It just worked as expected and was easy to understand.
Unfortunately I don't recall specifics with Adyen as it was a while back, but I know we were pretty unhappy with it. To this day I've never looked at it again, while I recommend Stripe to anyone in position to use it.
> It will be fascinating to see what happens as these two companies expand to compete with each other
Very unlikely, as both markets (smb payments and enterprise payments) is unlimited, there is a few chance they will try to compete with each other. On the other hand almost no company is able to be a leader in both the smb and enterprise space, because as you mentioned it, the cultures need to be different, the customer support need to be different, the product need to be different,... More info here : https://blog.luap.info/why-most-saas-companies-cant-be-succe...
Very unlikely, as both markets (smb payments and enterprise payments) is unlimited, there is a few chance they will try to compete with each other. On the other hand almost no company is able to be a leader in both the smb and enterprise space, because as you mentioned it, the cultures need to be different, the customer support need to be different, the product need to be different,... More info here : https://blog.luap.info/why-most-saas-companies-cant-be-succe...
==On the other hand almost no company is able to be a leader in both the smb and enterprise space==
Concur, Microsoft Office, GSuite, Tableau, DocuSign, Salesforce, Adobe, Slack and Zoom to name a few.
Concur, Microsoft Office, GSuite, Tableau, DocuSign, Salesforce, Adobe, Slack and Zoom to name a few.
> both markets (smb payments and enterprise payments) is unlimited
What? There are only so many companies in need of (or open to changing) payment processing software at a given time. When it comes to larger firms, those numbers get smaller. That's the opposite of unlimited.
What? There are only so many companies in need of (or open to changing) payment processing software at a given time. When it comes to larger firms, those numbers get smaller. That's the opposite of unlimited.
Well, as a single illustrative data point, retail sales numbers were announced for Canada this morning. Coming out of the pandemic lock-down total sales up 18%, online up 100+% but still only accounts for 8% of total retail. That leaves a lot of greenfield market to go after without ever competing.
I wouldn't be surprised if "so many" turns to be > 1 000 000.
Adyen's pricing seems to be higher and way more confusing than Stripe's.[0][1]
AMEX and Discover's transaction costs are a percent higher on Adyen, and I can't actually tell what Mastercard or Visa will charge since it is obfuscated. The cherry on top is the FAQ at the bottom that describes what interchange++ is but doesn't actually tell you a range of fees that it can be. I guess it's cool to see in detail all the middle men taking a cut of my revenue, but I'm way more concerned about the actual amount that is being taken out ahead of time instead of it being a surprise for every transaction.
[0] https://www.adyen.com/pricing?navItem=northamerica [1] https://stripe.com/pricing
AMEX and Discover's transaction costs are a percent higher on Adyen, and I can't actually tell what Mastercard or Visa will charge since it is obfuscated. The cherry on top is the FAQ at the bottom that describes what interchange++ is but doesn't actually tell you a range of fees that it can be. I guess it's cool to see in detail all the middle men taking a cut of my revenue, but I'm way more concerned about the actual amount that is being taken out ahead of time instead of it being a surprise for every transaction.
[0] https://www.adyen.com/pricing?navItem=northamerica [1] https://stripe.com/pricing
It basically is always cheaper for almost everything than Stripe (except AMEX). Interchange++ is always less than Stripe's equivalent charge (2.9% or lower for European cards) and 12¢ is less than 30¢.
The page I agree is confusing.
The page I agree is confusing.
Bear in mind, at any meaningful volume, Stripe does IC++ too and it isn't expensive
edit: Looking at their (listed) acquiring and processing fees, Stripe appears to be cheaper
That said, I don't know how Adyen's support is, but sadly Stripe's is honestly absolutely crap. Every single support interaction I've had with them has been incredibly slow and incredibly painful.
edit: Looking at their (listed) acquiring and processing fees, Stripe appears to be cheaper
That said, I don't know how Adyen's support is, but sadly Stripe's is honestly absolutely crap. Every single support interaction I've had with them has been incredibly slow and incredibly painful.
I don't understand where Stripe is showing as being cheaper?
Adyen for example for Mastercard: €0,10 + Interchange++ (average total 0.90% - 1.10%)
Stripe advertised in Europe for Mastercard: €0,25 + 1.4% of transaction.
Adyen for example for Mastercard: €0,10 + Interchange++ (average total 0.90% - 1.10%)
Stripe advertised in Europe for Mastercard: €0,25 + 1.4% of transaction.
It's not publicly listed, but from experience, their IC++ costs are decent
I'd guess that with the bigger deals they are doing all these things are up for negotiation anyway so they might not need a slick landing page with a simple pricing that a developer can understand in a few minutes.
Why is it remarkable that the company is based in Amsterdam?
I live there. There's a decent but not great startup culture. The services infrastructure is fantastic and there are many massive multinationals based here.
I live there. There's a decent but not great startup culture. The services infrastructure is fantastic and there are many massive multinationals based here.
I read this sentence as saying "outside the valley" more than saying that Amsterdam is a particularly surprising place.
I believe that "remarkable" was referring to Adyen getting and seeking little to no publicity compared to Stripe, yet having a higher market valuation, rather than its location in the Netherlands.
Indeed. I think I never heard about Adyen before moving here to the Netherlands (September 2019) to work as a software engineer.
Not only I discovered my company uses it, but plenty of other business I interact on a daily basis (from the market to utility-ish services) do.
Not only I discovered my company uses it, but plenty of other business I interact on a daily basis (from the market to utility-ish services) do.
Curious, does Stripe have a "Get the kids to take up smoking strategy" or do startups drop Stripe generally once they reach a certain size?
You can make a very good business of consulting people off of Stripe. Developers do love it, and for good reason (as the article points out). But it is expensive. If you are running $1,000,000 in credit card transactions per year at $29 each you will pay almost $40,000 in fees. Get up to $10,000,000 in transactions and you are now at $400,000 (this is basic pricing without volume discount, but they are still more expensive than most other interchanges). Suddenly it makes sense to look at other credit card processing technologies. There are a lot of costs to processing credit cards. But, if you have a CFO at your startup, they'll definitely run the numbers.
I think "Get the kids to take up smoking strategy" is a fairly accurate description of their Atlas program https://stripe.com/atlas
And their slogan "Our mission is to increase the GDP of the internet" https://stripe.com/about also alludes to the strategy of helping actually create more online businesses, as opposed to just getting all online businesses to use Stripe.
And their slogan "Our mission is to increase the GDP of the internet" https://stripe.com/about also alludes to the strategy of helping actually create more online businesses, as opposed to just getting all online businesses to use Stripe.
I think a lot of the big valuation is based on hoping the former is true. Stripe has a few big customers, and some of them are companies like Instacart that are younger than Stripe and have been on the platform since the beginning
One of the startup I worked for in London was using Adyen. That is to say they are not limited to enterprise customers.
We were processing a few millions a year at that time, which is quite small by enterprise standards. No idea how much volume it was years before when the company started using Adyen, I imagine not a lot.
We were processing a few millions a year at that time, which is quite small by enterprise standards. No idea how much volume it was years before when the company started using Adyen, I imagine not a lot.
Could you elaborate on how company culture is different?
Seems like Discover and AE are more expensive than Stripe at least for North America:
https://www.adyen.com/pricing?navItem=northamerica
https://www.adyen.com/pricing?navItem=northamerica
Stripe is the most popular option out of not many options. So, when you ask a developer what's their favorite payments API, chances are they are going to say Stripe. Which isn't surprising at all.
It's just yet another post on how Stripe are customer centric.
It's just yet another post on how Stripe are customer centric.
[deleted]
This is a PR release from Stripe isn't it?
http://www.paulgraham.com/submarine.html
http://www.paulgraham.com/submarine.html
I believe, that there are plenty of areas where you could succeed by literally just building what is already here but making it actually good.
Less features but better quality including with UX.
Less features but better quality including with UX.
Ah, the new Stripe design.
https://dribbble.com/shots/13676278-Home covers it, and the comments on it are unanimously positive (and also shallow).
Yet I open https://stripe.com and observe a page mostly incapable of hitting 60fps in its animations, which doesn’t scroll smoothly because of this, and which is intensely CPU-demanding (it immediately makes my laptop’s fans spin up, and I imagine it’d be draining the battery far quicker than normal). And that’s what I end up focusing on, rather than any prettiness. I don’t like websites that make my browser slow and my computer noisy, and will tend to close them far more quickly—either immediately, or go in, get the information, get out, rather than perhaps lingering.
They’ve focused on subjective prettiness at substantial and unnecessary cost. They could have implemented something just as subjectively pretty that didn’t perform so terribly, but they didn’t. (Fortunately it’s only the front page that suffers in this way.)
And on Dribbble: this sort of response is pretty standard: when something popular and pretty comes up, people seldom make any critical comment on even glaring usability problems. When something is obviously a catastrophically bad idea, maybe one or two people pipe up as dissenters, but even then their feedback will be muted. And don’t get me started on how people present their web design screenshots, framing them on a background that is essential to making key aspects of the design work, but which will be necessarily absent in the actual deployment—this is rank dishonesty, in my opinion, but it’s also ubiquitous on the platform.
As with Stripe’s popularity, these Dribbble things are a deliberate culture thing (problem, I’d say): the Dribbble community is interested in prettiness and doesn’t want to hear about impracticality or any form of negative feedback. This has probably helped with the platform’s popularity—it lets you feel good, everyone likes what you’ve made. Being largely invitation-only has also helped them create and sustain this echo chamber. (“Echo chamber” is a term too freely used, but it’s quite apt on Dribbble.) Otherwise I might create an account named “Honest Critic” and make a habit of pointing out problems in shots—not to be a downer or to condemn their work, but to help them improve it, and hopefully realise that they should care about these things.
https://dribbble.com/shots/13676278-Home covers it, and the comments on it are unanimously positive (and also shallow).
Yet I open https://stripe.com and observe a page mostly incapable of hitting 60fps in its animations, which doesn’t scroll smoothly because of this, and which is intensely CPU-demanding (it immediately makes my laptop’s fans spin up, and I imagine it’d be draining the battery far quicker than normal). And that’s what I end up focusing on, rather than any prettiness. I don’t like websites that make my browser slow and my computer noisy, and will tend to close them far more quickly—either immediately, or go in, get the information, get out, rather than perhaps lingering.
They’ve focused on subjective prettiness at substantial and unnecessary cost. They could have implemented something just as subjectively pretty that didn’t perform so terribly, but they didn’t. (Fortunately it’s only the front page that suffers in this way.)
And on Dribbble: this sort of response is pretty standard: when something popular and pretty comes up, people seldom make any critical comment on even glaring usability problems. When something is obviously a catastrophically bad idea, maybe one or two people pipe up as dissenters, but even then their feedback will be muted. And don’t get me started on how people present their web design screenshots, framing them on a background that is essential to making key aspects of the design work, but which will be necessarily absent in the actual deployment—this is rank dishonesty, in my opinion, but it’s also ubiquitous on the platform.
As with Stripe’s popularity, these Dribbble things are a deliberate culture thing (problem, I’d say): the Dribbble community is interested in prettiness and doesn’t want to hear about impracticality or any form of negative feedback. This has probably helped with the platform’s popularity—it lets you feel good, everyone likes what you’ve made. Being largely invitation-only has also helped them create and sustain this echo chamber. (“Echo chamber” is a term too freely used, but it’s quite apt on Dribbble.) Otherwise I might create an account named “Honest Critic” and make a habit of pointing out problems in shots—not to be a downer or to condemn their work, but to help them improve it, and hopefully realise that they should care about these things.
You really think anyone looking for a payment processing for their business cares about CPU and frames per second on a marketing website?
As far as they care about anything on the website. Do they care about it looking pretty?
If the CPU load is high enough to impact scrolling, it will hinder people trying to get information from that page.
If the CPU load is high enough to impact scrolling, it will hinder people trying to get information from that page.
It's been some time I've worked with web payments (back in 2003 or so when 3DSecure/UCAF was new which would bring up your card issuer's site in an iframe within your shop site, which still looked fishy), but I've always thought a payment infrastructure/comprehensive standard should be mandated by government, on similar legal grounds that a currency is issued in the first place, and for protecting access to the market (the EU already puts strong and maybe disproportionate reporting duties due to MiFid/MiFid2 for deposits, with unclear benefits). Though I'm not very sure, as a payment provider has to do costly things for fraud/money laundering/deposit protection.
This actually reads more like a content marketing PR piece for Stripe than a summary of useful and actionable information for a startup.
In my previous job, I implemented the backend integration with Stripe and also the frontend for iOS (Native Swift App). It was a piece of cake to get the whole implementation done across the stack.
Six months later, our company decided to switch to Adyen so we could target more local payment methods in different countries. Back then, Stripe wasn't so flexible on that. With Adyen, we could for example offer "carte bancaire" in France and "iDEAL" in the Netherlands with zero changes on our accounting and backend infrastructure.
I have to be honest, from the developer perspective, Stripe is light years ahead of Adyen regarding docs and simple to integrate (simple != easy).
But once we deployed Adyen, our sales skyrocketed after we enabled local payment methods for specific countries across Europe.
If you are outside of the US, you should really consider Adyen instead of Stripe from the business standpoint. I am still a super fan of Stripe btw.
If you are outside of the US, you should really consider Adyen instead of Stripe from the business standpoint. I am still a super fan of Stripe btw.
I work for Adyen in our developer experience team. It might have been some time since you integrated but we would love to hear about your experience integrating to Adyen and how we can make it more simple. (You can reach me at directly at [email protected] or reach out to our team at [email protected])
Hey Lucas, thanks for the kind response!
It has been around 2 years since I implemented and honestly it wasn't that Adyen was bad or anything, but the mental model was different from Stripe. Back then, Adyen was already fully async but Stripe wasn't so it required some learnings.
And once it was implemented, I was actually blown away with the flexibility.
In my current company, I am actually advocating for Adyen and we had a few calls with the sales team already, so it will most probably happen for us next year.
Wow honestly haven't heard of Adyen until reading several of the comments in this post.
Thanks for sharing your experience and for the tip!
I stopped reading when the author described a feedback button as the epitome of customer obsession. Is that really the bar?
dang - can you change the title on this? It's less about "building a developer cult" and more about "How Stripe builds for Developers".