HN Explorer

Poll: How do you bill recurring payments?

117 points by ceslami ↗ HN
Since many web applications using a recurring billing model, it would be interesting to see which services people use and why.

Please feel free to explain your choice in the comments.

95 comments

[ 3.2 ms ] story [ 104 ms ] thread
patio11
Spreedly provides the logic, Paypal the gateway. It works, it took vanishingly little time to get working eight (a few hours, total), it is fairly inexpensive, and it didn't require a real merchant account, which would be difficult to get for my business. ("You live where? I see. And your business does what exactly? I see. And you have five figures in yearly sales? I see. Thanks, we'll pass.")
ollysb
The spreedly FAQ implies that you need a merchant account.

  "How does Spreedly pay me?

  Spreedly never touches your customers' money - it goes straight into your merchant account."
is this not the case?
rlm
I assume the "merchant account" is a PayPal account in this case.
patio11
Pay pal Website Payments Pro, yeah.
sammcd
Paypal covers both Merchant and Gateway bases. So do Braintree and a few others.

If you have your own merchant account you can use paypal for just the gateway, but I don't think this happens very often.

rlm
Are you using the Payments API or just the "regular" Spreedly functionality?
patio11
Both. Payments to have a totally on-brand signup. The regular "redirect them to Spreedly" to do account upgrades, etc, to save me a day of programming that wouldn't sell accounts.
bradleyjoyce
I use Spreedly on TweetSaver.com ... like patio says, it works great and is easy to integrate... main downside is their reporting sucks really bad and they haven't added any new features in a really long time.
jordanvisco
We did this for one of our startups but had major issues after the first month when it turned out that spreedly doesn't db the credit card cvv ('cause they're not allowed) and then paypal wouldn't let us bill without the cvv code. We've had numerous issues with paypal not letting us do some simple things just because they made a decision at some point that we were sketchy and shouldn't be allowed and they tell us they'll NEVER EVER change their mind.

That said, we still use paypal recurring billing on a few sites cause its just sooo easy to do, even if it is a bit user unfriendly.

SupremumLimit
And also, Paypal only allows transactions without CVV for US and Canadian accounts, so if you're in another country Paypal + Spreedly isn't an option for recurring billing. Took an hour on the phone with Paypal to find this out.
catechu
I use the basic version of PayPal for subscriptions, but I've had issues with canceling customers' subscriptions without their explicit request, and the PayPal support is horrendous.

The fees are a little higher than some of the other services, but it integrates fine, so if you're okay with a clunky but easy to set up service, you might find it useful as well.

ceslami
So if PayPal has issues with canceling subscriptions, has horrendous support, is clunky, and has higher fees, why do you still use it?
mutru
Unfortunately PayPal is pretty much the only option, if you're based in Europe and want to do recurring payments.

I agree with all the points above: the support is worst I've ever experienced, the user experience is horrible and hasn't improved over the years, and the recurring payments clearly don't belong to the product.

milan_cvejic
Well, you can always try 2checkout. They work for europe too :)
jpallen
I use Paypal's recurring billing API directly. It's not an ideal solution, but being based in the UK without a merchant account it's the only one I have available. I use ActiveMerchant and some extensions to talk to the Paypal API but I've had to write the logic to handle recurring billing myself. I'm trying to extract that logic into a gem and make it more robust. I'd like to eventually release it and possibly save some headaches amoung small developers who just want to get up and running quickly.
marquis
We have also dealt with this manually. We'd love to see a more robust API out there that would integrate better with our existing payments solution as we do a mix of subs and license sales. Please post to HN if you get anything of the ground!
lsc
I use freeSide; not sure I'd recommend it, but hey, open source and it handles things like service credits much better than most of the webapps I've tried. I use paypal and/or checks for actual billing

I'm considering switching to one of the webapps you kids seem to like, but most of them seem more like payment processors than billing systems, really, and if I have to maintain my own separate billing system, what's the point?

I am very interested in what other people's experiences have been with the webapps, though.

