Pro: they abstracted away the intricacies of getting "KYC" approval to take payments and abstracted the merchant services integration, so a developer could be up and taking payments in hours, rather than weeks/months.

Con: they abstracted the relationship a merchant has with their processor, so now they stand between you and your money, they decide whether you get it or not, or if you're banned or not, and you have no recourse if they decide your story isn't compelling enough.

To add to this, one of their biggest pros was the developer documentation.

The quality of documentation that Stripe had stood out not only in the payment processing space, but in the industry as a whole.

Completely agree, thank you for adding that. Their documentation was a head above the rest; personalizing the example API calls with your key/token included within the documentation made it trivial to try it out and see something working almost immediately.

Dealing with banks was in many places horrible (still is probably). And more expensive. And worse than Stripe in every way you can think of.

You'd have to physically visit the bank. If they didn't like how your face looks, that's it. They'd say no we're not going to let your company open a merchant account for card payments. Or if they didn't like your last name, your age or your sex.

Then all kinds of strange fees. Although if you were a physical location with a high transaction volume, then banks offer better rates than Stripe.

Then your actual commerce software. The best quality systems for online sales all work with Stripe, and not with your local bank's offering. So if you want to forego Stripe, that also means you need to use a lower quality system. Meaning a worse experience for customers and for you and your staff.

I think they made it far, far easier to implement them as a payment provider vs PayPal etc. That was the first innovation.

Essentially, all they did was have a good API. They brought nothing that did not exist. They just made it SLIGHTLY easier to integrate payments into your website or mobile application. That's about it.

Previously you had a few choices, go with:

1. PayPal, who wanted to own the customer relationship

2. A payment processor who all had awful APIs and you had to do lots of setup around having a merchant account. Authorize.net I think was one of these. Recurring payments were often a nightmare to get to work.

3. An intermediary processor, who didn't need you to have a merchant account, nochex, Worldpay, sagepay, etc. who again generally all had awful APIs and hard to embed widgets and complicated setup processes. Again, recurring payments a nightmare.

Stripe solved all these pain points, and the API was great. It wasn't one pain point they solved, it was many.

You controlled the customer relationship, it was easy to embed the stripe widget, it had a great API, you didn't need a merchant account and the setup was quick and easy. Recurring payments were (fairly) easy to set up. Oh, and great documentation! That was another big thing.

And then they brought out a little widget you could attach to your phone/tablet to allow easy in-person card payments!

It probably seems a bit incomprehensible now, but this was a time when everyone did everything slightly awkwardly. Integrating with any third party was a big job. Documentation was terrible. Formats were all over the place. SOAP, XML, JSON was only just emerging as the defacto standard. For example, the APIs. Great APIs were rare, as far as I remember twilio and I think MailChimp really blazed the way there. Companies like Google were putting out absolute dogshit, complicated APIs, often strict REST with weird header requirements, or strange signing with private keys. If you've never dealt with it, strict REST really, really sucks.

I think I watched somewhere they stopped you from having to deal with banks individually.

paypal fees are ridiculous