CEOInterviews.AILost Early Patrick Collison Stripe (2012) Interview

N

Narrator0:18

Three messages before we get started. First, do you need a single phone number that comes with multiple extensions so anyone who works at your company can be reached no matter where they are? Go to grasshopper.com. It's the virtual phone system that entrepreneurs love. Next, does anyone you know need a beautiful online store that actually increases sales but is easy to set up and manage? Send them to shopify.com, the platform that top online stores are running on right now. Finally, do you need a lawyer who actually understands the startup world that you and I live in? Go to walkerclaw.com. I've known Scott Edward Walker for years, so tell him you're a friend of mine and he'll take good care of you. Here's a program.

A

Andrew Warner1:08

Hey there, freedom fighters. My name is Andrew Warner, founder of mixergy.com, home of the ambitious upstart. Over 700 interviews with proven entrepreneurs who've come here to tell you how they built their businesses so you can go out there, build your own company, and hopefully come back here once you do and do what today's guest is doing, which is tell your story and teach others. So, what I want to find out in this interview is how discovering a pain that most people, even most business people, don't notice that they have, how can doing that lead to building a successful new business? Patrick Collison is the co-founder of Stripe, which makes it easy to accept payments on the web. Stripe is used by thousands of online companies including Shopify, Foursquare, New York MoMA, and Tarn Snap. Patrick, welcome to Mixergy.

P

Patrick Collison2:04

Thank you. It's great to be here.

A

Andrew Warner2:05

So Paul Graham, guy who backed your company twice now actually, right?

P

Patrick Collison2:11

Yeah, he was also an investor in our previous company.

A

Andrew Warner2:15

So he said that one of the things that he admired about your business is that you noticed a problem that most people didn't even realize they had. How did you do it? How did you identify this big problem that the rest of us didn't notice at all?

P

Patrick Collison2:27

So it's interesting. I guess most people never run into the problem of having to accept payments online and most people don't actually, or most internet users don't build a product or service that they need to charge for. As that happens, we were web developers. We built a lot of software. This is something that we'd encountered a couple of times. I just built little side projects or something and I thought it'd be kind of cool to charge for it just to see, maybe there's some unexpectedly rich seam or something where it doesn't necessarily seem all that lucrative, there might actually be something there. And we'd actually experienced this.

A

Andrew Warner3:06

Can you give me an example?

P

Patrick Collison3:08

Yeah. So with the app store, we had run into this. A couple of years ago, I built an application for the iPhone that stored a copy of Wikipedia on the iPhone so you could read it without needing internet access. We launched in the app store and we charged for it because you had to download a two gigabyte dump from our servers which cost us a fair bit of bandwidth. As a result, we decided to charge a couple dollars for the app, expecting it to maybe become a couple of people would like it, but it was more just a fun side project. And then it ended up becoming really popular and got tons of downloads and actually was a major income stream for a while. But there's just no way that I would have expected or predicted that. And if it hadn't been so easy to integrate payments into the app or to have charged for it, there's just no way I'd ever discovered that.

A

Andrew Warner4:04

But you were able to integrate payments into the app through Apple's system, right?

P

Patrick Collison4:08

Through Apple's infrastructure, they had made it incredibly easy to charge for the software you built.

A

Andrew Warner4:13

Okay. But every time that I'd built a little tool or project or something like that, I'd either most of the time I actually hadn't integrated payments just because it seemed like so much work.

Can you give me a specific example? Tell me the story of a time when you were building a business and you were adding payments and you said this is infuriating, there's got to be a better way.

P

Patrick Collison4:33

Give you three examples. One is Automatic. This was our last company which was also funded by Y Combinator. It made it really easy for people to sell things on eBay. And there we never integrated payments.

A

Andrew Warner4:49

You never integrated any payments into it?

P

Patrick Collison4:51

Simply because it was just too much hassle.

A

Andrew Warner4:54

Do you remember when you tried integrating and what you experienced when you tried to add it on?

P

Patrick Collison4:58

I don't believe that we ever even went very far down the road in payments just because we knew it would be so much hassle. It was always kind of on the road map for the future at some point. We never actually went and had the conversations. The next project was a thing called Change Feed. This was just a tiny little tool that I wanted for myself. It was a thing where you give it the URL and it monitors the URL for changes and then gives you an RSS feed with a diff every time the link changes. It's cool for something like terms of service and things like that. It's a quick way to get an alert when a page online changes.

A

Andrew Warner5:39

Yes, I see.

P

Patrick Collison5:40

And that is literally just something I wanted for myself, but it was as easy to make it available for others as it was just myself. And there I went about setting up payments for it and discovered that it was just a huge amount of hassle.

A

Andrew Warner5:55

What kind of things? Because here's the thing that I know about you. Paul Graham thinks apparently you're so brilliant that he brought you to the Octomatic team, right? He said, "This guy Patrick is brilliant. You guys should meet him and work with him." Everywhere I look, when I look you up, I kept seeing people compliment how bright you were, how great a developer you were, how impressive the projects you worked on were, including Encyclopedia, which is what you talked about a moment ago. So, you're a guy who could do anything, you could even create a mobile payment system. Why was payment so tough for you? What were you seeing?

P

Patrick Collison6:30

