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.
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.
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.
I just looked at ClickBank. http://www.clickbank.com/recurring_billing.html
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.
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.
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 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.
<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>
They don't explicitly handle subscriptions now but that wouldn't be hard to build a recurring charge process.
http://checkout.google.com/support/sell/bin/answer.py?answer...
https://www.paypal.com/IntegrationCenter/ic_micropayments.ht...
$0.05 + 5%
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.