Why support should not be able to fix your balance

Every support team eventually gets asked the same question by its own management: why can you not just fix it?

A customer is upset. The amount is small. The agent can see the problem. Giving them a button that adjusts the balance would end the call in thirty seconds.

It is the single most tempting tool to build, and it should not exist.

What that button costs

It can be aimed at you. An agent who can move balances is a target. Social engineering does not attack systems; it attacks people with permissions, under pressure, who want to be helpful.

It hides the real problem. If a bug underpays customers and agents quietly top them up, the bug is never found. It is being paid for, invisibly, out of goodwill.

It destroys the books. A platform whose balances can be edited cannot prove what it owes. Not to a regulator, not to an auditor, and ultimately not to itself.

Read everything, change nothing

Support here can see the ledger, the payment, every attempt against it, every state change, and the hash-chained event log around it.

They cannot set a balance — and not because of a permission flag that could be changed on a bad day. They cannot because balances are not stored. A balance is the sum of its postings. There is no number to set.

So what happens when you are genuinely owed money

A posting. Under the ordinary authority and maker-checker rules, with a reason recorded and — for anything material — a second person approving.

It is slower than a button. It is also auditable, reversible and attributable, which the button never was.

The answer comes from the record

When you ask where your payment went, the agent is reading what happened: the attempts, the rail, the state changes, the timestamps.

Not an estimate. Not it is probably still processing. And where the record genuinely does not say, you should be told that — an honest we do not know yet, here is what we are doing is worth more than a confident guess that turns out wrong.

Every action has a name on it

Administrative actions are written to the audit trail under the agent’s own name.

That protects you, and it protects them: an agent who did the right thing has a record proving it.

What it costs

Nothing, and there is no paid priority queue. A broken payment is more urgent than a large account, and any system that reorders those two is optimising for the wrong customer.

What you can check

These are facts about the running platform, not adjectives. Each one is visible in the product, in the API reference or in the ledger.

• Agents read the ledger and the hash-chained event log; they cannot set a balance, because balances are derived from postings rather than stored.
• A correction is a posting under the ordinary authority and maker-checker rules, so a fix is as auditable as the original.
• Every payment carries its attempts and its state changes, so an agent can say what happened rather than what probably happened.
• Administrative actions are written to the audit trail under the agent’s own name.

What it costs

Support is included. There is no paid priority queue that moves a customer with a broken payment behind one who paid more.

Is it switched on?

Whether this is available depends on the authorisations in place and on what the administrator of a given deployment has switched on. That changes, and an article does not — so the live answer lives on the feature page, which reads it from the platform itself: Support and help on the features page.

Read next

• The ledger — Books that cannot be quietly edited.
• Refunds and disputes — A promise you can actually keep.
• Risk and compliance — Refused before, not recalled after.