A chargeback war room for every open Checkout.com dispute

Build me a chargeback war room: an internal workbench for the person on our team who fights card disputes. This is the surface they work out of all day, so the goal is that they never need to open the Checkout.com dashboard to review a case, assemble evidence, or execute a decision. It is not an alerting tool, it is the workbench where the defense actually gets built and submitted.

The main screen is a queue of every open dispute, pulled with Get Disputes from Checkout.com and sorted by response deadline with the most urgent first. Each row shows the dispute id, the amount, the currency, the reason code with a plain English label, the status, the customer or payment reference, and a days remaining badge counting down to the evidence deadline. The badge turns red when fewer than three days remain and should be visually loud, since a missed deadline is an automatic loss. Give the queue filters for status, reason code and an amount range, and make the sort by deadline the default. Get Disputes paginates with limit (maximum 250) and skip, and returns total_count, so implement real paging in the handler and show the reviewer how many cases they are looking at out of the total rather than silently truncating at the first page.

Above the queue put a header strip with two numbers that matter to the team: total money at risk, which is the summed amount of all currently open disputes, and the win rate so far this quarter, calculated from disputes resolved this quarter by comparing cases won against total resolved. If disputes span multiple currencies, group the money at risk by currency rather than adding different currencies into one meaningless total.

Clicking any row opens a work pane for that dispute. The pane loads the case in full: Get Dispute Details for the dispute itself and, importantly, its evidence requirements; Get Dispute Evidence for whatever is already attached; and Get Submitted Dispute Evidence for anything already sent. It then pulls the commercial context around the case so the reviewer sees everything side by side: Get Payment Details for the underlying payment, including the order reference and the card details, Get Payment Actions for the full action history so the reviewer can see the authorization, the capture, and any earlier refunds or voids in sequence, and Get Customer Details for the customer record. Lay this out so the order, the card, the capture and the refund history are readable at a glance without expanding anything, because the refund history in particular often decides whether a case is worth fighting.

The centrepiece of the pane is the evidence builder. Render the evidence requirements returned by Get Dispute Details as a checklist of required evidence types, each showing whether it is still missing, attached, or already submitted. For each required item the reviewer can search our Google Drive using List Files with a Drive query to find the matching invoice, delivery proof or support thread, see candidate results with name, type and modified date, confirm the right one using Get File Metadata, and attach it to that checklist item. When they attach, the app downloads the file with Download File Content, uploads it to Checkout.com with Upload a File (this is a multipart upload, not JSON) to obtain a file id, and then attaches that file id to the correct evidence type on the dispute with Provide Dispute Evidence. Let the reviewer also see and remove anything they attached by mistake before sending.

Respect the three step evidence flow exactly and never collapse it: upload the file, attach it with Provide Dispute Evidence, then submit with Submit Dispute Evidence. Nothing reaches the card scheme until that final submit, so the difference between saved and submitted has to be unmistakable in the interface. Use clear state labels on both the checklist items and the case itself, and keep the submit button disabled until every required evidence type has at least one attached file, with a hint naming exactly which items are still missing.

From the same pane the reviewer takes one of two decisions. They can submit the defense with Submit Dispute Evidence, or they can accept the dispute with Accept a Dispute. Accepting is irreversible and closes the case in the cardholder's favour, so it needs a confirmation step and a written reason that the reviewer has to type before the action is enabled, and that reason should be stored with the case and displayed afterwards. For cases that escalate, allow arbitration evidence to be submitted with Submit Arbitration Evidence, and show what was already sent using Get Submitted Arbitration Evidence so the reviewer is not guessing.

Every submit and every accept posts a short summary to a Slack channel with Send a Message, so finance and support see the outcome without being in the app. Keep the message tight: the decision taken, the dispute id and reason code, the amount and currency, the customer or order reference, who made the call, and for accepts the written reason. Make the channel configurable.

Two details to get right throughout. First, formatting: Checkout.com returns amounts as integers in the currency's minor unit, so 1000 is 10.00 GBP, but zero decimal currencies such as JPY and KRW are already in the major unit and three decimal currencies such as BHD, KWD and OMR are the value times 1000. Format every amount in the queue, the header strip, the work pane and the Slack message in a currency aware way. Second, keep a local decision log recording who submitted or accepted each case, when, the written reason where one applies, and which Drive files were attached, so the team has an audit trail of how each case was handled and can review past defenses when a similar reason code comes up again.