Billing software development
Billing software development for fintech and B2B platforms: pricing plans, subscriptions, usage metering, proration and dunning - built so commercial policy is configuration, not code.
Results from work we have shipped
Shortlisting a software development partner?
The questions to ask in an RFP, three warning signs a vendor may not deliver, and a scoring matrix to compare contractors objectively.
What we build
Tiers, seats, entitlements, contract terms and the legacy plans nobody is allowed to break - modelled as data with a history, not as branches in code.
Sign-up, upgrade, downgrade, pause, cancel and reactivate, with proration handled correctly on every mid-cycle change.
Events collected, deduplicated and rated at volume, so a usage-priced product bills what actually happened rather than what an approximation suggests.
Discounts, credits, minimum commitments and the negotiated exceptions that make a deal - expressed as rules with an owner and an expiry rather than a permanent special case.
Failed-payment retries on a schedule that recovers revenue without annoying good customers, with the escalation and grace rules made explicit.
Billing output that the finance system can actually take - deferred revenue and recognition treated as a requirement rather than an export nobody trusts.
The output handed to invoicing as a clean contract, so the legal document and the tax rules live where they belong.
See the serviceBilling held together by spreadsheets and goodwill?
Tell us your pricing model. We will tell you what it would take to make it configuration instead of code.
How we deliver billing software?
The same delivery discipline on every engagement - from the first map to a handover your team runs.
We start from how you actually charge - every plan, exception and legacy arrangement. The commercial model determines the data model, and getting that order wrong is what forces the rewrite.
In your repository, your CI and against the systems you already run. Billing that lives outside the platform becomes a reconciliation problem of its own.
Every line has to be traceable to the events and rules that produced it. If a customer disputes an invoice, the system answers - not an engineer with a query.
A configuration surface the pricing owner operates without a deployment, tests over the rules, runbooks for the billing run and a documented handover.
What shapes the work
Every pricing decision your business makes eventually becomes a billing rule: the legacy plan a long-standing customer keeps, the discount sales agreed to close a deal, the usage tier that resets monthly, the currency a market is priced in. Each one is reasonable on its own. Together they are the most volatile logic in the company, and they usually end up buried in the least accessible part of the codebase.
That is the actual problem with billing. Not that it is technically hard, but that commercial policy changes far faster than software releases, and a billing system that requires a deployment to change a price has put engineering in the middle of every commercial conversation.
So we build billing so that policy is configuration with an audit trail, and only the mechanics are code. The test is simple: can the person who owns pricing see what a customer is on, change it, and know what the change will do before it takes effect?
Billing failures are quiet. Nobody pages you because a customer was under-charged, so the damage accumulates until a finance review finds it. The patterns are consistent:
- Pricing logic in the application. The moment a discount is an if-statement, changing commercial policy needs a release, and the release needs an engineer who understands a deal signed two years ago.
- Proration invented per feature. Upgrades, downgrades and pauses each get their own arithmetic, they disagree, and the disagreement shows up as a credit note.
- Usage counted twice, or not at all. Metering without deduplication and idempotency bills the customer for a retry, which is the fastest way to lose their trust in every other number you show them.
- The billing run as an ordinary job. A half-finished run that is not safe to restart either double-charges or silently skips, and both are found by customers.
- No history. Without an effective-dated model you cannot answer what a customer was on last March, which is exactly the question a dispute or an audit asks.
The three get conflated constantly, and the conflation is expensive. Billing decides what a customer owes. Invoicing turns that into a legal document and delivers it. Payments collect the money.
They change for different reasons and fail differently: billing changes when commercial policy changes, invoicing changes when a tax authority changes, payments change when a provider or a scheme changes. Building them as one module means all three forces land in the same code, and every change becomes a risk to the other two.
We build them as separate systems with clear contracts between them. That is what lets you reprice without touching the invoice format, and change acquirer without touching either.
Metered pricing looks like a billing feature and behaves like a data pipeline. The events arrive out of order, duplicated by retries, occasionally late by hours, and sometimes wrong. Bill them naively and the invoice is a guess.
The parts that matter are unglamorous: idempotent ingestion, deduplication with a defined window, a late-arrival policy that is decided rather than discovered, and a rating step that can be re-run over a period and produce the same answer.
The prize is worth it, because usage pricing only works commercially if customers trust it. That trust comes from being able to show them exactly which events produced which line, which is a requirement we design in rather than add later.
The drivers are the shape of your commercial model rather than the number of screens: how many plans and exceptions really exist, whether pricing is seat-based, usage-based or both, whether proration and mid-cycle change are in scope, whether dunning is included, and which finance system has to receive the output.
The honest one is the second question we ask: how many of your current arrangements are undocumented. In most billing engagements the discovery of what the business actually charges takes longer than building the system that charges it, and we would rather find that out with you in week one.
As reference points from our own work on financial platforms, a banking platform we built saw 150x online-lending growth in a year, and a credit platform for $lana (Monetech) reached 1M+ users with full reporting - both are products where what the customer owes had to be right at volume.
WislaCode specialists quickly synchronised and worked with the second team involved in developing our solution. As a result, having started development from scratch, we came to the expected result quickly. The first users went to the application after 5 months.
What is included in a billing engagement
A billing engagement ends with the pricing controls in the business's hands:
The billing engine live in production, inside your repository and your CI.
Plans, entitlements and commercial terms modelled as effective-dated data with a full history.
Proration, upgrades, downgrades, pauses and cancellations with one consistent arithmetic.
Usage ingestion that is idempotent and deduplicated, with a defined late-arrival policy and re-runnable rating.
Dunning and retry rules that are explicit, measurable and tunable without a deployment.
A billing run that is restartable and safe, with monitoring on the window it must finish in.
A clean contract out to invoicing and to your finance system, tests over the rules, runbooks and a documented handover.
How long does a billing software build take?
Scope sets it: how many plans and exceptions genuinely exist, whether pricing is seat-based, usage-based or both, whether proration, dunning and revenue recognition are in scope, and which finance system has to receive the output. In most billing engagements, discovering what the business actually charges takes longer than building the system that charges it, so discovery exists to pin that down and produce a dated plan before you commit.
Should we build billing or buy a billing platform?
Buy where your pricing is conventional and build where it is a differentiator. A bought platform is an excellent answer to standard subscriptions and a poor one to a commercial model with genuine exceptions, because you will end up encoding those exceptions around the platform instead of in it. We are happy to integrate a billing platform for you or to build the engine inside your product - what we will not do is pretend the trade-off does not exist.
Can you migrate our existing customers and plans?
Yes, and it is usually the hardest part of the engagement rather than an afterthought. Live customers are on arrangements that must not change silently, so we model the existing plans as effective-dated data, run the new engine in parallel against real invoices until the outputs agree, and cut over per cohort. A migration that changes what a customer is charged without anyone deciding to is the one outcome we design against.
How do we keep a billing system auditable when pricing keeps changing?
By holding commercial policy as effective-dated data rather than as code. Every plan, discount and entitlement carries the dates it was true, so an invoice from March can be recomputed with March's rules and still produce the same number. Every charge should be explainable to a finance analyst without a developer present: which plan, which usage, which discount, which proration. That discipline is also what makes revenue recognition tractable, since IFRS 15, adopted into EU law by Commission Regulation (EU) 2016/1905, requires the transaction price to be allocated across performance obligations - which cannot be done from an invoice total.
Can a billing engine sit on top of a platform we already run?
Yes, and that is the usual shape. The engine needs three things from the existing platform: who the customer is, what they have subscribed to or consumed, and where the resulting charge should go. Everything else can stay where it is. We build the engine inside your stack behind a clear contract, run it in parallel against real invoices until the outputs agree, and cut over per cohort - so the old path stays available while the new one proves itself on your own numbers rather than on a test fixture.
How is billing handled across several countries and currencies?
By deciding early what is global and what is local. The plan model, the usage pipeline and the invoice structure should be one system. What varies by market is the price book, the currency and its rounding rules, the tax treatment, and the payment methods behind the charge. We hold those as configuration attached to the market rather than as branches in the code, because the alternative is a codebase that grows a new fork every time sales enters a country, and a finance team that cannot compare two markets.
Should AI be anywhere near a billing engine?
For finding what is wrong, yes. For deciding what is owed, no. Anomaly detection across invoice runs catches the silent failures that nobody pages you about - the under-charged cohort, the plan that stopped prorating. Dunning sequencing and retry timing respond genuinely well to modelling. What must never be probabilistic is the charge itself: a customer is owed a number that can be recomputed and explained, and a model that produces a slightly different figure on a second run is a finance problem wearing a product's clothes.
How do billing and the payment gateway fit together?
As two systems with one contract between them. Billing decides the amount and the due date; the gateway collects it and reports back, sometimes twice, sometimes out of order, sometimes not at all. So every write is idempotent and a reconciliation sweep closes whatever the webhooks missed. On authentication, Article 14 of the SCA-RTS, Commission Delegated Regulation (EU) 2018/389, exempts a series of recurring transactions of the same amount to the same payee after the first one - but a variable subscription charge is not that series, which is the assumption most billing designs get wrong.
How do we tell whether a partner has actually built billing before?
They ask about your exceptions before your requirements. Every business has plans that are not in the price list - the legacy customer, the deal sales agreed to close a quarter, the tier that resets differently - and the quality of a billing partner shows in how early they go looking for those. After that: how they migrate live customers without changing what anyone is charged, how a charge is explained to finance, and who can change a price after launch. If the answer to the last one is an engineer, the design is already wrong.
Moving from standard banking with a basic set of functions to a digital bank where everything can be done online.
View case
A progressive web app for independent and cooperative workouts in the gym, built for maximum accessibility.
View caseThis was a very task-heavy project, mostly exploration and R&D-driven. However, by the end of WislaCode, we were left with a detailed roadmap consisting of clear milestones - able to be converted into tangible KPIs - and some neat ideas of what actionable are next. Integrating...
We collaborated with WislaCode on a product strategy development project and gave the highest marks for this contractor. The WislaCode team delivered on time and with outstanding quality.
We collaborated with WislaCode on a route-to-market optimisation project. Working with WislaCode was effective, transparent and predictable, which is especially critical for AI and ML projects. We provided them with six months of anonymised data, and within just three weeks...
Repricing blocked by your own billing system?
Thirty minutes with the engineers who would rebuild it - the model, the migration and what it takes to change a price without a release.