Cadencesubscription billing

A working demo · not a product

“They upgraded on the 12th. What do they pay?”

Taking the money is the easy half — a payment provider does that. The hard half is deciding what to charge: proration in both directions, trials, coupons that expire, graduated tiers, usage billed in arrears against a subscription billed in advance, a card that fails, and tax that is sometimes somebody else’s problem.

Every line below shows the arithmetic that produced it. Pick a situation and read it.

invoice, bar height is the amount something the customer did a payment that failed credit note

The invoices

What happened, in orderand what you can change

Edit the scenario

Anything you add is validated on the server before it runs — dates, plan names, seat counts and the length of the whole scenario. A page is not a place to trust input from.

Why it is built this way

There is no model in this one

Eight of the ten demos on my site use one somewhere. This one deliberately does not. What a customer owes on a given day has exactly one right answer, it is arithmetic, and arithmetic that is occasionally creative is not a feature. Knowing which problems are not language problems is most of the job.

deterministic · auditable · boring on purpose

Proration is two lines, never one

The unused part of the old configuration is credited and the new one is charged for the days remaining. The net is identical to a single “difference” line — but this is the only version a customer can check against their own calendar, and the only one that still makes sense when it has to be refunded.

credit + charge · days, not guesses

Integer minor units, end to end

No float touches a total anywhere in the engine. Tax is computed on the amount after discounts and after credit is applied, not before — charging tax on money that was never taken is a real liability rather than a rounding quibble.

rappen · not 0.1 + 0.2

The same file runs in both places

The Worker imports the engine from the folder it serves to your browser, so there is one copy of the rules and no build step in between. Your browser runs the scenario, the server runs it, and the page prints both fingerprints. If they ever disagreed you would see it above.

one engine · two runtimes · same digest

The cataloguefour plans, one meter, four tax situations
What it is made ofand what it will not do

Built with

  • Cloudflare Workers on cadence.malikakhtar.dev/api/*
  • D1 for saved scenarios and daily counters. Invoices are never stored — they are recomputed
  • One engine file, imported by the Worker and shipped to the browser unchanged
  • No AI, no payment provider, no dependencies, no build step

Limits, on purpose

  • Saved scenarios are kept for 14 days

No money moves here and none can. Cadence takes no card details, connects to no payment provider and issues nothing anybody could pay. Taking the money is a solved problem you should buy; deciding the amount is the part that gets written badly, and that is the part this is.