Billing looks like a solved problem until the first price change. Then somebody asks what happens to customers mid-cycle, whether the old price stays for existing subscribers, how a refund works when half the month is used, and the answer turns out to be a spreadsheet and a developer.
A billing layer is the part that knows who owes what and when. It is separate from the gateway, which moves the money, and separate from the merchant account, which holds it. Choosing it badly is expensive in a specific way: you only discover the gaps when you want to change something commercial, and by then the customer base is large.
What the billing layer is responsible for
Four things, none of which belong in your product code if you can avoid it.
The plan catalogue. What you sell, at what price, in which currencies, with what trial and what billing period. Businesses that hardcode this end up unable to run an experiment without a release.
The subscription state machine. Active, in trial, past due, paused, cancelled, and the transitions between them. Most billing bugs are really missing states: nobody decided what «past due» means, so it means something different in three places.
Proration and changes. Upgrades mid-cycle, downgrades at period end, pauses, cancellations with or without refund. These rules are commercial decisions, and they change more often than anyone expects.
The charge schedule. When to attempt payment, when to retry and when to give up. This is where billing meets the payment side, and the two have to agree.
Questions that separate platforms
Ask how a price change is applied. A good system lets you raise prices for new customers while grandfathering existing ones, without a migration script. If the answer involves exporting and re-importing subscriptions, expect pain later.
Ask what happens when a customer upgrades on day ten. The amount charged, the amount credited and the next renewal date should all follow from one setting, not from manual arithmetic.
Ask how trials end. A trial that converts silently on day fourteen and a trial that requires confirmation are different products with different dispute profiles, and both need to be possible.
Ask what the customer sees. Invoices, receipts and the billing portal are part of the product experience, and a portal where someone can update a card or cancel in one click prevents more disputes than any fraud rule.
Build or buy
Small catalogues with one plan and one currency can live inside your own code for a long time. The line gets crossed when any of these appear: more than a couple of plans, multiple currencies, usage-based components, or a finance team that needs reports you did not plan for.
The honest comparison is not licence cost against zero. It is licence cost against the engineering time you will spend on proration edge cases, invoice numbering, tax lines and the migration you will eventually do anyway. Most teams underestimate the last one by a factor of three.
Where billing and payments must agree
Two systems holding separate opinions about the same subscription is the most common source of silent revenue loss. The billing platform thinks a customer is active; the payment side stopped charging them a month ago. Nobody notices until the annual reconciliation.
Prevent it with a single source of truth for subscription state, and a daily job that compares the two. Also agree where retries are configured: if both layers retry independently, customers get charged twice and you get disputes. Our merchant account reporting exists partly so this comparison is possible without exports.
Taxes and currencies live here too
Tax is not a payments problem, yet it lands in the billing layer because that is where invoices are produced. Selling across borders means different rates, exemptions for business customers with a valid tax number, and documents that have to show the right lines.
Decide who calculates it. Some billing platforms do it natively, others expect a tax service alongside, and a few leave it to you entirely. The third option is fine with one country and painful with ten.
Currency sits next to it. If you charge in several, settlement arrives in several, and keeping that tidy is easier with a dedicated business IBAN than with a personal operating account.
What we support is listed under payment methods.
What to settle before migration
If you are moving from one billing system to another, decide three things in advance. What happens to stored card credentials — whether they can be transferred at all depends on the providers involved. What happens to subscription anniversaries, since shifting everyone to the first of the month creates the billing spike you spent years avoiding. And how long you will run both systems in parallel, because the answer is never zero.
Connection on our side takes from 5 days once documents are ready, and the steps are on how it works.
Commercial terms, with rates from 1.8% for middle-risk models, are on the pricing page.
Connection from 5 days. Fees from 1.8% — transparent terms, no hidden charges. Leave a request or book a consultation and we will put together the right setup for your niche and risk profile.