4 ms·

Having written a billing system that relied on a third-party recurring billing solution (which I later ripped out), I would advocate rolling your own subscripti

Having written a billing system that relied on a third-party recurring billing solution (which I later ripped out), I would advocate rolling your own subscription system for anything but the simplest case. The article has some suggestions on how to keep it simple: 1. Charge everyone on the 1st of each month. 2. Keep refunds out of your system 3. Run the billing as a batch job based off of cron Once you've made those decisions, writing a subscription service really isn't very difficult. It's a lot easier than dealing with multiple API calls to modify a user's subscription, any one of which may fail. Plus you don't have to deal with polling the recurring billing service to find out a transaction's status nor the race conditions inherent in such a setup. Finally, when you want to get more complicated and deal with promotional periods, billing on different dates for different customers, etc., you will find that it's much easier to modify your own code to fit your business requirements than it is to retrofit your interface with a third-party (not to mention any possible data migration issues). This could be solved by an excellent recurring billing API, but most suck.

sunir 17y ago
As mentioned in the other post linked below, I'm the product manager for the FreshBooks API. We are extremely aware there are many problems with the recurring billing market right now, and we are currently committed to doing a better job serving it. We are committed painless billing for web apps too. If you can please forgive the shilling, I'm very interested in hearing what sucks about the recurring billing APIs on the market and specifically what sucks about ours (http://developers.freshbooks.com http://developers.freshbooks.com). I'm sure our competitors in the market would also be interested so we can all do a better job. This isn't so much about us, but letting you know that at least one vendor is here listening, and maybe others. Thanks for anything you can throw at me, good or bad. (And you can't hurt my feelings except by being quiet. I need to know.) NOTE I rewrote this comment to be less self-conscious.
- mrkurt 17y ago
  My information may be out-dated, but Freshbooks seemed like it wouldn't have been a good fit for subscription billing back when we were looking. Basically, it wasn't possible to create a signup form that resulted in a recurring invoice with credit card data attached. So you'd end up with janky situations where you're either invoicing people and waiting for them to pay, or charging them through another gateway, then hoping they enter payment information before the next cycle. There's also no callback mechanism from Freshbooks to an outside site, making it extremely difficult to keep track of expiring subscriptions/cancellations/etc. I would love, love, love for Freshbooks to also be a drop in subscription billing platform. It seems like most of the bits are there, but there's no guiding force trying to make sure it works well for that purpose.
  - sunir 17y ago
    Thanks for your help! Callbacks and credit cards are the top two problems with the existing API. At least callbacks are a problem with a clear solution (HTTP postback, aka webhooks). As for credit cards through the API, we debate about that one extensively. The concern we have is that ideally, our customers would prefer not to touch credit cards because of the liability of credit cart theft. That's why for now we take on the risk of managing credit cards by letting you punt the customer to our invoice page. What's preferable to you? 1. Never touching the credit card ever, but redirecting the customer to a good payment experience 2. Taking the credit card on your own sign up form and sending it through our API 3. Taking the credit card through a FreshBooks https iframe on your website Or any other solutions?
    - mrkurt 17y ago
      I'd prefer to have both #1 and #2, actually. #1 for quick implementation, #2 for later when it's worth controlling the signup flow more granularly.
      - sunir 17y ago
        Thanks. That's actually very helpful.
texel 17y ago
Just out of curiosity, which third-party system did you use originally?
- burnout1540 17y ago
  Payflow Pro (by PayPal) Recurring Billing. I'm sure there are much, much better APIs out there but most of my comments would apply to any of them. EDIT: tl;dr for my above comment: Third-party solutions are basically a replacement of a cron job that figures out when to bill someone and how much. It's easier to write that cron job than it is to keep your billing data synchronized across two systems.

sunir 17y ago

As mentioned in the other post linked below, I'm the product manager for the FreshBooks API. We are extremely aware there are many problems with the recurring billing market right now, and we are currently committed to doing a better job serving it. We are committed painless billing for web apps too. If you can please forgive the shilling, I'm very interested in hearing what sucks about the recurring billing APIs on the market and specifically what sucks about ours (http://developers.freshbooks.com http://developers.freshbooks.com). I'm sure our competitors in the market would also be interested so we can all do a better job. This isn't so much about us, but letting you know that at least one vendor is here listening, and maybe others. Thanks for anything you can throw at me, good or bad. (And you can't hurt my feelings except by being quiet. I need to know.) NOTE I rewrote this comment to be less self-conscious.

mrkurt 17y ago
My information may be out-dated, but Freshbooks seemed like it wouldn't have been a good fit for subscription billing back when we were looking. Basically, it wasn't possible to create a signup form that resulted in a recurring invoice with credit card data attached. So you'd end up with janky situations where you're either invoicing people and waiting for them to pay, or charging them through another gateway, then hoping they enter payment information before the next cycle. There's also no callback mechanism from Freshbooks to an outside site, making it extremely difficult to keep track of expiring subscriptions/cancellations/etc. I would love, love, love for Freshbooks to also be a drop in subscription billing platform. It seems like most of the bits are there, but there's no guiding force trying to make sure it works well for that purpose.
- sunir 17y ago
  Thanks for your help! Callbacks and credit cards are the top two problems with the existing API. At least callbacks are a problem with a clear solution (HTTP postback, aka webhooks). As for credit cards through the API, we debate about that one extensively. The concern we have is that ideally, our customers would prefer not to touch credit cards because of the liability of credit cart theft. That's why for now we take on the risk of managing credit cards by letting you punt the customer to our invoice page. What's preferable to you? 1. Never touching the credit card ever, but redirecting the customer to a good payment experience 2. Taking the credit card on your own sign up form and sending it through our API 3. Taking the credit card through a FreshBooks https iframe on your website Or any other solutions?
  - mrkurt 17y ago
    I'd prefer to have both #1 and #2, actually. #1 for quick implementation, #2 for later when it's worth controlling the signup flow more granularly.
    - sunir 17y ago
      Thanks. That's actually very helpful.

texel 17y ago

Just out of curiosity, which third-party system did you use originally?

burnout1540 17y ago
Payflow Pro (by PayPal) Recurring Billing. I'm sure there are much, much better APIs out there but most of my comments would apply to any of them. EDIT: tl;dr for my above comment: Third-party solutions are basically a replacement of a cron job that figures out when to bill someone and how much. It's easier to write that cron job than it is to keep your billing data synchronized across two systems.