[there]

TL;DR indeed. it doesn't have to be that complicated.

i needed a credit card processor for corduroy (plug: http://corduroysite.com/) to process monthly subscription charges. i filled out a form (i think, it was 2 years ago) on braintree's website (http://www.braintreepaymentsolutions.com/), they emailed me back some info, i filled out and faxed over their forms about my business and already-established checking account, they created my american express/discover/visa/mastercard merchant accounts for me, and i used activemerchant (http://www.activemerchant.org/) to talk to their gateway via my rails app. according to my email archive, i received the signup forms from them on april 14th and they emailed to confirm my first charge through their gateway on april 22nd.

i wrote some simple code to use activemerchant to process the monthly subscriptions from a cron job that submits a charge to braintree using the customer's vault id (the only thing stored locally, braintree actually stores the credit card and address information) and the subscription monies are deposited into my bank account the next day.

i get a monthly statement from braintree in addition to instant email receipts. i've had to change my bank account and address information once, which involved contacting braintree and american express/discover/visa/mastercard and was relatively painless.

i'm not sure what is so difficult that services like recurly are trying to make easier, but if the problem is lots of different points of contact, i'm not sure that another middleman is the answer. braintree stores and charges the credit cards, the credit card companies deposit the money into my local bank account. simple.

[sunir]

Billing can get complicated if your customers are other businesses and need proper invoices and account statements for tax purposes, not to mention managing coupons, refunds, expired credit cards, credit card failures, account suspension rules, etc. which apply to all classes of customers.

Most web apps are too small to worry about these issues.

(Full disclosure. I work at FreshBooks and I'm actually the product manager of recurring and subscription billing.)

[sachinag]

Ha, looks like Bryan owes you a beer for this ringing endorsement. :)

There are a number of reasons why it can be that complicated - doesn't always have to be, but I think you are the exception rather than the rule.

First, most people just don't have a basic understanding of how it all works. The idea that a merchant account isn't a bank account at all is non-obvious to everyone I've walked through payments hell with. Recurring billing, in particular, is a huge pain in the ass, especially with upgrades and downgrades that users do as they try to optimize their freemium subscriptions. (There wouldn't be at least four companies doing just this if it wasn't a total PITA.) If you're not built in Ruby, and you can't use ActiveMerchant, you really have to evaluate the documentation for each of the various gateways - and good luck finding out the names of all of them - before you can even begin. AmEx, in particular, is a whole 'nother circle of hell, although OnePoint solves a lot of these issues (but, of course, for a price).

Honest to God, I'm going to try to learn Ruby this summer purely because ActiveMerchant exists. My existing startup is coded in PHP with a dash of Perl and Python, but online billing is so complex and so tedious that I'm learning a language that's not useful to my existing startup because payments are so hellacious.

[enjo]

Well, he may be the exception but it lines up with my experience (also Braintree). I think I've spent a grand total of 1 day on our billing system. We do threshold billing, monthly subscription, and one time payments. We use the Braintree vault and everything just sort of works.

I've done some work with various authorize.net resellers in the past with similar results. Really, understanding the magic that is interchange rates is the most difficult piece of the whole equation:)

[lunaru]

To add to there's point:

When I first started getting into subscription based services about 2 years ago, googling "recurring billing rails" brought me ActiveMerchant, a few Payment gateways, and some blog entries about getting a merchant account which is all you need. I was on my merry way.

Try that same query now and it's full of noise. You get rants from various people and you get companies peddling their services. While I agree that new services are helpful and are an essential part of the eco-system it's becoming really intimidating for newcomers because it's so hard to get the bare minimum truths one needs to know.

Sure, there are many payment gateways to choose from (Auth.net, TrustCommerce and Braintree are great with ActiveMerchant, btw). Sure it's a lot to thinking and worry about. We're talking about taking money out of other people's pockets here - there should be at least a little bit of effort right?

If you're intimidated by recurring billing issues - get over it, it's really as easy as there makes it out to be, especially when you're just getting started. There's time to fill in the details (like coupon codes, special offers, prorating, etc) after launch. For now, I'd suggest ActiveMerchant + Gateway + cron job and worry about getting customers instead of worrying about your middlemen.

[terpua]

For a moment there, I thought your company was funded by Google Ventures: http://gigaom.com/2010/05/03/what-entrepreneurs-should-know-...

[ahoyhere]

Last I checked, Braintree doesn't want most startups - their site says they didn't want anyone under a threshhold of $LARGENUM per month. I recall it being quite high for a non-existing service - like $20k to $50k.

Braintree seems to simplify the work by a lot. On the other hand, use another provider, and PREPARE TO SUFFER!

I wrote about our pains w/ Auth.net in specific (and cc processing in general) here: http://letsfreckle.com/blog/2008/12/ecommerce-stuff/

[bryanjohnson]

We (Braintree) now work with companies of all sizes, including a lot of startups, and have no volume requirements. In the past we did have volume requirements. We were a smaller company then and were trying to balance maintaining a high quality of service when working with more leads than we could handle. We'll be blogging about this in greater detail.