A disputed transaction lands in support
A customer who uses your card says they did not receive the goods from an online shop, or they were charged twice, or they do not recognise a payment at all. Support takes the details in chat and passes it to the disputes person, who is also the payments ops person on Tuesdays.
They open the card processor's portal for the transaction, your admin panel for the customer, the chat for what the customer said, and ask the customer for screenshots of their emails with the merchant. The evidence goes into a shared drive folder named after the customer. The submission is filled into the processor's portal by hand. The deadline is on a sticky note, or in a calendar reminder if the person is careful.
Why disputes are slow to prepare
Disputes follow the card scheme's rules and your processor's process, both of which have stages and time limits. Your side of it, gathering evidence and keeping track, is usually done with general tools.
- Transaction data is in the processor portal, customer data in your admin panel.
- The customer's account of what happened is spread across chat messages.
- Supporting documents arrive as email attachments or chat uploads.
- Dates for each stage are tracked manually.
- There is no view of all open disputes and where each one is.
The cost when a dispute slips
A missed deadline can decide the outcome regardless of the facts, and the customer is out of pocket or you are. Each case takes an experienced person a long time, and that person is usually doing another job too. Customers ask for updates that nobody can give quickly. Patterns, like one merchant that generates many disputes, are hard to spot.
Which disputes to raise and on what grounds is your team's decision under the scheme rules and your processor's guidance. The build supports that decision; it does not make it.
A dispute case tool for your ops team
What we build brings each dispute into one case, from the first report to the outcome.
- Support raises a dispute from the helpdesk or admin panel, picking the transaction from the customer's list rather than typing details.
- The case pulls transaction data from your processor's API, plus the customer's recent card activity and account history.
- The customer receives a short form asking for their statement and uploads, based on the dispute type, and their answers land on the case.
- Stage dates are calculated from the rules you give us and shown on the case with reminders.
- The case screen shows everything together and lets the ops person write the submission.
- Where your processor has a disputes API, the submission is sent from the case; where it does not, the case produces a pack formatted for manual upload.
- Outcomes are recorded, and a report shows open cases by stage and repeat merchants.
| Stage | What the tool does | Who acts |
|---|---|---|
| Customer reports | Opens case, links transaction | Support agent |
| Evidence gathering | Sends customer form, pulls data | Automatic, ops reviews |
| Submission | Prepares pack, sends by API if available | Ops |
| Waiting on merchant or scheme | Tracks dates, reminders | Automatic |
| Outcome | Records result, updates customer | Ops |
How dispute days change
The disputes person opens a list of open cases sorted by next date. Most evidence is already on each case. The customer form means fewer back-and-forth messages. Support can see the stage and tell the customer where things stand without asking ops.
When a merchant appears in several disputes, it shows in the report, which may lead to a product or fraud decision earlier than it otherwise would.
Does your disputes process look like this?
- Evidence lives in shared drive folders per customer.
- Deadlines are tracked in calendars or on notes.
- Transaction details are copied from the processor portal by hand.
- Customers are asked for evidence in free text chat.
- Nobody has a list of every open dispute and its stage.