charliepark
We use Braintree's "Vault" for card storage and have a custom-built set of methods for handling the rebilling. Like jpallen, I'd like to release our logic as a gem, as it took us longer than it should to hack it together. They offer a rebilling service, but I really want to know how my billing system is working, so that if it breaks somehow, I know what's going on with it.
steveklabnik
> I'd like to release our logic as a gem,

Good! Do it! It's really easy: http://timeless.judofyr.net/making-ruby-gems

Is your stuff built on top of braintree's gem, or did you re-implement all of the actual calls to the API? You might want to check that out, it could simplify your code...

charliepark
Sorry. Just saw this now.

Our code is built on top of their gem. We focused on the rebilling logic, which replicates some of their own vault / rebilling code, which most people here would say was a waste of time / money. (Probably was?)

When it comes to billing stuff, though, I really want to know what's going on behind the scenes ... hence ... rolling our own.

As we work out the bugs, I'll try to get a gem together. Would love to have people dig into it and make it better.

lautis
We use PayPal Adaptive Payments. It's far from perfect: all paying customers must have a PayPal account and (in Europe) payments can be set up only for a year in advance. The term "preapproval" is also likely to frighten some customers.

Adaptive Payments was chosen as the standard recurring billing API doesn't allow us to automatically manage subscriptions, which becomes an issue if you have multiple plans. However, we had to implement billing scheduling ourselves. PayPal was for us the only option which didn't require us to store CC information on our servers.

jarin
I've used Netbilling's recurring payment API before (patched support into ActiveMerchant a while back), but now I'm using Recurly with a PayPal gateway.
tzs
We keep the credit card numbers on file (yes, fully complying with PCI) and handle the recurring billing ourselves.
steveklabnik
Impressive. Do you feel this is worth the money and effort? How big is the company?
tzs
We peaked several years ago at around 100k credit card transaction a month, but that line of our business is in an area that is in decline generally (I don't want to go into detail since I'm not a spokesman for the company, but basically it involves selling something that some very big and powerful companies have a strong interest in making free as it is a compliment to their products).

I suspect that the smaller companies like us will be out of this line of business in a year or two, and even the big players will be out of it in 5. Nowadays we're down to about 20k transactions a month.

Back then, it was worth it both for cost and flexibility but now there are a lot more options so I'm going to reevaluate.

garrettdimon
We use Braintree's vault, and we use ActiveMerchant to access it. We wrote all of the recurring/billing/invoicing logic ourselves. Beyond the initial implementation, we've done one sweeping overhaul of the logic to make some improvements and simplify things after learning a lot from the first pass.

We built it in late 2008, and either the companies that handled recurring stuff didn't exist when we were building it, or we weren't aware of the ones that did. Otherwise, it's unlikely that we would have gone down this route. However, now that we have it, it is pretty nice to have control over every detail of how it works.

When we made the enhancements, we briefly considered switching to a provider for handling it, but given our existing infrastructure, it was actually easier for us to improve our own instead of migrating to another provider.

steveklabnik
I did the same thing a while back; you might want to look into the actual braintree gem itself, it's pretty solid. AM is now (for BrainTree, anyway) a pretty simple wrapper on top of it: https://github.com/Shopify/active_merchant/blob/master/lib/a...
garrettdimon
Thanks for the recommendation. Unfortunately, we've been with Braintree so long that we're on their original platform, and the gem only works with the new platform.

The migration to get on the new platform wasn't worth it for us right now. It definitely looks nicer, though, and I'm a little envious of those that signed up later and get to use it.

