This is a horrible, horrible adventure for anyone trying to launch a new service. I was dreading this part of the process. The reason? Payment providers almost always suck, their technology and API are outdated and usually their fees are outright absurd.
So a little background is in order. In late 2012, early 2013 myself and a partner, the venerable staxmanade, founded a company called Resgrid. This company is a cloud service that provides logistical and management tools to first responder organizations (career and volunteer fire departments, EMS, search and rescue, public safety, hazmat teams, etc).
After a year of offering the service completely free we just recently started changing for the service. We do offer a forever free plan as well for smaller departments.
The first thing you will need to do is determine your requirements. This is actually a pretty easy process just ask yourself these simple questions:
- What will I be selling, products or services?
- Will I have a shopping cart?
- Are my sales more one off items/payments or reoccurring?
- Will I be offing a subscription?
- If offering a subscription will there be multiple levels?
- What countries and methods do you need to support?
- Mobile, Website, Both?
- Do you want coupons or promo codes/rates?
The subscription thing is a big deal, there are not many payment providers out there that do it well, or at all. All of them will do some reoccurring payments, but that’s not a real subscription style offering. If your service only has one subscription level, then any reoccurring payment provider will work for you. Why is subscription support important? Or at least total control over payment amounts and ability to control refunds? Customer service. If you have multiple tiers of a service, you WANT your customers to upgrade and that be a smooth and fair process. Say you bill yearly and your customers prepay, half way through the year they upgrade, what do you do? You cancel their existing sub, prorate the unused portion of their existing sub toward the new one. This sounds easy, but with some payment processors this is a huge pain.
Additionally, and depending on your circumstances, the country support could be a huge issue. So you will need to ensure that the payment processor you choose has support for the countries you want to support. This isn’t a comprehensive list of payment processors, instead it’s our opinion about the ones we looked and and ultimately why we made our decision.
Authorize.net is the granddaddy of payment processors. They’ve been around for as long as there has been an Internet it seems. It’s a trusted payment provider which every shopping cart or merchant system seems to support. Authorize.Net also has lots of integration options, for example PHP, Ruby Java and .Net. They also support eCheck which is a plus, especially in the B2B space and decent International support.
There is a lot to like about Authorize.Net, but there is also a lot to dislike. First and foremost is there fee’s, they charge $99 to setup, then they charge you $20 a month, then they change you 10 cents per transaction.
Authorize.Net supports reoccurring billing, but not a great subscription system. Also their API is quite dated, if you used to a more modern RESTful API and well defined method calls in their SDK’s on the platform side. It almost like calling COM+ interfaces/objects. In the end we choose not to use Authorize.Net due to it’s older implementation and it’s high fees.
I would say that 2Checkout is another venerable institution of online payment processors. They have great International support, they even support checking out via Paypal which is amazing. Also they have their own integrated shopping chart, which is bonus.
2Checkout is also expanding their API to be far more modern. I would say that, as a whole, Authorize.Net has a better API/SDK then 2Checkout (2Checkout also supports Authorize.Net calls, so it makes switching easier) but 2Checkout is in the beta period of a new API that is far more modern then anything Authorize.Net has.
2Checkout also has, what I feel, is the standard pricing model, 2.9% and 30 cents per transaction, BAM simple. No monthly, no setup. I would recommend 2Checkout, especially once their new API is available. Where 2Checkout didn’t work for us is that we wanted good subscription support and an awesome API. But we are keeping our eye on 2Checkout to see what the future holds.
What can I say about PayPal that everyone doesn’t already know, it’s PayPal and probably the best know payment processor out there, sorry Authorize. Up until recently PayPal didn’t do well with International card payments. That’s slowly changing, but it could still be an issue for you. Where PayPal shines is, in my opinion and experience, is customer trust. I hate giving every single site on the Internet my payment information, I don’t know what they are doing with it and if they are storing, with PayPal I know.
Fee’s are the standard 2.9% + 30 cents, so good to go there as well. But where does it fall of the rails? Their API and Subscriptions. You can have reoccurring payments in PayPal, but that’s all. In Resgrid users prepay at the start of their billing cycle, we allow them to upgrade their subs at any time, and when they do we prorate the unused portion to their new upgrade and deducted that for their upgrade. This is not an easy thing in PayPal and it might be impossible. Also their classic API is horrible. Thankfully they are launching a new RESTful API, but until we can adjust payment amounts on the fly and easily cancel reoccurring payments this won’t work well for a multi-tiered subscription service.
I’ve been hearing about Dwolla for a while now, but I’ve never used them as a customer. Dwolla seems to be taking their aim squarely at PayPal. The service they provide and their product offerings seem to be very close to PayPal. I couldn’t find much on International support, reoccurring billing or subscriptions, so that seemed very limited at best.
Where Dwolla shines is their API and their fees. Their API is very, very good, and their fee’s are amazing. No fees for transactions under $10 and just 25 cents per transaction otherwise.
If your looking for the lowest cost payment processor for US payments with a good API, then look no further. Unfortunately for international support, reoccurring billing and other features it seems that as of right now there isn’t that support in Dwolla. Which is why we didn’t implement that in Resgrid, those are just too important for us.
There is good, then there is Stripe, yes Stripe is that good. It’s not perfect, the International support just isn’t there right now and they themselves don’t have an SDK for the .Net platform. If it wasn’t for Jayme Davis’s Stripe.Net we might be using 2Checkout. Hey Stripe, pay Jayme Davis and make that project officially supported!
Stripe has the standard fee of 2.9% and 30 cents, so all good there. But where does Stripe shine? Their API and API documentation are amazing! Coupled with the Stripe.Net OSS project supporting the most complex payment scenarios in your system are a snap.
The feature that sold us on Stripe was the subscription system, which is like reoccurring payments on steroids. Stripe will handle canceling the pervious sub payment, handle prorating and bill accordingly, complex sub scenarios handled in a snap.
So Resgrid went with Stripe, but we may move to 2Checkout in the future if they continue going the way they are going, we would love to support PayPal, but interacting with PayPal directly is a huge pain, and in our opinion compared to Stripe lowers our customer experience. This isn’t an all inclusive list and there are many more payment processors out there, Braintree is a promising one that I may look at soon, Amazon Payments and Google Checkout are a few more, but we didn’t look closely at them.
Choosing and integrating with a payment processor is not fun and can be a very painful experience. But it could be one of the more important decisions you make for your product or service. Making your purchasing experience as good and easy as possible and it will help those conversion rates.