It was two things I think. One is that ultimately people can in fact accept payments online, this is a solvable problem and people do it, but it's so much hassle that it just ends up getting pushed back. There's always so many things competing for your attention, it's prioritization. With Change Feed, it wasn't like I'm not able to integrate payments, therefore I'm stuck. It was more like, well, I could integrate payments, but it looks like that would probably take me a day, so I don't know, maybe I'll just build a new feature, not bother charging because chances are I won't make much money anyways. Just like, who cares? But also it's that it's so complicated. There are merchant accounts and gateways and processors and ISOs and recurring billing providers and PCI and vaults and interchange and qualified and non-qualified and all these terms and PDFs and tutorials that teach you about all this stuff. From my standpoint, before I knew anything about this industry, for all I knew what you actually needed to do was pretty simple, but there was so much stuff there that I didn't even know if it was simple or not. It just ended up getting deferred. It was never the most pressing thing and I never ran that experiment of just charging a couple of dollars. For all I know, maybe Change Feed would have become really popular, or maybe my mom would have paid for it and nobody else ever, and I just don't know. I never got to find out.

A

Andrew Warner8:14

I see. You know what, you're right. You reminded me of all the steps that went into even us charging here at Mixergy. We had to get Authorize.net, which is a gateway. We had to get PowerPay.

P

Patrick Collison8:25

Yep.

A

Andrew Warner8:26

We had to do something with American Express and Discover to separately sign up for those. And then we had to set up a shopping cart.

P

Patrick Collison8:35

Yep.

A

Andrew Warner8:36

And by the way, I didn't know until months later that we had Authorize.net and PowerPay. I didn't even know about PowerPay even though I must have signed something to get it, until I had an issue with someone who months later wanted a refund and I needed to figure out how to do it and then they told me about PowerPay. I said, "What?" It's all these steps. So you're right, it's not just the development part, you could probably knock that out fairly quickly. You're saying it's all the different agreements you need and all the people you need to interact with.

P

Patrick Collison9:01

Right, and even just figuring out which company I should be talking to. What even do I need? Is a merchant account enough? What's a gateway? Why aren't they the same thing? Why are these different roles? It's like you need to go and assemble a server from scratch yourself, but you don't know what any of the components actually are. You don't even know what you need. And then coupled with that, especially for folks like us, for developers, people who just kind of make things, if someone tasked you and said you must get payments implemented this week and you have a week to do it, yeah, sure, you'd figure it out. But if it's just a speculative thing or experimental, it's often something you can defer and maybe you never get to it.

A

Andrew Warner9:43

So when you're deferring it, how do you get to a place where you start to notice that this is something that you're deferring and that you're deferring it not because you're afraid of charging, which some people are, not because you just want to keep the product pure, but because there's a hassle here that my mind just doesn't want to tackle and I wasn't aware of it. How do you become aware of it?

P

Patrick Collison10:05

For us it was this happening repeatedly. There was another one. I built an app store analytics product again just for my own use to track sales of this encyclopedia app. I actually wrote the app before the app store existed, and then released it pretty early in the history of the app store. There weren't really many analytics tools out there. Even the most basic questions like how much money did I make yesterday, Apple's tools didn't even tell you that. So I built this really simple web-based tool. Again, I went to payments for it. And I actually remember the day where I was chatting with John about it and just so frustrated with it. Having the experience of seeing how transformative it can be to discover that some things you build can actually become an income stream, and then having the experience of repeatedly sharpening this in other areas, the penny sort of started to drop and I started to realize that there's actually something broken here. In parallel with that, there was something really interesting happening in the hosting industry. 15 years ago, hosting meant calling a sales rep at some hosting company and then getting a physical server set up with a contract. Now there were things like your name tagged with your account, you need to understand the details of the specs, maybe they upgrade the server. And then EC2, Linode, Slicehost, and all these new companies came along where they give you all the advantages of shared hosting infrastructure where you can set it up instantaneously and you don't have to worry about the physical computation details, there are no contracts, things are pretty standardized, but they also gave you the complete control of traditionally renting your own box. I was really struck by, hey, why doesn't that exist in payments? Why can't I have all the benefits of a merchant account and the ability to define my own user experience and just have credit card payments really well implemented and integrated on my site, but as easy to set up as a server on Slicehost or EC2? That shift in the industry where hosting now looks completely different, for the vast majority of people you should just spin up a VPS on one of these services, and it seemed really clear that something like this should exist for all the major pieces of infrastructure that go into building a business on the internet. That repeated personal experience and that shift in the hosting industry made us start to realize.

A

Andrew Warner12:45

One thing I've noticed on a personal level is that when people scratch their own itch as you have, they solve a problem that they have for themselves. Often they end up creating a solution that they're the only ones who understand because they didn't talk to anyone else. They didn't try to address anyone else's needs. They thought everyone else was exactly like them and could understand their solution exactly the way they did. How did you avoid that problem?

P

Patrick Collison13:09

Good question. That's a mistake that I made before.

A

Andrew Warner13:16

When did you make a mistake of solving your own problem and having it be a solution that works so well just for you and not for anyone else?

P

Patrick Collison13:24

I worked when I was pretty young on new programming languages. In particular, I worked on a language called Chroma, which was a new Lisp variant. I realized that was very much tailored to the things I cared about and my own needs, and not necessarily to those that everybody else cared about. Building a programming language is actually an exercise in product design, and that never got much traction.

A

Andrew Warner13:53

It didn't get much traction because you were building it just for your need.

P

Patrick Collison13:57

Well, I thought I was building it for anybody's needs, but in reality I was entirely building it for my own needs.

A

Andrew Warner14:02

What's one thing that you built that made sense for you, but if you took it out to the rest of the world, it just wouldn't make much sense to them?

P

Patrick Collison14:08

