Two attempts at a subscription billing engine

I recently published getpaidhq.co as an open-source project on github.com. The one-sentence pitch is: a subscription engine that supports complex billing models and usage-based billing, customizable multi-channel dunning, self-serve customer UX, and first-class API and DX.

I started building it in 2025 under the project name Payloop. The initial project was to create a subscription payment engine for my checkout platform CheckoutJoy to process subscription payments for our merchants, so I could justify a transaction-fee-based pricing model. My decision to build my own billing platform was influenced by:

• I found that most payment processors serving the creator market don't handle any of the advanced use cases of subscription billing. Things like revenue recovery, variable amounts and discounts, any form of metering and usage-based billing aren't part of their core offering.

• It was becoming a basic business need in the creator market to be able to build more complex offers and funnels using a combination of these features. For example selling membership access for a discounted rate based on participation, or simple AI token usage billing.

So I started building Payloop. The MVP was a subscription payment engine with configurable dunning workflows that would connect to the merchants payment processor and handle subscription payments using tokenised payment details. Payment failures should kick off a dunning process with easy payment links or payment detail update UX for the customer.

The initial version was built on the actor model - an architecture I learned early in my career building telco systems in Erlang - where each subscription instance is a standalone durable workflow that manages its own state and updates through messages and events.

I chose that approach based on lessons I learnt in an earlier attempt I made to build a subscription engine - one that was built on cron jobs and fan-out workers (basically a for-loop executing billing tasks when some timestamp or condition matched). It was my first attempt at this, and I quickly learned how things could become an unmanageable mess when workflow complexity outmatches architectural design.

A use case like this clearly deserved something more engineered than a managed for-loop.

Building the actor-model version was a great experience and real exposure to durable workflow design and to building with technologies like Temporal and Hatchet. I'm still not sure whether the actor model simplifies the engine or adds another level of complexity (e.g. data synchronisation - what is ultimately the source of truth?), so part of the work I'm currently doing is implementing different workflow architectures to get the exact best fit for the system. The other architecture I'm working on is a hybrid of the two models - a cron-based system for longer intervals like monthly billing, and an actor-based system for shorter intervals like 14-day dunning campaigns.

The system is organised based on the hexagonal architecture. One of the best decisions I've made, and the main one that makes this work possible. Ultimately, the right implementation will be a combination that ensures the core traits of the system - be scalable, be flexible, be easy to deploy and manage.

I never got around to offering the subscription service to our merchants in CheckoutJoy, but I love this space so much that I need to continue working to find the right fit. Once it's ready, it might form a core part of CheckoutJoy's subscription offering.

I'm publishing the platform under MIT to invite contributions with as little friction as possible.

My focus now is on building out the different workflow engines and productising: auth flows, dashboard UI/UX, public documentation, and website.