How Stripe Wins over PayPal

It could cost you more than 4 times as much to use PayPal instead of Stripe

I’ve had such a horrible experience with PayPal recently that I thought it a good idea to share.

First off, PayPal’s widely known for freezing money and all sorts of schenanigans. To be clear, I’ve never had issues with this personally. Though I do personally know folks who have had their accounts locked due to silly things like “brand association” and such (which ended up in demands from PayPal to have complete access to a company’s system!). This is bad because it can really hurt a business. So for many, using PayPal is a risk.

If that’s not reason enough to avoid PayPal, that’s ok. Those kind of risks are not what I’m talking about here. I’m more interested in explaining why it’s a technical burden to use PayPal.

I had to setup recurring billing for work using PayPal. Why PayPal? I’m not entirely sure, but the higher ups felt the rate was better. True enough if you make a transaction of a certain amount or have enough volume you can get a better rate than Stripe. So theoretically your fees can be lower and over millions of transactions this would save you money. My argument is why, as a startup, worry about that now?

Anyway, using PHP (the Laravel framework) I built the recurring payments using PayPal’s classic API. It took nearly a month to get all of the plan management, downgrades, and proration coded and tested. There are a ton of paths a user can take even for 6 plans (3 monthly - 3 annually discounted). So testing alone took a good while due to all of the upgrade/downgrade paths.

Burden #1: You manage everything

You must setup all of your billing profiles in your code. There is no web interface that lets you define plans. There is a terrible amount of code complexity should you want to offer discounted introduction trial periods and such. You must keep track of all of this. This leads to a lot of technical debt and maintenance.

What if you need to adjust a plan? What does it mean if you need to add more plans? How much work is involved? How does it fit into your development and release schedule?

All of this must be built on your dime. It’s an enormous burden.

Burden #2: Terrible API

PayPal’s recurring billing profiles can take up to 24 hours to setup. There is an optional initial amount to charge (for things like setup/enrollment fees), but this could take a while to hit your IPN (payment notfication sent to your server so you know the user provided a valid payment option).

What does this mean for you, the site/app owner? It means you could be providing free service for a little while until it’s discovered the user gave you expired payment information.

So PayPal’s official response to overcome this burden is to issue a one time immediate transaction. This way you can know instantly if it failed or not. If so, your code can simply not setup the recurring billing profile. Easy enough.

Easy enough, until you get into proration and users changing plans immediately. Even a few days later. You can’t simply charge them over again. You must charge based on what they already paid if the user changed their minds before the end of the first cycle. To be fair.

PayPal’s API is horrible. They’ve taken steps to start working on a new one that promises to be better, but most people still use the classic API due to all of the available, time saving, 3rd party libraries in existence. I truly can’t trust in them to build a better API though, this is by far the worst API I’ve ever worked with in over 10 years of web programming experience.

Burden #3: Their API Approval Proccess

After everything was coded and working in their sandbox…We ran into a problem going live.

We previously had an application setup to use their API (from their dashboard, you must setup “applications” which manage what your code can access), but didn’t realize that there were all these checkboxes that dictated which API methods your application could access.

Note: The sandbox gives you full access. So you won’t know if you setup your application correctly until you go live. There is no way to test that you have checked off the appropriate options. This leaves you in a possible situation where something does not work upon going live.

So how hard is it to setup the application’s access? As it turns out, it’s pretty confusing. The options you can choose from do not match their API. At all. The phrasing is different. Check the option you think you need and hit submit for approval.

Yes, it takes time to be approved if you are using anything more than the basic features. It’s pretty quick though and a day later we got a response.

We were told that we didn’t select any options that would allow us to take money from people. What?! We selected the recurring billing option…How is that not what we needed?

The customer service rep told us what to check and it turns out that left us with an application that looked exactly like our old one. The old one which we knew certainly did not have access to the API methods we needed.

Note you can’t edit your application profiles (afer they are approved) within PayPal’s site. You can only make new ones. So should you need to access a new API method, guess what? You need to submit a new application and wait for approval all over again.

Be sure to take this into consideration when figuring out how long it’ll take to add a new feature to your site/app. It requires a process that is now completely out of your control.

Here it is now a week of back and forth e-mails with them trying to get access to their API. We literally can not charge users now for a week. This could result in a huge loss for a company.

They have even told us that we wanted to use the “Preapproval” API operation when that’s not quite right either. That API operation has a $2,000 limit on it. We don’t want to hit that limit and tell the user they must provide payment information yet again at some point in time. What a terrible user experience for our users that would be.

So their customer service reps clearly don’t understand their own API, yet they are gate keepers of it.

The Solution?

Use Stripe. It handles plan management, proration, discount codes, and more. All from an admin web page interface. This literally can save you a month’s worth of development time. I have setup Stripe over a weekend before. It’s very easy to use. It’s not confusing.

If you follow any of the burn rate discussions and estimates out there then it’s easy to calculate your up front cost to use PayPal. If it takes a month or so (and the attention of several employees), you can easily be paying $10,000+ to implement recurring payments by using PayPal.

If you use Stripe and it takes a week, it would theoretically take $2,500 to do the same thing. Not to mention you can release something sooner. Then you have the added benefit of managing discount codes, plans, etc. from a web admin interface that Stripe provides. Making many tasks code free chores.

I didn’t even mention the part where even more code would be required to build a tool to manage those recurring billing profiles with PayPal. If you need customer service employees to look through a list of paying customers and forcibly cancel subscriptions for any reason – this is additional code you must write.

Stripe simply wins over PayPal. Now that Stripe works internationally too, there’s simply no reason to use PayPal for payments ever again (other than perhaps if you wanted to let people pay with PayPal maybe).

Even the Laravel framework for PHP uses Stripe for its recurring payments feature. While I don’t think a framework should be doing that, I do appreciate the common sense. Why didn’t we use that then? First, Laravel added that feature as I was building the subscriptions with PayPal and second, my advice for Stripe was ignored. The savings for small transactions was the reason.

Yes, all to save a few pennies here and there while we just spent 4 times as much in development costs. Hopefully it balances out in the long run, but I doubt it.

Tags// ,
More Reading
comments powered by Disqus