That's what I'm saying. Chroma did not make sense for...

A

Andrew Warner14:11

You're saying the whole thing didn't make sense.

P

Patrick Collison14:13

Yes.

A

Andrew Warner14:13

Why not?

P

Patrick Collison14:14

It just didn't solve problems that other people cared much about. I cared about the problems.

A

Andrew Warner14:20

Like what? What's a problem you cared about that the rest of us didn't care about?

P

Patrick Collison14:23

I wanted serializable delimited continuations in my programming language. And very few other people wanted this, it turns out.

A

Andrew Warner14:33

You know what? Before you even answer the next question, the previous question, which is how you made sure that Stripe didn't suffer the same fate, I got to take a pause here and do something that I maybe should have done before, but I kind of assume everyone in my audience knows Stripe. In fact, they're the ones who are emailing me and telling me to have you on because they integrate Stripe into their businesses. But maybe we should just take a moment and tell people what exactly is Stripe for someone who doesn't know it.

P

Patrick Collison14:58

Sure. Stripe is the easiest way to start accepting payments on the internet.

A

Andrew Warner15:04

How quickly can I accept payments?

P

Patrick Collison15:05

You can start accepting payments instantaneously. Or you can accept payments as quickly as you can integrate Stripe. There's no synchronous blockers on our end. Go to Stripe, create an account, fill out basic details like your name and your bank account number and stuff like that. Integrate Stripe.js onto your web page or integrate into your mobile app or whatever, and you can just start charging credit cards. There is no phoning us up or submitting fax paperwork or any of that. It's instant setup.

A

Andrew Warner15:40

Conceivably, someone who's listening to us right now and is looking for something to do, maybe fidgeting at their keyboard, they could go to Stripe, sign up, get an account, and while they're listening to this interview, they can be live and have things running on their website accepting payments.

P

Patrick Collison15:55

Yes. And crucially, there have been things before like Google Checkout and PayPal and Amazon Payments and all this stuff. Some of those were kind of easy to set up on some level, but they really compromised the user experience in that your users were sort of whirled away into this offsite vortex or something, and they twist around in that for a while and they get jumped out back onto your site at some point kind of dazed and confused.

A

Andrew Warner16:21

You know what? That's exactly what I did when I first started. I'm sorry to interrupt, but you're absolutely right. And I've got to jump in here because when I needed to quickly accept payment, I went and I used PayPal. Quickly, you can set up and start collecting payments. But what I didn't notice was until I logged in using somebody else's account. They were basically upselling my customers on their products at PayPal and causing confusion that would basically lead someone to go buy a PayPal product and maybe never buy mine.

P

Patrick Collison16:47

Yes. The user experience of all these things really sucks. The thing we wanted to do with Stripe is provide a first class user experience, one that you completely define. You integrate the payment into your site whatever way makes sense for you, but provide the same kind of instant setup, super easy benefits that they had. Following off on that, the other problem with PayPal, Amazon Payments, Google Checkout, whatever, is the perceptions are kind of for smaller operations. By using Google Checkout on your site, that's a signal that you're not all that serious or big a business because you rarely see those on large or serious businesses. Also, they don't tend to scale very well. By scale very well, I mean they're really targeted at smaller users and just the really basic tangible stuff like how you export your data, how you search for a transaction, how you do reconciliation, how you match up transfers to your bank, all those things that you care about at any reasonable scale, they don't do very well. What we wanted to do is have Stripe work incredibly well at that initial moment where you want to integrate payments, but then on an ongoing basis, if your business takes off and you're doing 100K a year or maybe even a million a year, or in the wildly successful case, 100 million a year, we wanted Stripe to scale really well with each of those points. Just like AWS or something where EC2 will work really well if it's just you and your side project experiments, but it'll also work really well for Netflix. We wanted Stripe to span the gamut there. If you want to integrate payments, of any size, we want to make it incredibly easy to get started and then really effective on an ongoing basis.

A

Andrew Warner18:37

All right. So, going back to the question that I had earlier, you have this problem. You are unique. How do you make sure that you don't solve the problem for people who are uniquely like you, which is nobody. What did you do to make sure that it applied to other people?

P

Patrick Collison18:51

I don't know what, there's only one good answer that I know to that question, and that's get other people using it as quickly as you possibly can. John and I, my co-founder and also brother actually, we had this idea and then just after Christmas one year we had to go and take a month's holiday and we went to Bonaire. We just sort of started hacking on this. I think we got there on January 1st or 2nd, and we had our first live production user on Stripe on, I want to say January 11th, but I'm not completely sure about that date. Basically, 10 days after we started hacking, we had our first real user using Stripe.

A

Andrew Warner19:40

How'd you get the first user?

P

Patrick Collison19:41

He was a friend of ours. It was actually Ross Boucher from 280 North, the guys who built the Cappuccino web framework. So yeah, and then we had another user and then a couple more after that. Right from the start, we had real people using it. Paul Buchheit from Gmail tells this great story about how he prototyped Gmail where he built it on top of Google Groups because that was already kind of an email product. He just hooked the Google Groups UI up to his own email and then you could browse and search his email. Then you start giving access to it to other people and the other people are like, "This seems really great, but how about instead of showing me your email, you show me my email?" It was kind of like that with Stripe. When we first released it to Ross, it was an incredibly minimal product.

A

Andrew Warner20:35

Let's talk about what how long did it take before you got the first user again? What was the number of days?

P

Patrick Collison20:39

I don't remember the precise dates, but let's say it was like 10 days.

A

