Poll: How do you bill recurring payments?
91–96 of 96 posts
Re: Poll: How do you bill recurring payments?
#921. 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.
Re: Poll: How do you bill recurring payments?
#93Question: 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?
Re: Poll: How do you bill recurring payments?
#94Re: Poll: How do you bill recurring payments?
#95We'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.qupl…
Adyen (www.adyen.com) is based in Amsterdam, did you check them? Anyone has any experience with them?
Re: Poll: How do you bill recurring payments?
#96We 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.
> 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...
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.