5
12 Comments

How do you build your recurring billing?

Do you put a flag on a user object and then use some monthly callback to toggle that flag? Or are there other methods that you use?

on July 20, 2020
  1. 1

    For a small number of recurring clients, the lightest path is often Stripe Subscriptions with a simple webhook to trigger invoice emails — setup is a few hours but it's fully hands-off after. If you want to avoid Stripe complexity entirely, Wave and Zoho Invoice both have free recurring invoice features that handle scheduling and sending. For anyone who just needs the PDF side quickly without automation (billing monthly but collecting manually), InvoiceDesire generates invoices in-browser with no account so you can recreate the same invoice each cycle in under a minute.

  2. 5

    I basically just use Stripe without having any state or logic on my backend other than storing their Stripe customer ID.

    At some point, I'll add PayPal and then I'll have to build out infrastructure abstracting it, but for now I'm happy to hand it off!

    1. 1

      Sounds like a good use case for the strategy pattern. :)

  3. 2

    Hey there, I worked on several SAAS recurring payment implementations.

    My recommendation is to use a 3rd party (eg stripe, braintree) which is supporting recurring payments / billing. You will be interested in supported payment methods as well. There are several other requirements to consider (billing, calculating usage metrics if you need, upgrade paths, etc..)

    Your integration probably will work webhooks. A 3rd party system will send notifications when something happens. You will need two things

    • A non changeable identifier in the 3rd party system (eg: user id)
    • An account or subscripiton id from the 3rd party in your system which ID the user
    • A status on your system about the user's subscription

    When you create a subscription set that flag to active, when the user cancels the subscription (or the sub is overdue) turn that flag to cancelled.

    The payments are not really interesting regarding the subs status, they are important for generate invoices.

    In general push all the logic to the 3rd party system and have only a very thin integration on your system.

    Other things to consider during the implementation

    • idempotency (to avoid double subs / charges)
    • configure retries of the webhooks
    • transaction handling / error handling (to avoid paying users wo/ subs, subs wo/ users)
    • data consistency between 3rd party and (to avoid split brain problems)
    • check what if the 3rd party system is down, which parts of your system will degrade

    Hope it helps!

    1. 1

      This is great. I am so glad this was asked. I was just working through a subscription schema, pulling my hair out doing so, for a new project. My first with integrated subscriptions. I will definitely go this route with Stripe.

  4. 2

    Depending on your language and stack there's probably already a package that someone spent months building. It may also depend on the payment provider you use.

    For example Stripe: You create the recurring subscription through their API, and they handle charging your customer every month. If something goes wrong (payment declined, etc) you'll have webhooks on your application to handle dealing with these events (stopping their subscription, etc)

    1. 1

      Okay cool. So Stripe handles the recurring charge and hits one of your webhooks if successful or failure. What do you normally do when someone cancels? Do I create a webhook for that too?

      1. 3

        Exactly. So on your application you have the form to create a subscription. If that succeeds with stripe you do whatever you need to do on your side to 'activate' their subscription (give them access, set a subscribed flag, or however you're handling it).

        Canceling the subscription should also be handled by your application. This will basically just be another form that makes an API request to Stripe telling them to cancel the subscription.

        Webhooks are meant for things that happen outside of your app: Payments declined, making changes manually inside the stripe dashboard. This just makes sure the data in Stripe and in your app are in sync.

        1. 1

          Awesome. Thanks so much for your help.
          I've been a developer for almost 10 years and now that I'm bootstrapping, there's a whole host of things that I've never done before. I feel like a kid again. :)

  5. 1

    If you are in the UK you might want to look at https://recurly.com/

  6. 1

    I have a subscription model to handle the subscription (one-off, recurring, etc.) and just run a job to check for expiring ones — it's because in Germany we must do "consecutive invoice numbers" and automated Stripe invoices do NOT come with consecutive numbers :-(

  7. 1

    Hey, agree with @michaelmesserli that you can probably find something pre-built. Usually, you would set their user permissions to paid user/package once they pay, and listen for webhooks, downgrades and cancellations to switch that back.