Andrew Warner20:42

Roughly 10 days. What did you build in those 10 days?

P

Patrick Collison20:44

What we built was an API that allowed you to charge credit cards and a really minimal web interface that allowed you to view those charges, but we may not even have had that actually. It may literally have just been an API where you can submit a credit card number, an amount, and we will charge it.

A

Andrew Warner21:08

So, I just send you a credit card number, an amount, name, etc., and you say charged.

P

Patrick Collison21:13

Yes, that's pretty much it. You definitely couldn't refund transactions. We had to build that as you needed it. The web interface for viewing transactions and searching and all that kind of stuff all came later. Even the infrastructure around transferring money to bank accounts came later. I'm pretty sure that wasn't there on day one.

A

Andrew Warner21:36

So basically day one the money was staying in your bank account.

P

Patrick Collison21:40

Yeah. Ross couldn't get the cash out for himself for a couple of days. But it was just what is the simplest possible thing that we could build that would enable Ross to start using this on a site. Of course, we were helped by the fact that he was a good friend, and this wouldn't have been acceptable to release this to a paying user.

A

Andrew Warner21:57

So Ross did this because he's a good friend.

P

Patrick Collison22:00

Yes.

A

Andrew Warner22:01

Why else would he do this? You have tons of great friends and tons of people who would die to help you out because they know you're going places. They want to be helpful early on. Why Ross specifically?

P

Patrick Collison22:13

It was a combination of things. We knew him. We knew that he needed to accept payments for this product they were building. We really respected his design sense and technical sense, and we thought the feedback he was likely to give us would be really good. I don't know how many of your viewers know of Cappuccino, the web framework, but Cappuccino is just unbelievable. People are now going to talk about this new breed of modern web frameworks built in JavaScript like CoffeeScript, Ember, Backbone, and all this stuff. Cappuccino, I think, is still the most advanced web framework, certainly client side web framework ever written, and was basically done by these three guys in a pretty short span of time. They're just incredible software engineers. We were building a product trying to fix a deficiency on the web on some level, and this was also their mindset: what are the primitives we should use to build great products on the web? That confluence of things where they needed this product, they were friends, and they had really good design sense, they made for a pretty good first user.

A

Andrew Warner23:24

Was he also looking at the world and saying, "Hey, I don't like whatever is out there and I don't want to spend time building it either"?

P

Patrick Collison23:31

Yes, very much so.

A

Andrew Warner23:32

So he shared the same pain that you had.

So, he's looking at, by the way, before I even ask you about his feedback, what about you? You don't feel awkward saying to this guy who you admire, whose feedback you want, "Hey, you know what? You're never going to get refunds in version one. You're not going to get all this other stuff."

P

Patrick Collison23:51

I mean, we were pretty upfront about that. But from this time, I think you can look at the other way, which is online payment sucks. There's all these dinosaurs that provide terrible service. We will build the product that you want and you can start using it right now, and as you give us feedback, we'll immediately go and build the stuff that you'd like to see. From the other person's perspective, that's actually a compelling proposition. If somebody else who I thought execution was good came to me and said they would solve an acute problem that I have, and as soon as I give them feedback they'll go and iterate on it, like basically my own sort of boutique consulting company.

A

Andrew Warner24:28

Exactly. They get a free consultant.

P

Patrick Collison24:30

Exactly. Yes. I think that would be awesome. I think there's few things more motivating for a user of a piece of software than to just see it improve really quickly in a direction you approve of, even though it's kind of not quite there yet.

A

Andrew Warner24:47

I know what you mean. That is inspiring.

What about before you launched? Did you talk to Paul Buchheit, the founder of Gmail? Did you talk to friends and say, "Hey, do you guys have this problem too? What are you doing?"

P

Patrick Collison25:01

Yes. We talked to Paul a bunch in the past. He's actually also an investor in our previous company. We talked to a lot of people just about this problem space generally and heard about what their pain points were and what they used and what they wished existed.

A

Andrew Warner25:21

What's one thing that you discovered in these conversations that you didn't know when you were just thinking about it on your own?

P

Patrick Collison25:29

In the beginning, we were much more focused on the ease of setup because that was the real issue that we kept hitting. But as we had more of these conversations, we realized that even for the people who got set up and were actually accepting payments, the experience still sucked for them. They got statements in the mail and they couldn't possibly figure out the most basic stuff. Most of the people we talked to didn't know how much they were paying. They were getting some amount of money into their bank account every month, it was roughly of the order of what they were charging, but were they paying 1%, 2%, 3%, 5%, 10%? They just didn't know. Often they'd tell us numbers, and then at some point later we could see their statements because we really wanted to analyze what they were being charged for and why and how, and we found that in most cases what they thought they were paying actually wasn't what they were paying. Intentional obfuscation. The ongoing, again really prosaic issues. There's one guy who now uses Stripe who is a pretty heavy user and previously used PayPal. His issues with PayPal were stuff like it's really hard to find a transaction and just refund it. A basic thing: I log into PayPal and I have to page through all these transactions and every page load is really slow. The whole process of refunding a transaction takes you like 10 minutes, whereas with Stripe, I just type in a type-ahead search bar, press enter, and then click refund. Just the really basic things all kind of suck. From all these conversations, we started to think much more about how we could make Stripe awesome for people who were already up and running and had real businesses, not just trying to figure out how we could turn all those people who had been put off by even the notion of processing payments into customers.

A

Andrew Warner27:26

So, from what I'm understanding, there wasn't a formal list of questions or a formal process of asking people, right?

