Almost Every Billing Enquiry Is the Same Question

Look at the billing enquiries any subscription service receives and the overwhelming majority reduce to one thing, which is somebody who saw a line on a statement and does not recognise it. They are not disputing it, they are asking what it was. That is a question the platform already knows the answer to, and every time a person has to be involved in delivering it, you are paying somebody to read out a record that could simply have been visible. The useful way to think about billing tooling is therefore not how efficiently your team can look things up, but how many of those lookups never need to happen because the subscriber could see it themselves.

The temptation with a refunded or cancelled transaction is to make it disappear, on the reasonable sounding grounds that it no longer represents money you hold. Resist it. Six months later somebody disputes a charge with their bank, and what you need is not the current balance but the sequence of what happened, including the parts that were undone. A refund recorded against an order tells that story. A deleted order tells nothing, and the absence looks considerably worse than the reversal ever did. The same reasoning applies to cancelled subscriptions and closed accounts, which keep their history rather than being erased. The transactional side is covered under the orders manager and the recurring side under automated billing.

A single subscriber can pay you by card on your website, from a balance they topped up, and through an app store, sometimes all within the same year. Those are genuinely different arrangements with different providers and different rules about who can refund what, and pretending otherwise is how billing conversations go wrong. What the platform can do is hold one view of the person regardless of route, with each transaction recording how it actually happened. That means the answer to whether you can refund something is available before the conversation rather than during it. The providers themselves are covered under payment gateways, the store constraint under gateway level packages, and the account view under the subscribers manager.

Monthly reconciliation done by hand is slow, and worse, it produces a second set of numbers that gradually stops matching the first. Because orders and transactions are reachable through the API, an accounting package or a reconciliation job can read them directly, which keeps one set of records rather than two that quietly disagree. That is usually the right answer at any scale beyond a few hundred transactions a month, and it is considerably less work than it sounds. The interface is described under the REST API, and the summarised view your commercial team wants under the sales dashboard.