We’re looking at chargify.com, spreedly.com, and cheddargetter.com to manage subscriptions for a SaaS web app we’re developing at pybrew.com. I made some graphs to see how their prices scale with the number of customers they’re managing for your business.
Spreedly charges per transaction, whereas chargify and cheddargetter charge per customer. For these graphs, I’m assuming that it’s simply one transaction per customer per month, but spreedly’s curve will go up or down if you charge more or less frequently than monthly. Also, I didn’t include any costs from payment gateways like authorize.net.
In a few places, these graphs make it look like there are some big price differences. However, after looking at it for a while, I’m not sure that the differences are significant. The most noticeable one is where the chargify price jumps when you get your 501st customer. At that point, you’d be paying $249/month for chargify but only $119.20 for spreedly or only $39.00 for cheddargetter. But, if you’re charging, say, $15/month for your app, and you have 501 customers, then you’re getting $7,515/month in revenue, and the difference of $210 between chargify and cheddargetter is about 2.8% of your revenue, which is the biggest difference in percentage of revenue that I can find in the first 20,000 customers. Once you get past 1,150 customers, spreedly is always the most expensive, but the difference is generally around 1% of revenue, assuming a $15/customer/month subscription model.
There’s another change at 50,000 customers, which is where the cheddargetter cost begins increasing again, so eventually it will cross the chargify curve, which is fixed at $2,499 for unlimited customers. However, I stopped the graphs at 20,000 customers, because I figure, at that point, with a $15/month subscription, you’re bringing in $300,000 per month, so you can afford to do pretty much whatever you want.
For a startup, getting to the point of having 50 paying customers is the hardest and probably takes the most time, and with chargify, those first 50 are free, but overall, I’m not convinced that the price differences alone are enough to make a decision between the three. You might want to choose based on some combination of price and features. As primarily Python coders, we like that Spreedly already has a Django app, thanks to Chris Drackett.
Here’s the quick-and-dirty Python script I wrote to generate the numbers. (Please let me know if you catch a mistake!)
#!/usr/bin/env python
def spreedly(transactions):
return 19 + .20*transactions
def cheddargetter(customers):
def _basic(customers):
cost = 39.00
if customers > 1000:
cost += .19*(customers-1000)
return cost
def _advanced(customers):
cost = 169.00
if customers > 10000:
cost += .06*(customers-10000)
return cost
def _premium(customers):
cost = 549.00
if customers > 50000:
cost += .02*(customers-50000)
return cost
if customers <= 20:
return 0.00
else:
return min(_basic(customers), _advanced(customers), _premium(customers))
def chargify(customers):
if customers > 15000:
return 2499.
if customers > 10000:
return 1499.
if customers > 5000:
return 749.
if customers > 500:
return 249.
if customers > 50:
return 49.
return 0.
if __name__ == '__main__':
max_customers = 20001
f = open('prices.txt','w')
print >>f, "# num_customers\tchargify\tspreedly\tcheddargetter\tspread\trevenue\tpercent_diff"
max_spread = 0.
max_percent_diff = 0.
for c in xrange(max_customers):
cha = chargify(c)
spr = spreedly(c)
che = cheddargetter(c)
spread = max(cha,spr,che) - min(cha,spr,che)
if spread > max_spread: max_spread = spread
revenue = c * 15.00
percent_diff = revenue > 0. and (100. * (spread/revenue)) or 0.
if c > 50 and percent_diff > max_percent_diff:
max_percent_diff = percent_diff
print >>f, "%d" % c,
print >>f, "\t%.02f" % chargify(c),
print >>f, "\t%.02f" % spreedly(c),
print >>f, "\t%.02f" % cheddargetter(c),
print >>f, "\t%.02f" % spread,
print >>f, "\t%.02f" % revenue,
print >>f, "\t%.02f" % percent_diff
f.close()
print "max spread (diff between cheapest and most expensive):", max_spread
print "max percent diff (spread/revenue):", max_percent_diff
Here’s the gnuplot script I wrote to make the graphs.
set key left
set grid
set xlabel 'number of customers'
set ylabel 'monthly prices ($)'
set terminal png
set xrange[0:50]
set output '00050.png'
plot 'prices.txt' using 1:2 title 'chargify', \
'prices.txt' using 1:3 title 'spreedly', \
'prices.txt' using 1:4 title 'cheddargetter'
set xrange[0:100]
set output '00100.png'
replot
set xrange[0:200]
set output '00200.png'
replot
set xrange[0:500]
set output '00500.png'
replot
set xrange[0:1000]
set output '01000.png'
replot
set xrange[0:5000]
set output '05000.png'
replot
set xrange[0:10000]
set output '10000.png'
replot
set xrange[0:15000]
set output '15000.png'
replot
set xrange[0:20000]
set output '20000.png'
replot
Update 2013-01-07: When I migrated from posterous.com to Octopress, I was unable to migrate the comments from the original post into Disqus, so I’m just copying them below so they don’t get lost.
Update 2018-02-08: The code has been on GitHub for some time now: https://github.com/ccg/billing-service-price-comparison
Spreedly supports a half dozen payment gateways. Paste in your PayPal Pro data and your subscriptions continue rebilling uninterrupted through there instead of through Authnet.
The other services don’t support multiple gateways right now, so if you lose your gateway all that stored billing information is unusable.
However, if you’re terminated for too many chargebacks then you’ve got other problems. You’re just going to get terminated again. At that point, consider getting into a different business.
Making a decision on a subscription billing solution should be based on two main items:
1.) the features- i.e. does this fit my application’s current needs, and is the system flexible enough to allow me to change it in response to changing customer/business needs.
2.) Price- does this fit my cost structure today, tomorrow and where I project my business to grow to
As DJC and Marc discuss, what payment provider are you using currently? Chargify limits you to authorize as does Cheddargetter. Spreedly supports multiple gateways but isn’t PCI compliant. Are those items limiting factors and is that risk an issue for you? These are questions to ask.
Pricing is also key- the way you handle your customers and users (and how they grow) has a huge impact on what you get charged (as these graphics show). Recurly charges on a percentage transacted basis- so we only get paid as you get paid. We’re also one of the only solutions that has a maximum cap on what that fee will be- so you won’t be penalized for being successful.
We’re happy to answer these questions for you as they come up and in the end, the competition between us and these other solutions will only help developers. We’re standing by to help :)
As for a Python library, one of our beta customers was kind enough to release what they have worked on so far at http://github.com/getyouridx/pychargify
We’re building our team & technology to answer the needs of beta customers. The feedback is great and is helping us prioritize.
Our development pipeline is full of good stuff and we’re always happy to hear what’s important to you. It’s still very early!
Now you need to find out if the tokenization systems at the gateways these services work with do either of two critical items.
1. Will the gateway transfer the card data you acquired to you or another service provider that is PCI compliant?
2. Does the gateway implement card updater or any other sorts of retention systems on the cards it has tokenized for you? Loosing customers to passive opt out really hurts.
Please don’t lose the ability to bill your early adopters…
-Gene (CEO, Vindicia)
I think it’s worth noting that so far, the companies mentioned have all been friendly and responsive, which makes it ever harder to know which way to go. For example, a couple weeks ago, I casually asked on Twitter if any Django developers had chosen one of those services, and I got replies straight from Spreedly and Chargify within minutes.
With Recurly’s pricing based solely on what’s transacted through our service, we’re only paid if you get paid. If you’re using a Freemium model, there’s no cost for your free users and we offer a seamless way to let them upgrade into a premium billing level. Just another reason to consider Recurly.
We look forward to seeing how this discussion continues :) Thanks again for the forum.
IMHO: The only way to keep costs low for the nth client is to roll your own.
A service like the ones you mention above are on top of what you need to roll your own. Remember, YOU still have to get a merchant account. You still are going to be charged transaction fees and then their fees on top of it (in the case of chargify, anyways, but i’m sure it’s similar to all of the ones you’ve tested).
How do these services compare for odd little things that happen in real life situations?
For instance, Paypal will create a recurring subscription and pass a Success message back to you, however, when they actually go to try and bill the client, it won’t go through. so now you have to go back to the client and ask them to sign up again to remedy the situation.
Plus chargify, at least, uses a US based system that only US clients can use, which means chargify would be US based only.
Merchants need to be very careful when storing their customers credit card data with a payment gateway provider because most will hold it hostage if they ever want to move. It’s a huge gotcha with big implications.
To address this problem, we recently created the Credit Card Data Portability Standard. You can read more about it here: http://www.braintreepaymentsolutions.com/blog/data-portability
Bryan Johnson
Braintree
The key point for compliance with PCI DSS is how the entire organization approaches the issue. Will the billing system just provide a linkage to a payment gateway that tokenizes customer credit cards? Or will the solution provide multiple ways for each department to easily access the information according to their roles?
Also, what happens when the payment data is initially submitted by customers? Vindicia recently introduced Hosted Order Automation to allow companies to fully offload the PCI burden while still offering an enterprise-class billing system with integrated payment gateway.
More information can be found here - http://bit.ly/eliminatePCI
A few updates on CheddarGetter, however. They’re switching to a new pricing system which is focused on making recurring billing affordable for startups. Their smallest plan costs $19/month and $0.25/transaction, and covers up to $3K monthly revenue. The next plan up costs $79/month and $0.20/transaction, but you are allowed an unlimited monthly revenue. For both of these plans, you can have unlimited customers and unlimited transactions. That makes CheddarGetter very doable for small businesses, and much cheaper than other plans for large clients. If you do think that you will have many customers, they also have an Enterprise plan, rates for which are available by contacting their friendly support team.
The best part about these new plans is that it’s not just about money - CheddarGetter also rolled out some new features that make recurring billing much easier to undertake, such as PayPal integration (if you want it), a quick setup wizard, hosted payment pages, and more. Check out the post on their blog here: http://blog.cheddargetter.com/post/4211900640/new-pricing-plans.
Also, just to settle a few matters, CheddarGetter does work with many third-party payment gateways (authorize.net, PayPal, etc). At the same time, they offer their own gateway (called CheddarGateway), which continues to streamline the process of setting up your online billing.
I highly suggest them!
May I ask if anyone has had any success with incorporating any of the above into a Shopify type offering… this seems to be the one downfall.
Thanks again for the post and all of the comments! Very helpful!
Would *love* to see some updated graphs with their current pricing plans. And maybe throwing in Recurly as well.
Billing Savvy : http://www.billingsavvy.com/