3 ms·

In my opinion, no one should be using recurring billing for any provider. If you do, you've basically tied yourselves to them--if you ever decide to move, you

In my opinion, no one should be using recurring billing for any provider. If you do, you've basically tied yourselves to them--if you ever decide to move, you need to somehow get the subscription details for every customer migrated into your app! Instead, view your payment processor as just another PaymentProcessor enum. Own the recurring subscriptions yourself, or be willing to pay for someone to do it for you.

paxys 6y ago
That is easier said than done. Managing recurring billing is a significant engineering problem, and getting tied in with a provider and paying a surcharge is still worth it over maintaining an entire in-house dev team to do it.
- raiyu 6y ago
  I guess now it's as simple as checking whether cost of a dev team to do recurring billing is < 0.5%
- candiddevmike 6y ago
  In my experience, it should be no more difficult than sending recurring emails. You should have all the data (PaymentProcessorCustomerID, LastBillingDate, etc), run it like you would a email with a retry queue.
  - abfan1127 6y ago
    its more than that. The "What ifs" get out of control pretty quickly. Prorating, canceling, expired/canceled cards, tend to create a ton of end cases. For instance, a person pays for Feb 15 to Mar 14, the card expires March 1, then the person requests a cancellation Mar 7 and wants a refund. Its not impossible, it just takes a lot of time and effort to weasel out all of these end cases.
    - candiddevmike 6y ago
      In the example you gave, how would stripe billing solve that? This seems like you'd need some kind of manual interaction regardless? For all the end cases, you manually handle them until they happen with enough frequency to require automation. A simple recurring billing system is absolutely fine for most businesses, and as you scale you can add more bells and whistles to it.
      - abfan1127 6y ago
        I think you're right in this case. I haven't looked at the problem in about 10-15 years (before Stripe had recurring). I remember there being a ton of end cases I had to deal with. We ended up going with Recurly due to it.
- abfan1127 6y ago
  > Managing recurring billing is a significant engineering problem This is a huge understatement! Its very painful. It sounds easy, but there are so many end cases with the calendar alone! Let along discounts, prorating, cancelations, etc. It sucks to become dependent on providers for this service, but it also sucks to have crappy recurring billing.
- mytailorisrich 6y ago
  > Managing recurring billing is a significant engineering problem It's not. Sure it's a problem and it requires thought and engineering skills. But overall it is not one of the complicated problems and quite standard work for an engineer. Sometimes I feel that people have become so used to have a third party API for everything so that they are scared of doing actual engineering work... ;) That said, of course weighing the cost of dev and maintenance in-house versus paying a surcharge is a very valid consideration. At the same time one should not underestimate the risk/cost of getting tied to a provider for anything critical (and payments are obviously critical).
  - porker 6y ago
    > It's not. Sure it's a problem and it requires thought and engineering skills. But overall it is not one of the complicated problems and quite standard work for an engineer. If you reduce it to "Charge them again after X period" then sure. If you want to comply with worldwide payment laws and tax requirements, then I'd disagree it's "not one of the complicated problems". Edit: And dunning. And pro-rata'd subscription changes. And pro-rata'd refunds. We pay Paddle 5% of every subscription transaction for a reason.
    - mytailorisrich 6y ago
      I'm not reducing, this is what recurring billing is. The relevant issues include cancellations, pro-rata refunds, card expiry, calendar calculations (always fun), etc. These are not rocket science. Handling of tax has to happen on any payment and is not an issue specific to recurring billing/payments. It obviously brings in its own set of issues, the biggest of which is the multiplication of requirements if you want to comply with the rules of many countries, as you point out.
    - Silhouette 6y ago
      If you want to comply with worldwide payment laws and tax requirements, then I'd disagree it's "not one of the complicated problems". It's also not something that a service like Stripe will handle for you to a useful degree. Edit: And dunning. Which, AFAIK, you still can't actually test properly with Stripe's system before making it live. I'm not even sure it's fully documented yet, and if it is, that's a relatively recent development. And pro-rata'd subscription changes. And pro-rata'd refunds. You can literally write the code to do things like this in a few minutes, including all conceivable edge cases. Many of us have. It's basic arithmetic combined with some almost-but-not-quite-trivial logic around dates. We pay Paddle 5% of every subscription transaction for a reason. But Paddle's model is a merchant-of-record, which also takes care of things like the tax reporting and remittance headaches that a service with Stripe's model doesn't. It's not a fair comparison.
nickjj 6y ago
I think this is good advice or at least seriously worth considering it. I remember DHH from Basecamp mentioning this once a few years ago. I forgot if I asked him on Twitter or if someone else did, but it came down to asking why Basecamp doesn't use Stripe's subscription API. He said it didn't exist at the time but he also said it wasn't a ton of work to get it all working using the basic single charge API. Details are spotty since it was a random tweet from a while ago but the overall feeling of it was it's very doable. I feel like the topic came up in one of those YouTube videos where DHH walked through real life code in Basecamp. Even today it might be worth it. I mean if you try to integrate an abstraction on top let's say Stripe and Braintree, there's quite a lot of differences between the 2 for subscriptions. How much more work would it be to write your own subscription logic once and use it anywhere vs writing a really good abstraction.
- lomoeffect 6y ago
  There's a few startups in this space: see Spreedly, Optile etc. In my experience large enterprises are heading in this direction and managing that abstraction is not something which they want to do themselves (particularly with evolving local regulation/APMs/3DS2.x in Europe).