P

Patrick Collison27:32

Yes, that's correct.

A

Andrew Warner27:34

What a lot of entrepreneurs who I interview, who talk to customers and figure out what to build based on those conversations, what they often warn me against is you don't want to ask a question with the expectation that people are going to come back to you with a specific kind of answer. You don't want to say, "Hey, I'm thinking of building this, is this the best?" and not give them room to say no, it's not. You want to... So how did you do it if you were just casual? How do you make sure that you weren't influencing the answers that they were giving you?

P

Patrick Collison28:03

That's a good question. I'm not sure that we did a fantastic job of not influencing their answers. We may actually have influenced them. I think that with Stripe, we were just kind of lucky. We just stumbled upon this geyser. There's this giant problem here: the payments infrastructure of the internet sucks. I don't think that we necessarily did an especially good job of being systematic about how to discover the optimal product. It was more just our instincts that this should be built for developers and makers and the end users, as opposed to the business people, and that it should be instant setup and treated as a technology problem, not a finance problem. I can't claim that we had a great, very disciplined process for really proving that was the case. It was more just our own suspicion. I guess I say that I think we were just lucky. But the one thing that I think was helpful was that we just had real production usage almost literally from day one.

A

Andrew Warner29:24

Real production usage. So, and by the way, this shows that even if you're not perfect, as long as you talk to customers, the influence that they have on your product is going to be positive. The way they open your eyes to issues that you didn't know because you didn't feel them because you weren't depending on those payments to come through PowerPay or whoever else.

P

Patrick Collison29:45

Right. Helpful. For sure. There's lots of schools of thought here. There's a classic Henry Ford quote about customers and you get a faster horse or whatever. Obviously, I guess a balance. But once you've decided where the future should be, we decided kind of the structure of the industry and just thinking rationally about how the internet should work, this kind of service should exist. I think once you kind of meet that need that customers might not necessarily tell you about, then for implementing that concept, you should talk to users as much as you possibly can. Similarly for Henry Ford, he might decide that the motor car is where it's going to be, but once he's decided that, it would probably be to his benefit to then go and talk to customers with the car constantly and figure out the issues and bugs and pain points. So I think it's probably some kind of balancing act. Once you have the lead and you've kind of popped that chasm in your mind, then talking as much as possible is almost only a good thing.

A

Andrew Warner30:58

All right. And so you showed it to a first customer within about 10 days. What did the first customer say? What was the feedback that you got?

P

Patrick Collison31:08

I have to dig up the emails and the IM transcripts.

A

Andrew Warner31:13

Does anything stand out?

P

Patrick Collison31:18

My recollection is that he was just very kind of satisfied. It's like, "Oh yes, this is how it should be. Great." On some level, Stripe is just kind of amazing, not so much because it's a wholly implausible technological leap. It's more like this is amazing relative to everything else. It's amazing that everything else was so bad and this finally exists. With a lot of users, including Ross, it was like, "Yes, good job. This is indeed what I've always wanted."

A

Andrew Warner32:02

So you're showing it to customers, not necessarily just the first one, but you're showing it to a handful of customers early on because you want their feedback and you want their influence on your product.

P

Patrick Collison32:12

Yes.

A

Andrew Warner32:12

So, let's step away then from the first customer and talk about those early experiences. What did showing your...

What did shipping the product to real people teach you that you wouldn't have known if you were just building it on your own with your brother?

P

Patrick Collison32:27

I guess you kind of talked about the ongoing account a little bit. There were a lot of use cases that we hadn't thought a lot about.

A

Andrew Warner32:46

Can you give me an example? What's one thing that hadn't occurred to you?

P

Patrick Collison32:51

For example, recurring billing. Obviously a ton of people do recurring billing. We're now on our third major version of our recurring billing infrastructure. We first talked to a bunch of people and figured out a set of abstractions we thought would cover most use cases pretty cleanly. We then realized we were actually missing a bunch. We ran another version and now we're on a third, and I think there's a good chance there will be a fourth. That can only really come from...

A

Andrew Warner33:23

But the whole idea of recurring billing wouldn't have occurred to you as being so important.

P

Patrick Collison33:30

Well, actually, in the beginning I'm pretty sure I thought we shouldn't even have recurring billing features, that it was pretty easy for developers to build themselves and they should just do that. Then enough people asked for it — probably half of our users — and we realized we should probably just build it ourselves. We've been moving up through the levels of abstraction. Our first recurring tool was just a clock, and you had to do most of the billing logic yourself. Whereas now in Stripe we have this first-class concept of plans, coupons, invoices, invoice items, and we've really brought together all the atoms that people typically want to build subscription infrastructure around. That was entirely driven by our users. The person who built that recurring billing infrastructure, before working with Stripe, she built a company that did subscription payments on top of Stripe. She was very well positioned to build that.

A

Andrew Warner34:36

So why couldn't people do recurring billing on their own? It seems to make sense that if you can program your side of the interaction as a merchant and send Stripe a credit card number and username for a customer, couldn't you just do that again a month later and then a month after that? What were you finding that made them say, "Hey, you guys should do this for us"?

P

Patrick Collison34:59

