Poll: How do you bill recurring payments?
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.
Please feel free to explain your choice in the comments.
"How does Spreedly pay me?
Spreedly never touches your customers' money - it goes straight into your merchant account."
If you have your own merchant account you can use paypal for just the gateway, but I don't think this happens very often.
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.
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.
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.
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.
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.
"Unfortunately your transaction volume was too low to be approved for a merchant account at this time. "
Alternatively, you could do this, but charge your early customers via a simple Paypal recurring invoice until you're ready to turn on chargify.
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.
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.
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.
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.
Thanks for your blog post!
$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
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.
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?
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.
Sorry Bryan.
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
I talk more about it here: http://peachshake.com/2010/06/15/saas-subscription-billing-o...
* 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.
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.
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'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.
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...
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.
Store their card data in Authorizenet CIM and run a nightly cron job to make the charges you need. You can charge whatever amount you need and never have to ask for payment info twice.
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.
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.
I've had a real problem finding a recurring billing company that allows payments to be split like this. Any suggestions?
- Authorize.net + CIM + ActiveMerchant
- Authorize.net + Reoccurring Billing
- Authorize.net + Freshbooks
John.
I think if I did it over, for the time-based recurring payments I would use chargify or one of the others mentioned in this thread.
Our European startup is using Adyen, a Dutch company.
I also use Amazon Payments for a subscription service I have.
- None of the major Indian gateways support recurring billing.
1. Rolling your own with a gateway like Paypal or Authorize.Net is often the easiest entry point (for US based startups at least), provided your requirements are not too complex. Especially if you are just getting started with an uncertain revenue prediction, there's little justification in trying to take on more sophistication. Do what's easiest for you - sling code or outsource to a SaaS billing provider. Unfortunately, the underwriting process is controlled by the credit card companies and tends to be cumbersome. No shortcuts there.
2. Once you've got a customer base, then you get the feel for the issues. Some examples: Mid-month upgrades/downgrades, chargebacks (customers disputing the charge directly with their credit card issuer), orders expiring, corporate customers wanting to pay by paper check, adding 1 time service charges to monthly bill, house credits or refunds, early termination fees, etc. Then you start thinking stuff like, gee, if I could notify my annual customers in advance I'd reduce a good deal of chargebacks and automate a lot of renewals...and so on... At this point you definitely want to consider either a SaaS billing solution or buying a platform and running it in-house (ya, we do both). And, now that you've got some volume, you'd want to switch CC processors for better rates. Let's hope you can get YOUR data back...
3. If your growth has continued past the above stage, then you want to be able to customize. Typical examples we see: commission and affiliate payouts, master billing (one consolidated corporate bill, a la your corporate telco+internet bill), custom payment retry logic (eg. ACH when paychecks are most likely to hit the bank), customer segmentation tactics (e.g. coupon codes for VIP customers to entice renewals), advanced billing models (eg. peak concurrent usage, or annual averaged billing), blacklisting bad cards, etc. The founders of BluSynergy spent two decades doing this kinda stuff for the big guys. Our specialty is that we designed the system from the ground-up to easily implement this level of customization (often less than a week) while still running in a cost-efficient multi-tenant model. And it's not just for the big guys anymore :)
Now see if any of this applies to your revenue strategy. For many, #1 above is still the best bet if your requirements are simple. There will be a migration effort when you get to stage 2, but at that point it's a "good problem" to tackle.
more rambling thoughts: http://blusynergy.com/features/compare-alternatives
We love to work the challenging cases, give us a call. We are especially eager to work with companies contemplating mobile/"in-app" purchases.