Support and help
Support that can see the same ledger and the same events you can, so an answer is read off the record rather than guessed — and cannot change your balance to make a problem go away.
Every customer who has had a payment go wrong, and every operator who has to answer for what their support team did.
Switched on for this deployment.
The problem
Support teams under pressure are given tools to make problems go away. An agent who can adjust a balance can be socially engineered, can make mistakes, and leaves a platform unable to prove what actually happened.
How it works
- Open a ticket, or chat where that is available.
- The agent can see the payment, its attempts, its events and its state.
- The answer is read from the record rather than estimated.
- Where money genuinely needs to move, it is a posting under the ordinary controls — not an edit.
What you can check
Facts about the running platform rather than adjectives. Each one is visible in the product, the API reference or 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.
Questions
Why can support not just put the money back?
Because an agent who can set a balance can be talked into setting it by somebody who is not you, and because a platform whose balances can be edited cannot prove what it owes anybody. A genuine correction is a posting, under the same controls as any other movement.
Will they actually know what happened to my payment?
They can see the payment, every attempt, every state change and the events around it. The answer comes from the record. Where the record genuinely does not say, they will tell you that rather than invent a reason.
Is there a faster queue if I pay?
No. A broken payment is more urgent than a large account, and a priority queue that reorders those two is selling the wrong thing.
Read next
The ledger
A double-entry ledger where balances are derived from postings rather than stored, corrections are opposing entries rather than edits, and invariants are enforced at write time instead of checked by a nightly job.
Refunds and disputes
A refund that reserves the money atomically before it is promised, and a dispute that is an object with a timetable rather than an email thread somebody is supposed to remember.
Risk and compliance
A sanctions screen that runs inside the posting, before money moves, so a blocked payment is refused rather than recalled — and every alert becomes a case with a decision and a name against it.