A chargeback is the customer’s bank deciding for you, taking the money, and charging a fee whether you win or not. Most are communication failures, and three small fixes remove them.
Ilinca Bostan6 min readA chargeback is not a refund. A refund is you deciding to return money. A chargeback is the customer's bank deciding for you, taking the money back, charging you a fee for the privilege, and putting a mark against your merchant account that you cannot see and your acquirer never forgets.
Hosting is a category card networks watch, because it has the profile they associate with risk: digital delivery, recurring charges, instant provisioning, and a customer who may never have spoken to a human. Here is how disputes work, what to do about them operationally, and what your billing platform needs to support.
Not legal or financial advice, and not a guide to any specific card scheme's rules. Dispute reason codes, evidence requirements and time limits are set by the card networks and your acquirer, and they change. Confirm the current process with your payment provider. This post covers the operational and billing-platform side.
The customer contacts their bank rather than you. The bank reverses the transaction and notifies your processor. You are debited the amount plus a dispute fee — the fee applies whether or not you eventually win. You get a window, usually short, to submit evidence. A decision comes back weeks or months later.
Two things follow from that timeline. First, the money is gone from day one, so treat the dispute as a loss you might recover rather than a charge that might reverse. Second, the fee is a certainty and the recovery is not, which is why prevention is worth far more than dispute-handling skill.
"I did not authorise this." Genuine card fraud, or a family member's card. If it is real fraud, you have probably also provisioned a server to an abuser. This is a signup-screening problem before it is a billing problem — see fraud prevention for hosting signups.
"I cancelled this." The most common one, and usually a process failure rather than dishonesty. The customer thinks they cancelled — they emailed support, or clicked something ambiguous, or assumed not paying was cancellation. If your cancellation flow is unclear, this dispute is your own fault and the evidence will show it.
"I did not recognise the charge." Your billing descriptor on the statement does not match the brand the customer bought from. Entirely preventable: set the descriptor to your trading name, and make sure renewal emails use the same name.
"The service did not work." A quality dispute. Your evidence is uptime data, ticket history and what your SLA actually promised.
Decide first whether to fight it. Contesting a €9 shared-hosting dispute costs more staff time than the amount, and losing still costs the fee. Contesting a €400 dedicated server dispute with a clean audit trail is usually worth it. Set a threshold and apply it consistently rather than deciding case by case.
Then decide what happens to the service. A chargeback means you have not been paid, so the service should follow your normal non-payment path — but consider a suspension rather than immediate termination while the dispute is open, because destroying data belonging to a customer who turns out to be right is a much larger problem than an unpaid invoice.
Then record it properly. The invoice is not paid any more. Your books need to reflect a reversal and a fee, not a quietly deleted payment record. This is where a lot of hosting businesses lose track: the money is gone from the bank but the invoice still shows paid in the platform, and the discrepancy surfaces at year end.
A customer who disputes once and returns is worth watching. A customer who disputes, gets the money back, signs up again with the same card, and disputes again is running a pattern — and cheap monthly hosting is a common target because the amounts are individually too small to fight. Blocking on payment fingerprint rather than only on email address is what catches this.
Being straight about scope: FluxBilling does not ship a dedicated dispute-management workflow — there is no built-in evidence-submission flow to your acquirer, and that process runs in your processor's dashboard. What it does support is the record-keeping and the recovery path around one.
Every payment gateway plugin forwards the processor's own decline and failure reason back into the platform rather than collapsing it into a generic error, so a failed or reversed payment carries a reason you can act on instead of a shrug. Webhook deliveries from gateways are logged durably, so a reversal that arrives asynchronously leaves a record rather than vanishing into a request that returned 200. Credit notes reference the invoice they correct, so recording a reversal is a document rather than an edit, and the result flows through the accounting export. Suspension and termination are separate lifecycle steps, so a disputed service can be suspended without being destroyed — see the suspension and termination timeline.
See billing features and the gateway catalogue.
Most chargebacks are not fraud, they are communication failures with a bank attached. The descriptor, the renewal notice and the self-service cancellation are three small pieces of work that remove most of them, and none requires a feature you have to buy. Do those first, set a threshold for what you contest, and make sure a reversal shows up in your books as a reversal rather than as a payment that stopped existing.
The gap between "this invoice is overdue" and "this server is gone" is a policy, not a feature. Most businesses never write it down, so it exists anyway as whatever the software defaults to.
Getting money in is built carefully. Getting it back out is built in a hurry, and that is where the accounting goes wrong. Four operations that look like one.
A gap in an invoice sequence is a question you have to answer, and "the software did it" is not an answer. Where hosting businesses generate gaps and how to stop.