This is what we thought, right? Just charging amounts every month, how hard can it be? That's not the hard part. The hard part is actually getting up and running quickly, doing refunds, and finding customers in an easy way. Then you realize that maybe they don't want to charge every month. Maybe they want to charge every quarter, every year, or twice a month. And then do they want to charge after the service has been provided or before? What happens if a charge fails? You want to allow them to update their credit card and charge them for whatever payments are pending. Then maybe you charge them some amount every month but there are additional things they can buy — a $20 base plan and $5 or $10 of add-ons. Then maybe there's usage-based pricing, coupons for a 10% discount for the first year with a code from a podcast. It just keeps going. What happens when you have an add-on for only half the month and you want to charge a prorated amount? There's this fractal complexity. Yes, ostensibly sending an amount every month most developers can do, but once you dig into real-world scenarios, there's usually quite a bit of subtlety. It's sufficiently universal and common that we can do a pretty good job of it.

A

Andrew Warner36:40

I see. At that point, when it's that complex, it does become a whole job for them, a whole other business, and they don't want to be in that business. There are entire companies built around this, like Chargify and Recurly, that basically do subscription billing infrastructure.

P

Patrick Collison37:00

I see, because it is such a big pain that stood out like that.

A

Andrew Warner37:10

You're talking about...

P

Patrick Collison37:22

Yeah, I guess this might not be too surprising, but one thing we just didn't think much about initially that we discovered people really cared about was having visibility into the transfers coming into their bank account from Stripe. This is an interesting one because before Stripe you had merchant accounts, gateways, and all these other companies loosely integrated. You'd authorize with one company, and you get statements from American Express and bank transfers from the merchant account. The gateway doesn't know what's going on on the bank side, only the API side. All these separate silos. Stripe integrates everything, so it's easy for us to know what's going on on every side. That means we can do things that Authorize.net cannot, like tell you if you've got the money yet for a charge, when you'll get it, or what a transfer into your bank account was for. It turns out our users cared a lot about that. Accountants especially loved it. When companies become successful, they hire someone to do taxes, and that accountant goes through bank statements trying to reconcile things. With most systems, random amounts of money appear and they have to guess. With Stripe, it's really easy. We built this transfers display just because it seemed easy, and then accountants loved it. We ended up building infrastructure to export the data via an API so you could introspect it and see exactly which charges went into a particular transfer.

A

Andrew Warner39:44

And that goes into the bank statement.

P

Patrick Collison39:46

That's not on the bank statement. For a particular transaction, your bank statement can tell you exactly why that happened.

A

Andrew Warner39:54

I see, by going back to stripe.com. Yes. Because you're right. Otherwise, you look at your bank statement and see lots of little payments and then this big number you don't know what it is.

P

Patrick Collison40:08

And they have to go and figure out if they can go to the shopping cart for it. Pretty material, right? $457.13 just appeared in your bank account. In which year did those sales occur? Even those basic questions you cannot answer with most merchant gateway infrastructure.

A

Andrew Warner40:28

So, here's the thing. I started out this interview thinking, how does a guy who scratches his own itch figure out how to build a product that satisfies other people? Your itch stopped at needing a merchant account and not wanting to deal with the headaches. This wouldn't have been a problem you had yourself. So where did you even get the idea to create a page that accountants might get excited about?

P

Patrick Collison40:52

This is interesting. This is where the idea started to lead us. It's like discovering a geyser or an updraft — we're just pulled along by it. We had this initial idea that it should be way easier to start accepting payments online, and that infrastructure should look very different. As we started to dig into it, we uncovered all these other problems. Stripe itself underwent a big shift in our own heads. In the beginning, we thought of it as a side project, like building Slicehost for payments. This is for folks just like us. Then, maybe eight months later, over the subsequent summer, we realized this is actually an enormous problem on the internet. It's not that we're building Slicehost for payments, but the fundamental economic primitives of the internet are horribly broken. It's incredibly difficult in every single case to transfer money from A to B. If I'm building a product in the US, even if I accept credit cards, the majority of internet users cannot transact with me because most people don't have credit cards. If you're in Indonesia, Germany, or Guatemala, you probably can't purchase from my website. I'm not actually selling online, or I'm selling to a small subset of internet users. If I'm in one of those countries, it's even harder to start accepting payments online. There are all these disenfranchised users and a whole raft of problems. Because it's been so bad on the internet up to now, we've almost lost sight of just how bad it is. It's remarkable that in 2012 you cannot accept payments from the majority of internet users. As these realizations percolated, we started to take Stripe more seriously and systematically talk to people to hear their pain points.

A

Andrew Warner43:22

How do you systematically do it? What's your process?

P

Patrick Collison43:25

Systematically? Still just talk to lots of users, get more of them, interact with them constantly.

A

Andrew Warner43:31

How do you do it? I'm not looking for the most professional setup that gets taught in Harvard business classes, but even if it's just a casual way, how do you do it consistently?

P

Patrick Collison43:46

I think it's all about maximizing the contact between the people building the product and the people using it. For the first year, we were the only people doing support. If you had a problem with Stripe, you emailed us and we fixed it. That was a great incentive to fix the actual issues people run into. To this day, both John and I do support. Most people at the company do support. The people building the product hear directly from users constantly. That's the long and short of it. We'd often have users come over to our office, or we'd go visit them.

A

Andrew Warner44:48

You visit people's offices.

P

Patrick Collison44:50

Oh, sure. We visited tons of our users.

A

Andrew Warner44:52

What do you see when you look at someone's office?

P

Patrick Collison44:56

With regard to Stripe or in general?

A

Andrew Warner44:59

Yeah, with regard to Stripe. Do you remember walking into someone's office, looking at their computer, and seeing something you wouldn't have thought of, or learning something you couldn't have done remotely?

P

Patrick Collison45:08

I'm trying to think. My answer is yes, but I'm trying to think of a specific example.

