I spent a full week evaluating Amazon, PayPal, Authorize.net and a couple of smaller players (don't remember their names). I even posted a detailed report here somewhere in August.
Authorize.net is the big daddy of online payment processing. I found it to be most developer-oriented too. Amazon suffers from unnecessary complexity and tied to their own stuff too much, besides not a single support person (on the phone) knew anything about it. PayPal was not very "customer friendly", in fact their sales people sounded like typical scammers/car salesmen and overall PayPal not as developer-friendly as authorize.net
In the end I implemented everything (one-time payments, scheduled payments, etc) in just two evenings using a couple of PDF downloaded from authorize.net.
By the way, another reason to use them is the dev. community. Thousands of devs built stuff for authorize, i.e. there are libraries, code samples and docs on numerous blogs for every imaginable programming language/framework.
I think cheapest and easiest depends on your situation. I've used FreshBooks[2] with PayPal for some online services. I've also used Kagi[1] too. I'm looking forward to Amazon DevPay[3] when it becomes generally available.
The thing to note here, in my opinion, is to not implement it as they have. Do not store the credit card numbers on your own system. Instead, read through the comments. A few people talk up TrustCommerce (http://trustcommerce.com/), and it looks pretty good .
Note: I've never used it, just pointing out what others said. I do plan on using it sometime, however.
I've used TrustCommerce and I highly recommend them. I've also used authorize, paymentech, and cybersource. TC is head-and-shoulders above the rest IMO.
BrainTree (www.braintreepaymentsolutions.com) works great. You could store CC info if you want but with their SecureVault, you can have them store it and get back a unique token for the customer. In this way, you can still process your subscriptions and charge customers each month but you store no critical CC info in your own system.
The easist method depends upon your customer. Therefore, it could be beneficial to implement multiple payment mechanisms. Customers could pay through the most familiar and trustworthy mechanism. You could most heavily promote the method that takes the least commission. This would allow new and experienced users to select the most optimal method autonomously.
An often overlooked payment method is sending a cheque in the post. For many people, this is considered to be a superior channel for security. It also allows payment for those without a credit card. It also increases trust because you have to provide an accurate postal address. From my experience, sales by cheque equal sales online. Therefore, you can double sales with this option.
They all kinda suck it seems in some way. I'm working with PaySimple now and the service has been pretty nice, but it was a lot of paperwork and hassle, and now the effort in using the API..
They were the defacto standard of people selling ebooks, but now they look like they have a recurring option. Their commission is higher I'm sure than a merchant account + gateway, and you have to use their credit card form, but it's probably the easiest to setup and lowest setup fees.
Authorize.net seems to be the bigdaddy in the space, and in my experience they're a pain to set up, but service is fine once you've obtained an account and wrapped your head around thier Extensive but hard to navigate documentation/API.
They also offer options of writing your own form and CURLing them to submit the data, or using one of thier forms, and they offer pretty good payment tracking (including search by cc data, and quickbooks files).
Not sure about thier price point, but the few credit-card processing businesses i've worked with have all chosen it prior to my involvement, so i assume it's a good 'safe' choice.
The real challenge is building out the back-end that deals with the service you select. (Unless you plan on handling unsubscribes manually, which might not be a bad idea if you are dealing with a low volume of users. IE: I'd pay someone $8/hr for an hour a day before I committed an $80/hr developer to spend a month building a system, until they are spending more than an hour a day dealing with orders.)
I was consulting for a company where we spent weeks building and testing the back-end component that worked with Paypals API. Their API is embarassing. Instead of building a system that allows you to poll for unsubscribes daily, their server "pings" your server with data periodically. Imagine the difficulty of testing this out when they don't provide a way to simulate this.
So if you do decide on a back-end, spend some time seeing if there is an open source component you can use to handle subscribe/unsubscribes. (Maybe ActiveMerchant?)
I don't think they have that option, but I haven't looked in a couple years.
I generally try to stay away from PayPal, because they're not a bank. Their user agreement states that they're not liable or responsible for "lost" funds, and I've heard of people getting burned by that. If you use them, I would advise withdrawing often.
They burned me for somewhere around $300 when I sold some stuff on eBay. Allegedly, the account that I was paid from was "hacked", so they took money out of my account about a week after the transaction took place. I will never give that company another dime of direct or indirect income again in my life, be it from my personal or business life.
<snip>"You can let your subscribers change the name, number, regular terms, or currency of an
existing subscription without canceling it and re-subscribing by creating a Modify
Subscription button."</snip>
I've been looking at Google Checkout. One compelling advantage is that they don't charge CC processing fees up to 10* what you spend on AdWords. Has anyone here had experience integrating with that?
They don't explicitly handle subscriptions now but that wouldn't be hard to build a recurring charge process.
authorize.net supports subscriptions. it's pretty easy to manage, but I don't know if its the cheapest (it's at least reasonable for our needs, and easy, which is more important than cheap to me most of the time.)
Sounds like an opportunity for a good startup. I've heard this question bounced around a number of times online. Doesn't really sound like there's one great service out there.
If you're running a web site with any amount of customers, you're going to want to let people manage their own subscriptions with no intervention required on your part. If you don't have a way to integrate CC payments in to your product, then you would have to do everything manually.
You still need to have a merchant account in addition to a billing service, and for that, you could just use your local bank if you wanted to. I'd imagine that an online bank would have cheaper fees since there's no brick and mortar side of the business to maintain, though.
Authorize.net is the big daddy of online payment processing. I found it to be most developer-oriented too. Amazon suffers from unnecessary complexity and tied to their own stuff too much, besides not a single support person (on the phone) knew anything about it. PayPal was not very "customer friendly", in fact their sales people sounded like typical scammers/car salesmen and overall PayPal not as developer-friendly as authorize.net
In the end I implemented everything (one-time payments, scheduled payments, etc) in just two evenings using a couple of PDF downloaded from authorize.net.
By the way, another reason to use them is the dev. community. Thousands of devs built stuff for authorize, i.e. there are libraries, code samples and docs on numerous blogs for every imaginable programming language/framework.