JonLim
Freshbooks with Authorize.net as the payment gateway.
primigenus
We're using Spreedly on top of Ogone and Atos Worldline. The notable thing about our setup is that we're based in the Netherlands and it took us 6 months of painstaking research and headaches to figure out the combination of services that would allow us to accept subscription payments. I wrote a blog post about the ordeal last week; I recommend it to anyone in a similar situation (eg. non-UK Europe): http://blog.quplo.com/2011/01/looking-back-on-the-quest-for-...
thibaut_barrere
I plan to use exactly Spreedly on top of Ogone (I bought a Spreedly kit a while back and I'm in France).

Thanks for your blog post!

ag
Adyen (www.adyen.com) is based in Amsterdam, did you check them? Anyone has any experience with them?
primigenus
We passed on them because their homepage didn't feel professional and trustworthy.
andrewwebb
We just selected MetraTech for all of our billing needs due to the complexity of our pricing models. However there are lot of great less expensive services if your needs are simpler. A few that come to mind are Zuora, Vindica, Monexa and Aria. If you are pre-revenue Zuora may be a good choice because they have a pricing model that charges a percentage instead of requiring a significant upfront investment.
jcampbell1
I use Paypal, Authorize.net, and First Data, and we use their built in recurring payment options. It is torture. For First Data, I have to maintain a screen scraper because they don't even have a Reporting API.
locusm
Any comment from Australian devs as Im about to go through this myself. PayPal is the anti christ, not an option for me.
maayank
Anti-christ because of things done in the past that you are generally afraid will affect your startup or because of a general sentiment of them being "evil"? If the latter, then not evaluating them because of it sounds like bad business mojo to me...
locusm
Bad experience at both the merchant and user end. Spreedly who I had never heard of till this post integrate with 2 Australian payment gateways so that will be worth checking out I think.
Tones125
We are trying to go through NAB now for a US billing merchant account and honestly they are the Antichrist. It's been three and a half months and we are still not there yet. Painful is an understatement.
El34
Paypal website payments standard is your only option here. Unless you want to bill in AUD, you can't really use a merchant account in Australia. It's technically possible to use NAB to acquire in foreign currencies (ie. USD), but it's not feasible for small startups due to cost and complexity and the bank not actually knowing how. I lost my real HN account because I'm an idiot or whatever, but send questions to wtfaustralia@soundfolder.com if you want to hear about our various failed attempts at recurring cc billing.
SupremumLimit
This is interesting. I'm in the process of getting a merchant account from BNZ in New Zealand, they are a subsidiary of NAB. They are the only option here for billing in USD but at least they have an actual product for it called CurrencySelect and it seems like this is a workable solution and nobody is too confused by it. The fees are pretty high though - starting at 8.1% per transaction and only going down starting from $25K in volume.
SeanOC
I've used CheddarGetter (http://cheddargetter.com) for a few projects and I've been extremely happy with their service.

* API is reasonably nice to work with (wrote a Python client called Sharpy https://github.com/saaspire/sharpy) * Lots of options to control exactly how and when your customers get billed. * Support for a bunch of payment gateways * Tools for handling tracked items and one-off charges (e.g. discounts or fees) as part of your subscriptions. * Fantastic support - I don't think I've ever waited more than a few hours for a response and their support team has been very helpful.

epynonymous
failed to list cybersource, zuora, and netsuite.
holdenc
Amazon Simple Pay is quite good and easy to set-up as well. There are no monthly fees and you get a lot of control over the subscriptions, but the payment experience is hosted by Amazon unfortunately.
[dead] to
we do recurring offers since years and i dont even know what chargify, recurly and spreedly is but just because of their names i wouldnt want to use them. besides that they probably just give you a nice frontend and a nicer API on top of one of the real creditcard processors, which you could use yourself.
Dbodbo
Recurly with PayPal gateway is a scalable solution for startups through large transaction levels. API approach and extreme ease-of-use key to their strengths.
jqueryin
We're using CheddarGetter, they have their own gateway as well. Any positive or negative comments would be appreciated as we're just getting underway.
nopal
I couldn't get a merchant account through them because I didn't estimate that I'd make $10,000 in my first months.
cgbystrom
Same for us, their gateway turned us down.
bobx11
I use chargify but I don't want to vote them up
moklett
If you're willing to share your reason, I'd love to know. I work on Chargify.
dh
Sorry to hear that, as a founder I would love to learn how we can do better. Feel free to contact me anytime and chat.
voxmatt
Question: It's a bit out on the horizon, but in the not too distant future we're going to be implementing a payment system that charges a % of the transaction to us. For example: $110 payment in, $100 to seller, $10 to us.

I've had a real problem finding a recurring billing company that allows payments to be split like this. Any suggestions?

BluSynergy
We are doing this for one of our clients, give us a call: 731-INVOICE (731 468-6423)
shazow
I hate the construct that you must be a business in order to make money. Not only that, but you must be a reasonably-successful business. Talk about a chicken and egg problem.

I'm trying to bootstrap a product that charges between $10-40/mo per user. Right now I have no users, but I hope to get a few over the next couple of months. What are my options?

Do I have to incorporate in order to get a merchant gateway? Do I cut my losses by using Chargify or Recurly and pay $30-40/mo while I am making less than half of that in revenue?

If I'm to remain economical, I'm forced to use Paypal (or Amazon's SimplePay, or Google Checkout) until I graduate to a better position with more customers.

I imagine a more efficient economy someday in the future when peer-to-peer transactions are commonplace and streamlined. Everyone should be able to provide a service or product in an ad-hoc nature before having to invest in incoporation, etc.

As much as I love to hate Paypal, I have to appreciate their forward thinking.

marketer
I think Cheddargetter is friendly to bootstrappers - they have a free plan for up to 20 customers.
noodle
not that friendly. i applied to their special branded merchant account and was denied due to low volume.
cgbystrom
Are you sure it was CheddarGetter that turned you down? I've also been denied but it was one of their supported payment gateways that denied me (even though I applied through CG).

Recently been thinking of changing to Chargify now that they support a payment gateway in Scandinavia. We (http://beaconpush.com, push service for Web Sockets) currently have our custom-built system for recurring payments. It works, but I really don't want to spend time hacking on it. I rather be focusing on our core business of developing our service.

noodle
yes, i'm certain. straight from the email:

"Unfortunately your transaction volume was too low to be approved for a merchant account at this time. "

bradleyjoyce
one option would be to let your early users help you test things out for free.. with chargify, you can set up your site and everything in test mode, without paying for anything (I believe) as you work out the kinks. then you flip the switch to go from test to "live" when you feel you'll be able to cover the monthly fees.

Alternatively, you could do this, but charge your early customers via a simple Paypal recurring invoice until you're ready to turn on chargify.

pkenjora
Free is an option. You could also slap a big "Or Buy This Better Thing" button generated by PayPal somewhere on the signup page. Thats a better option.

Why?

Because, its a great way to A/B test if what you're hoping to sell will get traction even with one person.

Set the expectation for payment early, Dan Martell wrote a solid post on why this has worked for him in the past. If you give it away free with no expectations of payment, it de-values your product. So set the expectation of payment, slap a "Buy This" button ont there.

I sold 6 tea kettles once before knowing where to get them myself. I sent an email to 3 saying sorry were out of stock (fairly true). Then I searched the web for kettle distributors. Sent the email to other 3 asking if its ok if they are a few weeks late. All 3 sold, and several dozen since then. All from a Buy Now Button on a landing page.

shazow
I worry about the scenario of building something that people are unwilling to pay for. Also the service can get rather resource-intensive so I can't afford many free users.
pkenjora
Just use PayPal, especially if you bootstrap.

Set up a recurring payments button and drop the HTML into a page. The IPN does the rest. Its simpler than you think:

http://blog.awarelabs.com/2008/paypal-ipn-python-code/

If within your first month of operation you have customers changing subscription plans then worry about how to deal with it.

Don't solve problems you dont have yet. If you don't have customers yet you've got more pressing concerns.

Having gone through this recently, Im hoping to save you pain.

shazow
I agree, that's what I ended up doing yesterday.
lefrancaiz
I think you're taking bootstrapping to an extreme.

You should have at least a little bit of cash to burn (let's say $100 per month) until you get enough users to cover your costs.

techsupporter
Intuit's GoPayment[1] service is a real merchant account and they take unincorporated sole proprietors. The basic service is free (it's positioned as a competitor to Square) and there's even "an app for that" on iPhone and Android. Their user interface leaves a little to be desired, but it is functional and there's a place for recurring payments to be handled (as long as you have authorization from the cardholder, of course).

My relationship with GoPayment: The co-op I help run uses them as an alternative to Square because GoPayment actually accepts EINs for incorporated entities. I'm just a satisfied customer.

1- http://gopayment.com/