A

Andrew Warner45:14

I'm putting you on the spot, constantly asking for specifics.

P

Patrick Collison45:18

It's a good way to do it. Yes. There was a company selling robots on top of Stripe. They were one of our favorite users because they were selling robots. I remember visiting their office. They didn't sell a ton of robots — the robots were pretty expensive — so they hadn't automated the procedure for charging for a robot. When they got a sale, someone would review the order, and then the guy would literally start typing a curl command to charge the credit card. At some level, it was cool that the API was simple enough for him to do that every time. But it suggested we should have a method within Stripe for performing an ad hoc charge. Now, if you log into your Stripe account, you see a button for "new payment" where you can type in a credit card number and amount and charge the card. Visiting his office was the first time I realized that might be a use case.

A

Andrew Warner46:45

What a great story. So when you walk in, you just say, "Hey, how do you interact with Stripe? Can I watch what you do?"

P

Patrick Collison46:55

Oh yeah. I find that stuff super interesting.

A

Andrew Warner46:57

Do you have them do specific tasks, or do you just say, "Do whatever you do and I'll watch"?

P

Patrick Collison47:06

By and large, yes. We've done less of this than I would like. One thing we did was hold an event at our office about two months ago — Stripe office hours. People could come by if they had a problem, questions, or wanted to integrate Stripe. We just hung out, helped out, watched, and interacted directly. That was really useful.

A

Andrew Warner47:36

So Patrick, that brings up another question. When you invite people into your office or go to theirs and get a suggestion, it's hard not to do it. But if you do everything people suggest, Stripe won't be such a simple way to collect payments because it'll be overloaded with features. You're smiling. How do you decide what to do and what not to?

P

Patrick Collison48:01

It's hard. I don't have a great profound answer. It's a combination of things. We remove features that no longer exist because an insufficiently large number of users cared about them. We iterate on features a lot. For example, Stripe.js — you can drop a single JavaScript include into your page, and it helps you submit a credit card number directly to Stripe. We tokenize it and give you back a token that's not sensitive and not subject to PCI. That feature is on its fourth or fifth major iteration. It's gone through different implementations in ways that have been challenging because we have to support all the old users and make sure we don't break anything. We constantly try to figure out where the natural boundaries are in terms of functionality.

A

Andrew Warner49:44

Emmett Shear from Twitch TV said he has people rank their frustrations on a scale of 1 to 10, so he knows which items are most important. Do you do anything like that?

P

Patrick Collison50:05

We do some of that internally. We'll go through user communication and support emails and chats. One thing Stripe does that I always want when dealing with companies is you can jump into a chat room immediately and start chatting with the developers.

A

Andrew Warner50:28

Someone sends you an email, you respond, and you say, "Let's get into this chat room and start talking."

P

Patrick Collison50:32

You don't even need to email us. You just go to stripe.com and start chatting. That ends up being productive because one question often needs clarification and leads to another. We distill the chat transcripts and emails and rank people's pain points and issues. That's similar to what Emmett does, but we do it more latently — we don't ask users to rank, we just rank based on what the overall set of users has brought up. But it's also a lot of taste — where do we think Stripe should go? Based on all the feedback, maybe nobody has asked for this specifically, but if we did it, it would solve a whole host of use cases. It's a balancing act. You always want to sand off the rough corners of the product, but you can't let immediate feedback drive it too much. We err on the side of figuring out what people actually want. The people using Stripe and selling things are not experts in payments, and they shouldn't have to be. That's the whole point. When they come to us with a problem, they might know what's possible. For example, they might complain that PCI forms are confusing. A feature request we often got was for an automated tool to fill out PCI forms. But what would be way better is if we just made PCI go away so it's not something you have to think about.

A

Andrew Warner52:29

What is a PCI form?

P

Patrick Collison52:32

I'm glad you don't know. PCI is the industry standard around the protection of credit card information. There are various self-assessment questionnaires that businesses are required to fill out depending on what they're doing. Stripe.js enables a ton of these businesses to get outside the scope of PCI altogether.

A

Andrew Warner53:00

I see. So they would have asked you to make it simpler or help them autofill it, and you said, "Maybe what we should do is just get rid of it if it's that frustrating." Were you able to get rid of it for them pretty early on?

P

Patrick Collison53:13

No, is the short answer. PCI is really complicated. They store the card on Stripe, and we give them a reference to that card, so the number never touches their servers. PCI is pretty complicated and subtle. It's an ongoing dialogue with the folks making the standards, the card companies, the banks, and the auditors who do PCI audits. We are PCI certified ourselves. That came much later in the history of the company.

A

Andrew Warner54:07

All right. Let me say this, and then I've got to come back and ask you two follow-up questions. First, if you're a Mixergy Premium member, you know that Kissmetrics and a lot of people who follow Eric Ries' lean startup philosophy go through a specific process of talking to customers with specific questions. We got someone from Kissmetrics, Jason Evanish, to teach that process on Mixergy. We're editing it now. If you're a Mixergy Premium member, it should be on mixergy.com soon. If you're not, sign up. I'd love to use Stripe because I get all these different things you're talking about. I don't want the paperwork. I just don't know how to integrate it with my membership plugin. If I could, I would pay someone to integrate Stripe properly. I would much rather have Stripe than what I deal with now. I never talk badly about the system I use, but the process involving PowerPay is not ideal. I see people who use Stripe, and I would pay someone to integrate Stripe with my plugin, WishList Member. If I can get somebody to plug in a better system, I'd love it.

P

