4 ms·

I don't like outsourcing subscription logic at all. It's not difficult to do yourself, yet expensive to outsource. It also ties you very tightly to a company wh

I don't like outsourcing subscription logic at all. It's not difficult to do yourself, yet expensive to outsource. It also ties you very tightly to a company which can raise prices on you at any time (as Recurly has in the past, without grandfathering). The switching cost when that happens is huge. I store customer billing info at SpreedlyCore, which also provides a provider-agnostic API for making charges/refunds against the stored credit cards. Right now my processors of choice are PayPal Pro and an "interchange-plus"-priced merchant account with Authorize.net as the gateway. With SpreedlyCore, I can change payment providers overnight (to Stripe or Dwolla or whoever becomes flavor-of-the-month) without changing any code or having customers re-enter payment details. There's also no vendor lock-in to SC -- they'll hand off the stored billing info to you if you want to leave. I'm also in the US, and most of my customer base is also international.

jdlshore 14y ago
Thanks for the suggestion. Actually, from my brief glance, the combination of Spreedly + SpreedlyCore seems like it might be a good fit. It looks like I could use Spreedly to get up and running quickly, then migrate to SpreedlyCore when I want to reduce costs or have more control over subscriptions.
dmgrow 14y ago
Recurly did grandfather their early customers (we were one). For the most part, I'm a fan of Recurly and it helped improve our renewal rates. However, the major outage they experienced earlier this year (including substantial data loss) was a real blow. Yes, it's possible to build. But if building is delaying you from doing it immediately, then buy -- it's worth it.
- jdlshore 14y ago
  How did Recurly help your renewal rates? Are they doing something different/more than others?
  - dmgrow 14y ago
    I think their feature set is probably fairly similar to others. Through some testing of dunning settings and email notifications, we were able to significantly increase the percentage of customers who updated failed credit cards. More than anything, it was fairly easy to integrate and roll out. We are busy building our core software and it would have taken us a long time to get to the point where we would have prioritized building our own. I'm glad we didn't wait longer than we did because it has been worth the time and money spent on Recurly.
- dangrossman 14y ago
  I was a Recurly beta user. 2010 I think. Just after I finished integrating them and pushing it live on a 50k user site, they upped the pricing (and changed pricing models entirely) with no grandfathering. There was some big hooplah on their blog over that which led to some kind of special offer for existing users, but it still wasn't the same as when we signed up. You were probably in during a later price change. I wasn't cool with having the company I was about to entrust my income -- putting food on my table -- changing the rules on a whim like that, so I had to roll everything back and do billing myself. I'll never trust 'em again.
  - skrish 14y ago
    Genuine question, as I want to learn from this (as I run similar service). If you were to launch one such critical service, what would you do differently to assure your customers that you really care & won't screw them behind their back? Definitive answer is: first of all don't screw your customers. But how do you make sure you convey, you won't?
drstewart 14y ago
>I don't like outsourcing subscription logic at all. It's not difficult to do yourself, yet expensive to outsource I disagree, and I say this as someone who just finished writing a recurring billing engine. If your needs are simple (basic plans that vary in price but not necessarily in length) and you don't have much need for being able to precisely control things like add-ons, discounts, etc, then going with something like Stripe, Recurly, or Braintree is the best option. If you need custom logic, which we did, definitely roll your own. But it's a lot trickier to do than you'd expect. I'll give you an example of a case we need to support: handling a case where a user purchases a monthly subscription, upgrades to a yearly subscription of a different plan, but mid-way through decides they don't like it (during the trial period) and want to rollback to the monthly subscription. Writing generic logic to handle refunds, billing dates, etc is tricky, but doable. In my mind there's no need to go through the pain of writing the whole thing yourself if the use case is simple and you don't need complex logic.

jdlshore 14y ago

Thanks for the suggestion. Actually, from my brief glance, the combination of Spreedly + SpreedlyCore seems like it might be a good fit. It looks like I could use Spreedly to get up and running quickly, then migrate to SpreedlyCore when I want to reduce costs or have more control over subscriptions.

dmgrow 14y ago

Recurly did grandfather their early customers (we were one). For the most part, I'm a fan of Recurly and it helped improve our renewal rates. However, the major outage they experienced earlier this year (including substantial data loss) was a real blow. Yes, it's possible to build. But if building is delaying you from doing it immediately, then buy -- it's worth it.

jdlshore 14y ago
How did Recurly help your renewal rates? Are they doing something different/more than others?
- dmgrow 14y ago
  I think their feature set is probably fairly similar to others. Through some testing of dunning settings and email notifications, we were able to significantly increase the percentage of customers who updated failed credit cards. More than anything, it was fairly easy to integrate and roll out. We are busy building our core software and it would have taken us a long time to get to the point where we would have prioritized building our own. I'm glad we didn't wait longer than we did because it has been worth the time and money spent on Recurly.
dangrossman 14y ago
I was a Recurly beta user. 2010 I think. Just after I finished integrating them and pushing it live on a 50k user site, they upped the pricing (and changed pricing models entirely) with no grandfathering. There was some big hooplah on their blog over that which led to some kind of special offer for existing users, but it still wasn't the same as when we signed up. You were probably in during a later price change. I wasn't cool with having the company I was about to entrust my income -- putting food on my table -- changing the rules on a whim like that, so I had to roll everything back and do billing myself. I'll never trust 'em again.
- skrish 14y ago
  Genuine question, as I want to learn from this (as I run similar service). If you were to launch one such critical service, what would you do differently to assure your customers that you really care & won't screw them behind their back? Definitive answer is: first of all don't screw your customers. But how do you make sure you convey, you won't?

drstewart 14y ago

>I don't like outsourcing subscription logic at all. It's not difficult to do yourself, yet expensive to outsource I disagree, and I say this as someone who just finished writing a recurring billing engine. If your needs are simple (basic plans that vary in price but not necessarily in length) and you don't have much need for being able to precisely control things like add-ons, discounts, etc, then going with something like Stripe, Recurly, or Braintree is the best option. If you need custom logic, which we did, definitely roll your own. But it's a lot trickier to do than you'd expect. I'll give you an example of a case we need to support: handling a case where a user purchases a monthly subscription, upgrades to a yearly subscription of a different plan, but mid-way through decides they don't like it (during the trial period) and want to rollback to the monthly subscription. Writing generic logic to handle refunds, billing dates, etc is tricky, but doable. In my mind there's no need to go through the pain of writing the whole thing yourself if the use case is simple and you don't need complex logic.