Abonnement- & Zahlungssysteme
Managing subscription revenue is more than issuing invoices: upgrades, trials, usage limits and gating decisions come together in one engine. We run this engine live across our 46 SaaS products.
Managing subscription revenue is more than issuing invoices
Recurring revenue looks simple but hides countless edge cases behind it: when a trial ends, how a mid-cycle plan upgrade is calculated, what happens when a card is declined, which user should see which feature. All of this has to live in one engine — plan, trial, usage limit and the gating decision defined in the same place, so that when a rule changes you edit one spot, not code scattered across screens. We're not inventing this engine; we run it live across our 46 sector SaaS products today.
The gating decision is an architectural principle for us: whether a feature is on or off for a given customer lives in one service, with the mapping held in a single constant. The gate's source might be a plan, a license or a trial period — when the source changes, only that source's adapter changes; an 'if' block never gets buried in a screen. We build your subscription system with this discipline; as you grow, adding a new plan or a new payment provider never means touching the core.
- Plan, trial and usage limit in one engine
- The gating decision lives in one service
- A discipline running live across 46 SaaS products
- A new plan/provider means just a new adapter
The sub-services beneath the subscription engine
The invisible half of a subscription isn't the charge — it's the rule behind it.
Plan, package & trial management
Trial periods, plan upgrades/downgrades and prorated billing; subscription state is defined in one place.
Usage limits & feature gating
Which feature is on for which plan; the gate decision lives in one service, with no conditions scattered across screens.
Payment provider & virtual POS
We connect to the provider's secure flow and never hold card data ourselves — only a secure reference/token.
Failed charges & retry (dunning)
A declined card is retried automatically and the subscriber is notified in time; revenue doesn't quietly leak away.
Invoicing, e-invoice & tax
Invoice and receipt generation is designed to connect to e-invoice/e-archive systems; tax lines are calculated separately.
Reconciliation, revenue & payout reports
The provider's statement matches your own records line by line; revenue, refunds and pending collections show on one panel.
The lifecycle of a subscription
Trial
The user starts a trial; the gate opens according to the trial plan, and a reminder goes out before it ends.
Subscription
A plan is chosen, the first charge runs, and the gate is re-evaluated for the chosen plan — feature access updates instantly.
Renewal
Automatic billing fires at period end; if it fails, the retry flow kicks in and the subscriber is notified.
Cancellation
On cancellation, proration or a refund rule applies; the gate closes but past data is retained — coming back is always possible.
Win-back
A targeted reminder or offer goes to the churned user; the subscription cycle isn't closed — it's a gate that can reopen.
The engine's three parts
The gating engine
The decision of who has a feature turned on doesn't live in 'if' blocks scattered across screens — it lives in one service, with the plan-feature mapping held in a single constant. If the gate's source changes — a license instead of a plan, a quota instead of a trial — only that source's adapter changes; the interface layer stays untouched.
- The gate decision in one service
- Plan-feature mapping in one constant
- Only the adapter changes when the source changes
Payment provider integration
We build a secure flow with the virtual POS and provider API; card data stays in the provider's own vault, not on our side. Webhook notifications from the provider are verified with HMAC — a forged or duplicate notification never triggers a charge twice.
- No card data stored, only a token
- HMAC webhook verification
- Protection against duplicate notifications
Invoicing & tax
Every charge becomes an invoice or a receipt; document generation is designed to connect to e-invoice/e-archive systems, and tax lines are calculated separately by plan and region. Revenue shows on the dashboard broken down by plan — you don't wait for a separate report to see how much each package brings in.
- E-invoice/e-archive-ready document generation
- Tax calculated by plan and region
- Revenue-by-plan breakdown on the dashboard
This engine is already running in our sector products
Subscription isn't only a SaaS panel's job; recurring revenue flows, in different shapes, beneath many of our products.
Finance & insurance
We built the subscription and billing engine, the payment flow and reconciliation in our finance/insurance product; on the pension/life-insurance side, premium and renewal tracking is another face of the same logic.
Enterprise work management
In our enterprise product family, modules turn on independently: you start with project tracking today and add HR and document management tomorrow — that module switch is the same gating logic.
Our mobile product family
Setting up in-app purchase and subscription flows in line with each platform's own rules is a standard part of our mobile-development service.
Our maintenance & SLA family
A monthly maintenance contract, SLA response time and a monthly hour pool for small development — itself a recurring service model.
What ships as standard in every subscription setup
The technology we build on
- Virtual POS
- provider API
- Plan + limit + gating
- .NET 9
- PostgreSQL
- HMAC
- webhook verification
- JWT
Frequently asked
Do you store the card details?
No. Card data stays in the payment provider's vault; only a secure token/reference is kept on our side. Data you don't store is data you can't leak.
Can you work with more than one payment provider?
Yes. The payment provider is set up as an independent adapter; adding a new provider or switching between two doesn't touch the core gate/plan logic.
Does billing start automatically when the trial ends?
It depends on the rule — card details can be captured at trial start and billing can auto-trigger at the end, or the user can be asked to pick a plan when the trial ends. That's your product decision, not ours; the engine supports both.
How is a current subscriber's invoice calculated when a plan changes?
When an upgrade or downgrade happens mid-cycle, a prorated calculation runs based on the remaining days; the difference is applied to the next invoice or charged immediately — this behavior is configurable by rule.
Does it connect to a tax/e-invoice system?
Invoice and receipt generation is designed to connect to e-invoice/e-archive systems; tax lines are calculated separately by plan and region. We clarify together which official system you need to connect to.
Let's build your subscription engine together
We'll listen to your plan structure, payment provider and billing needs and map out where to start, together. The first conversation is non-binding.