Patrick Collison56:06

Stripe is a better system.

A

Andrew Warner56:09

And I would pay them. This doesn't have to be a favor for Mixergy. I'll pay you. All right. Now I've got to ask you two things based on my research on you that have nothing to do with what we've talked about so far. The first is you sold your previous company for $5 million to LiveCurrent Media. I heard some people thought you sold too soon. What do you say about that?

P

Patrick Collison56:38

They might be right. It's hard to know. For us, with Optimatic, we were very interested in providing liquidity for used items. I think a lot of the most exciting startups are about introducing or facilitating a new kind of coordination that wasn't previously possible. Kickstarter, Uber, and Etsy are perfect examples. In the case of used goods, it's inefficient that there's so much stuff in the world. There's totally somebody who could make use of this and for whom it would be great value. For my old iPhone, there are billions of people who would love to have it and would give me something for it, but how do I find them? We were really into that problem space. Optimatic was our first step — we were taking people already selling on eBay and making the process more effective. We planned to think about ways to make buying easier or build a better marketplace. It was an interesting time for that ecosystem, with eBay declining, Google thinking about it, and Facebook launching Marketplace. From our standpoint, we were excited by what LiveCurrent was doing. In our conversations, it was clear they wanted to do something very similar. Frankly, we were pretty young, Optimatic was new, and there's a nonlinearity to the value of money. Having that small bit of liquidity was compelling. It subsequently enabled us to be freer to explore and do things. For side projects like Encyclopedia and even Stripe, the fact that we could take a month and hack on Bonanzas was facilitated by that sale. We were freer.

A

Andrew Warner59:57

You didn't have to worry about money, so you could think about what you wanted.

P

Patrick Collison1:00:00

Yeah. It's not that we were set for life, but we were somewhat freer. Having that little bit of incremental freedom was really valuable. I have tremendous respect for entrepreneurs who don't sell. With Stripe, we obviously haven't so far, and our intent is not to. But it gave us the freedom. It's a personal choice, situation and circumstance dependent.

A

Andrew Warner1:00:40

What about Buenos Aires? I spent a year there, and working on Mixergy there made my interviews better, my comfort in front of the camera better. I had no idea you'd spent time there.

P

Patrick Collison1:00:57

Yeah, 2010 pretty much. It's such a fantastic city.

A

Andrew Warner1:01:02

It was fantastic. For me, it was complete focus on my work. It was like my Shaolin, where I got to focus and train every day. And because people have dinner at 10 PM, I could still go out at night, have dinner, have friends and conversations, and be back the next day.

P

Patrick Collison1:01:18

It's so funny to hear you describe this because I've been seeing exactly the same stuff. It's like a city on the hacker schedule. It starts late. You can have dinner at midnight, no problem, and roll into bed at 3 AM. There's Wi-Fi everywhere. Because people speak a different language and I don't speak Spanish, I don't overhear all these conversations around me.

A

Andrew Warner1:01:43

You don't get sucked into meaningless conversations.

P

Patrick Collison1:01:46

Yeah. It's really cheap, which is nice. You can spend a ton of time there focusing on one thing. The food is great, the weather is great, there's Wi-Fi at all the cafés. I'm preaching to the converted here.

A

Andrew Warner1:01:59

But I think it's important to say that it was huge for me. It was huge for you.

P

Patrick Collison1:02:04

I have incredibly fond memories of that city. I haven't been back since, but I've been trying to find an excuse ever since. I definitely will before too long.

A

Andrew Warner1:02:13

All right. Final question is, what advice do you have? I'm looking at Paul Graham's blog post about you. How fantastic was it that he singled you and your company out as a model of the kind of companies he admires? He says, "For over a decade, every hacker who'd ever had to process payments online knew how painful the experience was. Thousands of people must have known about this problem. And yet, when they started startups, they decided to build recipe sites or aggregators for local events. Why work on problems so few people care about and no one will pay for?" So for someone who says, "I want to notice this problem that others are ignoring," do you have a piece of advice that will help them do that?

P

Patrick Collison1:03:00

Yes. I'm not sure how you notice them, but the advice I have is about how you think about them. Almost definitionally, the harder problems are mechanically harder — there's more to do, think about, and solve, and the solutions are less clear. But I think they're actually easier in a really significant way: they're easier to motivate yourself to work on, motivate others to work on, and get a bunch of people together to really solve something. I hate to pick a specific vertical because in almost any area there are good companies doing good work. But let's take recipe apps since that's the example he uses. I have nothing against recipe apps. With a recipe app, you want to assemble amazing people to really nail a problem. But if it's a recipe app, it's harder to do that. You know, Andrew, this interview stuff is awesome, but why don't we go and solve recipes? That can be harder. Not just harder — for yourself, when you wake up in the morning, you're like, "I'm really going to solve recipes today." Whereas if you take the other extreme, like Elon Musk, you wake up and think, "What's the next step in putting man on Mars?" In that philosophical, existential way, the hard problems are actually kind of easier. That's a huge win. It makes life so much easier in so many ways. When people get really excited about the problem you're solving, like for us, trying to fix the economic infrastructure for the internet as a whole — that gets people motivated and excited. That's the one piece of advice I have.

A

Andrew Warner1:04:53

That's a great place to leave it. Thank you so much for doing this. Of course, guys, the site is stripe.com. Thanks.

P

Patrick Collison1:05:01

Thank you very much.

A

Andrew Warner1:05:02

You bet.

Lost Early Patrick Collison Stripe (2012) Interview

About Patrick Collison