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.")
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.
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.
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.
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.
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.
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.
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-...
I recommend trying PayLeap (http://www.payleap.com) They're both a gateway and Credit Card processor. They're also
very developer friendly, have the best rates around and have FREE recurring billing. We just switched after meeting them at a developer conference and are very happy with them. Here are their base rates:
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.
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!
I'm planning to use Paypal Adaptive Payments for a site I'm building. Can anyone save me?
I'm building a Ruby site and will charge my users automatically on a monthly basis, based on their usage, so their charge varies. They agree to a billing agreement when they sign up, and their charges will vary mostly between $0.25 and $5.00.
I need a payment service that:
(1) enables me to automatically charge my users varying amounts (without them approving each time),
(2) has a decent micropayment fee structure ($0.05 + 5% for less than $10),
(3) allows my users to pay with any credit/debit card without requiring a proprietary login (e.g. Amazon), and
(4) can store my users' billing info so I don't have to be PCI compliant - I just do an API call to charge them.
The only service I've found meeting my needs is Paypal's Adaptive Payments API. I've had some bad experiences in the past with Paypal and I'm wary based on others' feedback (e.g. "Paypal is the Anti-Christ"), but I don't see any other option.
These results are very biased by the early-adopters that frequent hackernews.
There are WAY more people out there are using the recurring functionality of the gateways (ex. Auth.net, Braintree, Linkpoint / First Data Global Gateway) than one of the standalone recurring billing systems (recurly, chargify, etc).
However using those legacy solutions is a SHAME because they are in general quite horrible. They are certainly cheaper, and may seem like the path of least resistance, but they don't do the job well enough for serious companies.
You want something like Recurly, Chargify, Zuora, CheddarGetter, if you are doing either recurring or metered charging of your customers. It will make your life easier and is worth the expense.
Clarification -- as a gateway providers like Braintree, Linkpoint/FDGG, Auth.net, etc are perfectly fine, but their recurring functionality is not robust enough for most subscription or metered businesses. I must have written this before my coffee or something.
[full disclosure - I am a co-founder of Recurly] I'll do my best to be objective and help frame an inclusive approach to the answer.
First - you need to decide what kind of billing mechanics your business needs. (simple X$/mo or advanced- multiple plans, upgrades downgrades, add-ons, coupons, dunning, multi-currency support etc) - this is typically the first step in the build vs. buy eval.
Secondly - you need to evaluate your own available time/resources. Most eng. projects require 2x original estimate...you can easily apply 5-10X for billing since even the most talented developers don't get it 'right' the first time (add PCI and ongoing customer support + gateway recourse to your total estimates). The best developers can usually 'get it working' - but then realize they end up spending tremendous time to 'get it working well'.
Third - [Assume now you're buying vs. building] You need to choose a service that gives your business room/flexibility to grow. Many businesses decide to change gateways at some point - when new business needs emerge - [multi-currency support, better rates, customer support]. Don't hem yourself in by choosing a service that doesn't store your card data, and let you easily switch gateways. Numerous horror stories exist on this topic - won't cover here. Also important, don't choose ANY service that won't commit to returning your customer credit card data if/when you decide to leave them. [Braintree was a leader in this area, and Recurly fully supports the Data Portability Standard as well].
Compare core feature capabilities AND 'high frequency use' capabilities of available recurring providers. Core features might be: add-on support, upgrade downgrade + proration, customizable emails, API documentation + API behaviors, Push notifications for sync to your systems, free trials, coupons etc.
'High frequency use' aspects include reporting, data exports, third party integrations, account dashboard + common customer support functions (can you easily credit, refund, charge, modify info, upgrade/downgrade) from any customer account page. This is a critical aspect and most evaluations fail to consider what it will be like to actually 'live with' a vendor's solution.
Lastly, the payment processor options + combinations.
Merchant Bank Accts - (We really like FeeFighters.com for helping entrepreneurs to choose a merchant bank).
Payment Gateways - Your payment gateway decision should be made not just on fees alone, but also consider the kinds of error fidelity you will receive (How many error/decline messages and what type of info is returned). Another important consideration is multi-currency support. Does your business need to accept many different kinds of currencies from around the world? (Dramatically improves conversions if you don't force your customers to pay in $USD). PayPal does a better job with currency conversion than just about any other gateway (For US companies). Some gateways will require you to be incorporated in each country you would like to accept currencies from..
Most importantly, talk to customers from your prospective recurring billing provider. The 'Net promoter score' opinions are very palpable across vendors. Don't just take the 'reference' customers provided by the vendors, but do your homework and you'll find quickly where the raving fans are.
Hopefully this was helpful, balanced, fair and objective.
Switched from Amazon FPS to Amazon SimplePay to Chargify. Although very pricey, Chargify is much, much nicer. I really cringe when I see the bill, but I cringe more when I think about how much things sucked before we made the switch.
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.
Authorize.net's CIM to store the payment data, and a nightly cron job to charge whoever's monthly subscription fee is due. It's not that hard, everyone managed before these subscription-as-a-service companies popped up in the past few years.
We use PayPal. The solution we found was to cancel the subscription and create a new one. Sure this isn't atomic but we haven't had anyone drop mid flow yet.
It looks and feels atomic to the user.
PayPal could go a long way to document their API better. The number of customers with PayPal accounts is large enough that we're willing to deal, especially since setup is a one time cost.
PayPal does not support monthly recurring billing between Germany and United States. Thats no good.
I think someone can displace PayPal but not enough payers are comfortable using services other than PayPal, especially on a startup site.
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.
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.
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.
[+] [-] patio11|15 years ago|reply
[+] [-] jordanvisco|15 years ago|reply
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.
[+] [-] ollysb|15 years ago|reply
[+] [-] rlm|15 years ago|reply
[+] [-] bradleyjoyce|15 years ago|reply
[+] [-] garrettdimon|15 years ago|reply
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|15 years ago|reply
[+] [-] shazow|15 years ago|reply
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.
[+] [-] pkenjora|15 years ago|reply
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.
[+] [-] techsupporter|15 years ago|reply
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/
[+] [-] lefrancaiz|15 years ago|reply
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.
[+] [-] bradleyjoyce|15 years ago|reply
Alternatively, you could do this, but charge your early customers via a simple Paypal recurring invoice until you're ready to turn on chargify.
[+] [-] marketer|15 years ago|reply
[+] [-] primigenus|15 years ago|reply
[+] [-] thibaut_barrere|15 years ago|reply
Thanks for your blog post!
[+] [-] ag|15 years ago|reply
[+] [-] asnyder|15 years ago|reply
$29 Monthly Processing Fee
Transaction Fee: $0.25
Credit Card Rate: 2.15%
No Annual Fee
No Monthly Minimum Fee
No Monthly Gateway Fee
Free Reporting and API
Free Recurring Billing
[+] [-] tzs|15 years ago|reply
[+] [-] steveklabnik|15 years ago|reply
[+] [-] jpallen|15 years ago|reply
[+] [-] marquis|15 years ago|reply
[+] [-] tashmahalic|15 years ago|reply
I'm building a Ruby site and will charge my users automatically on a monthly basis, based on their usage, so their charge varies. They agree to a billing agreement when they sign up, and their charges will vary mostly between $0.25 and $5.00.
I need a payment service that:
(1) enables me to automatically charge my users varying amounts (without them approving each time),
(2) has a decent micropayment fee structure ($0.05 + 5% for less than $10),
(3) allows my users to pay with any credit/debit card without requiring a proprietary login (e.g. Amazon), and
(4) can store my users' billing info so I don't have to be PCI compliant - I just do an API call to charge them.
The only service I've found meeting my needs is Paypal's Adaptive Payments API. I've had some bad experiences in the past with Paypal and I'm wary based on others' feedback (e.g. "Paypal is the Anti-Christ"), but I don't see any other option.
Does anyone know of a good alternative?
[+] [-] seanharper|15 years ago|reply
There are WAY more people out there are using the recurring functionality of the gateways (ex. Auth.net, Braintree, Linkpoint / First Data Global Gateway) than one of the standalone recurring billing systems (recurly, chargify, etc).
However using those legacy solutions is a SHAME because they are in general quite horrible. They are certainly cheaper, and may seem like the path of least resistance, but they don't do the job well enough for serious companies.
You want something like Recurly, Chargify, Zuora, CheddarGetter, if you are doing either recurring or metered charging of your customers. It will make your life easier and is worth the expense.
[+] [-] seanharper|15 years ago|reply
Sorry Bryan.
[+] [-] danburkhart|15 years ago|reply
First - you need to decide what kind of billing mechanics your business needs. (simple X$/mo or advanced- multiple plans, upgrades downgrades, add-ons, coupons, dunning, multi-currency support etc) - this is typically the first step in the build vs. buy eval.
Secondly - you need to evaluate your own available time/resources. Most eng. projects require 2x original estimate...you can easily apply 5-10X for billing since even the most talented developers don't get it 'right' the first time (add PCI and ongoing customer support + gateway recourse to your total estimates). The best developers can usually 'get it working' - but then realize they end up spending tremendous time to 'get it working well'.
Third - [Assume now you're buying vs. building] You need to choose a service that gives your business room/flexibility to grow. Many businesses decide to change gateways at some point - when new business needs emerge - [multi-currency support, better rates, customer support]. Don't hem yourself in by choosing a service that doesn't store your card data, and let you easily switch gateways. Numerous horror stories exist on this topic - won't cover here. Also important, don't choose ANY service that won't commit to returning your customer credit card data if/when you decide to leave them. [Braintree was a leader in this area, and Recurly fully supports the Data Portability Standard as well].
Compare core feature capabilities AND 'high frequency use' capabilities of available recurring providers. Core features might be: add-on support, upgrade downgrade + proration, customizable emails, API documentation + API behaviors, Push notifications for sync to your systems, free trials, coupons etc. 'High frequency use' aspects include reporting, data exports, third party integrations, account dashboard + common customer support functions (can you easily credit, refund, charge, modify info, upgrade/downgrade) from any customer account page. This is a critical aspect and most evaluations fail to consider what it will be like to actually 'live with' a vendor's solution.
Lastly, the payment processor options + combinations. Merchant Bank Accts - (We really like FeeFighters.com for helping entrepreneurs to choose a merchant bank).
Payment Gateways - Your payment gateway decision should be made not just on fees alone, but also consider the kinds of error fidelity you will receive (How many error/decline messages and what type of info is returned). Another important consideration is multi-currency support. Does your business need to accept many different kinds of currencies from around the world? (Dramatically improves conversions if you don't force your customers to pay in $USD). PayPal does a better job with currency conversion than just about any other gateway (For US companies). Some gateways will require you to be incorporated in each country you would like to accept currencies from..
Most importantly, talk to customers from your prospective recurring billing provider. The 'Net promoter score' opinions are very palpable across vendors. Don't just take the 'reference' customers provided by the vendors, but do your homework and you'll find quickly where the raving fans are.
Hopefully this was helpful, balanced, fair and objective.
-Dan
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] MicahWedemeyer|15 years ago|reply
I talk more about it here: http://peachshake.com/2010/06/15/saas-subscription-billing-o...
[+] [-] SeanOC|15 years ago|reply
* 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.
[+] [-] dangrossman|15 years ago|reply
[+] [-] pkenjora|15 years ago|reply
It looks and feels atomic to the user.
PayPal could go a long way to document their API better. The number of customers with PayPal accounts is large enough that we're willing to deal, especially since setup is a one time cost.
PayPal does not support monthly recurring billing between Germany and United States. Thats no good.
I think someone can displace PayPal but not enough payers are comfortable using services other than PayPal, especially on a startup site.
Hope this helps someone.
[+] [-] lautis|15 years ago|reply
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.
[+] [-] lsc|15 years ago|reply
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.
[+] [-] andrewwebb|15 years ago|reply
[+] [-] jqueryin|15 years ago|reply
[+] [-] nopal|15 years ago|reply
[+] [-] cgbystrom|15 years ago|reply
[+] [-] JonLim|15 years ago|reply