Billing per delivery, enforced in exactly one place

Signedy runs on a prepaid usage model rather than a flat monthly seat price: an account holds a token balance, and sending a delivery for signature spends one token, with an additional charge if that delivery uses eID verification. It's simple to explain to a customer. Making it simple to get right in the codebase took more care, because there isn't just one place where a delivery can be sent.

More than one way to send

Deliveries can go out through a few different paths: an account sending one manually, a bulk batch sending several at once, and automated flows that trigger a send as part of a larger workflow. Each of those is a genuinely different code path, built for a different use case, with different callers and different surrounding logic.

The naive way to bill for token usage would be to add a balance check and a deduction at each of those send points individually. That works, until one of them gets missed, or a fourth send path gets added later by someone who doesn't know all three existing ones need the same check duplicated into it. Billing logic scattered across multiple call sites is billing logic that will eventually drift out of sync with itself.

One TokenService, called from everywhere

Instead, every path that can send a delivery routes through a single TokenService that owns the entire concern: checking whether the account has enough balance, deducting the right amount, including the eID surcharge when it applies, and recording the transaction. The manual send path, the bulk batch path, and the automated flow trigger all call the same service rather than each implementing their own version of "check and deduct."

This isn't just tidier code. It's the difference between a billing rule that's structurally guaranteed to apply everywhere a delivery can be sent, and one that only applies everywhere someone remembered to add it. A new send path added later automatically gets correct billing behavior simply by calling the existing service, rather than needing someone to remember to reimplement the check.

Manual top-up now, a payment integration next

Right now, adding tokens to an account's balance is a manual process on Signedy's side. That's a reasonable place to start: the enforcement and accounting logic, the part that actually has to be correct, is already built and centralized. Automating the purchase side, letting an account top up its own balance directly through a payment integration, is a separate concern layered on top of a billing model that already works, rather than something that needed to be solved before the core system could ship.

Centralizing enforcement first and automating purchasing later is the right order for exactly the reason above: a billing model with money on the line needs its enforcement to be provably correct and impossible to accidentally bypass, before it's worth the added complexity of an automated payment flow sitting on top of it.

Learn more about how Signedy prices document workflows on its product page.