paxys 6y ago

That is easier said than done. Managing recurring billing is a significant engineering problem, and getting tied in with a provider and paying a surcharge is still worth it over maintaining an entire in-house dev team to do it.

raiyu 6y ago
I guess now it's as simple as checking whether cost of a dev team to do recurring billing is < 0.5%
candiddevmike 6y ago
In my experience, it should be no more difficult than sending recurring emails. You should have all the data (PaymentProcessorCustomerID, LastBillingDate, etc), run it like you would a email with a retry queue.
- abfan1127 6y ago
  its more than that. The "What ifs" get out of control pretty quickly. Prorating, canceling, expired/canceled cards, tend to create a ton of end cases. For instance, a person pays for Feb 15 to Mar 14, the card expires March 1, then the person requests a cancellation Mar 7 and wants a refund. Its not impossible, it just takes a lot of time and effort to weasel out all of these end cases.
  - candiddevmike 6y ago
    In the example you gave, how would stripe billing solve that? This seems like you'd need some kind of manual interaction regardless? For all the end cases, you manually handle them until they happen with enough frequency to require automation. A simple recurring billing system is absolutely fine for most businesses, and as you scale you can add more bells and whistles to it.
    - abfan1127 6y ago
      I think you're right in this case. I haven't looked at the problem in about 10-15 years (before Stripe had recurring). I remember there being a ton of end cases I had to deal with. We ended up going with Recurly due to it.
abfan1127 6y ago
> Managing recurring billing is a significant engineering problem This is a huge understatement! Its very painful. It sounds easy, but there are so many end cases with the calendar alone! Let along discounts, prorating, cancelations, etc. It sucks to become dependent on providers for this service, but it also sucks to have crappy recurring billing.
mytailorisrich 6y ago
> Managing recurring billing is a significant engineering problem It's not. Sure it's a problem and it requires thought and engineering skills. But overall it is not one of the complicated problems and quite standard work for an engineer. Sometimes I feel that people have become so used to have a third party API for everything so that they are scared of doing actual engineering work... ;) That said, of course weighing the cost of dev and maintenance in-house versus paying a surcharge is a very valid consideration. At the same time one should not underestimate the risk/cost of getting tied to a provider for anything critical (and payments are obviously critical).
- porker 6y ago
  > It's not. Sure it's a problem and it requires thought and engineering skills. But overall it is not one of the complicated problems and quite standard work for an engineer. If you reduce it to "Charge them again after X period" then sure. If you want to comply with worldwide payment laws and tax requirements, then I'd disagree it's "not one of the complicated problems". Edit: And dunning. And pro-rata'd subscription changes. And pro-rata'd refunds. We pay Paddle 5% of every subscription transaction for a reason.
  - mytailorisrich 6y ago
    I'm not reducing, this is what recurring billing is. The relevant issues include cancellations, pro-rata refunds, card expiry, calendar calculations (always fun), etc. These are not rocket science. Handling of tax has to happen on any payment and is not an issue specific to recurring billing/payments. It obviously brings in its own set of issues, the biggest of which is the multiplication of requirements if you want to comply with the rules of many countries, as you point out.
  - Silhouette 6y ago
    If you want to comply with worldwide payment laws and tax requirements, then I'd disagree it's "not one of the complicated problems". It's also not something that a service like Stripe will handle for you to a useful degree. Edit: And dunning. Which, AFAIK, you still can't actually test properly with Stripe's system before making it live. I'm not even sure it's fully documented yet, and if it is, that's a relatively recent development. And pro-rata'd subscription changes. And pro-rata'd refunds. You can literally write the code to do things like this in a few minutes, including all conceivable edge cases. Many of us have. It's basic arithmetic combined with some almost-but-not-quite-trivial logic around dates. We pay Paddle 5% of every subscription transaction for a reason. But Paddle's model is a merchant-of-record, which also takes care of things like the tax reporting and remittance headaches that a service with Stripe's model doesn't. It's not a fair comparison.

nickjj 6y ago

I think this is good advice or at least seriously worth considering it. I remember DHH from Basecamp mentioning this once a few years ago. I forgot if I asked him on Twitter or if someone else did, but it came down to asking why Basecamp doesn't use Stripe's subscription API. He said it didn't exist at the time but he also said it wasn't a ton of work to get it all working using the basic single charge API. Details are spotty since it was a random tweet from a while ago but the overall feeling of it was it's very doable. I feel like the topic came up in one of those YouTube videos where DHH walked through real life code in Basecamp. Even today it might be worth it. I mean if you try to integrate an abstraction on top let's say Stripe and Braintree, there's quite a lot of differences between the 2 for subscriptions. How much more work would it be to write your own subscription logic once and use it anywhere vs writing a really good abstraction.

lomoeffect 6y ago
There's a few startups in this space: see Spreedly, Optile etc. In my experience large enterprises are heading in this direction and managing that abstraction is not something which they want to do themselves (particularly with evolving local regulation/APMs/3DS2.x in Europe).