chargebacks

---
name: chargebacks
description: Turns a chargeback notification from your acquirer into a dated response pack, the dispute condition identified by its number, the exact evidence that condition accepts listed item by item, a decision to defend or accept with the reasoning written down, a covering response that addresses each point the cardholder made, and a running register that shows which of your disputes you win and which you keep losing for the same reason. Use the day a chargeback lands, and again when you want to know why you keep getting the same one.
---

# A chargeback answered with the evidence the rules actually accept, and a register that shows you which one keeps coming back

You give this the chargeback notification from your acquirer, the transaction receipt, the booking or order record and whatever correspondence exists with the customer. You get back the dispute condition identified by its number, the list of evidence that condition accepts, a defend or accept decision with the reasoning recorded, a response addressing each of the cardholder's points, and a register entry so the pattern shows up before the fourth one arrives. It will not tell you your chances of winning. Nobody publishes a win rate for a single independent venue, and a percentage invented to make a decision look supported is worse than no percentage at all.

## What it does

1. **Start the clock in the same minute the notification arrives.** Visa's own merchant guidance is blunt about it: "Timeliness is also crucial when attempting to remedy a dispute. Each step in the dispute cycle has a defined time limit during which action can be taken. If you or your acquirer do not respond during the time specified on the request, which may vary depending on your acquirer, it may potentially lead to unfavorable outcome of the case." The deadline that binds you is the one your acquirer sets, not the one in the scheme rules, and it is usually shorter. Write the notification date, the acquirer's stated deadline and your internal deadline two working days earlier at the top of the file before doing anything else.

2. **Identify the dispute condition by its number, because the number decides what evidence counts.** Visa organises disputes into four categories with numbered conditions: 10 Fraud, 11 Authorization, 12 Processing Errors and 13 Consumer Disputes. The conditions a venue actually meets are 10.3 Other Fraud in a card-present environment, 10.4 Other Fraud in a card-absent environment, 11.3 No Authorization or Late Presentment, 12.5 Incorrect Amount, 12.6 Duplicate Processing or Paid by Other Means, 13.1 Merchandise or Services Not Received, 13.3 Not as Described or Defective, 13.6 Credit Not Processed and 13.7 Cancelled Merchandise or Services. Answering a 13.3 with the evidence that wins a 10.3 loses. Record the condition number exactly as the notification states it.

3. **Ask the one question that decides a card-present fraud dispute: was the chip read.** For condition 10.3 the cardholder is "claiming that they did not authorize or participate in a key-entered transaction conducted in a card-present environment". The guidance gives three responses and no others. If the card was swiped or chip-read and authorised, provide the authorisation record as proof the magnetic stripe or chip was read. If a manual imprint was obtained, provide it, and the guidance notes that this "Does not apply to the Europe region". And then the one most venues do not want to hear: "The transaction was not swiped, chip-read, or manually imprinted. Accept the dispute." A key-entered transaction taken because the chip would not read, with no imprint, is a dispute you lose, and the money is gone before you start writing.

4. **For a card-absent dispute, gather the elements the rules name rather than the story you want to tell.** Condition 10.4 covers a transaction the cardholder says they did not authorise in a card-absent environment, which for a venue means a telephone booking, a deposit taken over the phone, or a no show charge on a stored card. The guidance sets out the specific route: two or more completed transactions settled in the window before the dispute which the issuer did not report as fraud, sharing "at least two data elements (device ID, device fingerprint, or the IP address) the same as the disputed transaction", together with a detailed description of what was purchased in the disputed transaction and the two previous ones. A venue that takes phone bookings and writes nothing down has none of this.

5. **Treat a not as described dispute as a quality argument you have to evidence, and note the sting in the tail.** Condition 13.3 covers services that "did not match the description on the transaction receipt or other documentation presented at the time of purchase", services not the same as a verbal description, and a cardholder who "disputes the quality of the merchandise or services". The guidance's advice is to provide specific information or documentation to refute the claims, notes that for quality disputes "There may be instances where you will need to obtain a neutral third-party opinion", and says plainly that "It is recommended that you address each point that the cardholder has made". Then the sentence that catches out every venue with a no refunds sign: "Merchants should keep in mind that their return policy has no bearing on disputes that fall under this dispute condition."

6. **Check whether the dispute is actually a credit you already processed, because a surprising number are.** Conditions 13.6 Credit Not Processed and 12.6 Duplicate Processing catch the venue that refunded in cash, refunded to a different card, or ran the terminal twice when the first attempt appeared to fail. The response the guidance asks for is the same in several conditions: "Provide documentation of the credit or reversal that includes the amount and the date it was processed." If you refunded by any route other than back to the original card, you need the record that proves it, and if you refunded in cash you may have no record at all, which is its own finding.

7. **Decide to defend or accept, and write the reason down either way.** The guidance is explicit that accepting is sometimes correct: "Although many disputes are resolved without the merchant losing the sale, some cannot be remedied. In such cases, accepting the dispute may save you the time and expense of needlessly contesting it." Record the decision, the reason, who made it and the date. A venue that defends everything burns hours it does not have on disputes it cannot win, and a venue that accepts everything never finds out which of its processes is generating them.

8. **Assemble the evidence to the standard the rules set, not the standard that feels convincing.** Two requirements apply whatever the condition. Supply everything at the first notification: "it is essential to promptly supply all available details including relevant documentation at the initial dispute notification". And make it readable: "Evidence must be legible (good scan copy) and in English or accompanied by an English translation". A photograph of a docket taken at an angle in low light is not evidence, and neither is a till roll that has faded. Scan, name each file for what it proves, and list the files in the covering response in the order the points are answered.

9. **Hand the assembly and the register to Codex after you have made the decision.** Put the notification, the receipts, the booking records, the correspondence and your decision in one working folder and run, from that folder:

   ```
   codex exec --sandbox danger-full-access --skip-git-repo-check -C "<working folder>" - < CODEX.md
   ```

   Claude hands over the condition number, the evidence checklist for that condition, your defend or accept decision, the documents you hold and the cardholder's points. Codex returns the dispute register entry, the evidence checklist with each item marked held or missing, the deadline calendar and a gaps file. Codex never decides whether to defend, never writes the covering response and never judges whether a document proves anything.

10. **Read the register every month and act on the pattern, not the individual case.** Visa's guidance recommends tracking disputes by condition, tracking them as a proportion of sales activity, and tracking card-present and card-absent disputes separately, because "Each condition is associated with unique business issues and requires specific remedies and reduction strategies". Three 10.3s in a quarter is not bad luck, it is a terminal that will not read chips and a team that key-enters instead of asking for another card. That fix costs one conversation. The disputes cost the sale, the fee and the hour.

## Then it checks

1. Every dispute in the register carries the condition number exactly as the acquirer's notification states it, and no dispute is recorded with a category alone.
2. Every dispute has a notification date, an acquirer deadline and an internal deadline, and the internal deadline is earlier than the acquirer's.
3. Every evidence item on the checklist is marked held or missing, with the file name where it is held, and no item is left blank.
4. Every defend or accept decision names the person who made it, the date, and the reason in one sentence.
5. Every document listed as evidence is legible and in English or accompanied by a translation, and the file records who confirmed that and when.
6. No sentence in the output states a probability, a likelihood or a win rate for the dispute.

Any check fails: name it, redo that step once. Failed twice: say what is wrong and stop.

## Rules
- Public information only.
- Never invent a fact, a number or a quote.
- Anything sent in someone's name says whose name it is.
- Never state a chargeback rate, a win rate or a typical number of disputes for a UK hospitality business. No published figure exists for a single independent venue, the percentages that circulate come from firms selling chargeback services, and an owner who believes a borrowed figure will either accept a serious problem as normal or spend money solving one they do not have.
- Never write a fact into a dispute response that is not in a document you can produce. A response that asserts the customer ate the meal, with nothing behind it, is weaker than a response that produces the signed docket and says nothing else.
- Never present the venue's refund policy as an answer to a condition 13.3 dispute. The scheme guidance states that the return policy has no bearing on that condition, and leading with it wastes the one response you get.
- Never defend a card-present fraud dispute where the transaction was key-entered with no imprint and no chip read. The guidance says to accept it, and the time is better spent stopping the next one.
- Never send the response direct to the cardholder or the issuer. It goes to your acquirer, through the route and within the deadline your acquirer has given you, and any contact with the customer is a separate decision the owner makes knowingly.
- Never treat a customer's withdrawal of a dispute as done until you hold it in writing. The guidance asks for "a letter or email from the cardholder that states they no longer dispute the transaction", which means a phone call is not evidence.
- This output is a working document prepared for the owner to check against their own records, and for their accountant and, where the sum or the allegation is serious, their solicitor to check before it is sent. It applies published scheme guidance to documents you supply. It is not legal advice and it is not a prediction of the outcome.

## Built from
- Visa, "Dispute Management Guidelines for Visa Merchants", June 2024, https://usa.visa.com/content/dam/VCOM/global/support-legal/documents/merchants-dispute-management-guidelines.pdf, read 23 September 2026: the definition of a dispute, the four categories and their numbered conditions, the timeliness and legibility requirements, the responses for conditions 10.3, 10.4 and 13.3, the credit and reversal evidence, the advice on accepting a dispute and the dispute monitoring recommendations, in steps 1 to 10.
- The Payment Services Regulations 2017, regulation 76, https://www.legislation.gov.uk/uksi/2017/752/regulation/76, read 23 September 2026: the separate statutory route by which a payer's own provider must refund an unauthorised transaction, which is why a fraud dispute can reach you even where you did nothing wrong, in steps 3 and 4.
- The Payment Services Regulations 2017, regulation 79, https://www.legislation.gov.uk/uksi/2017/752/regulation/79, read 23 September 2026: refunds for authorised transactions initiated by or through the payee where the exact amount was not specified, which is the shape of a disputed deposit or no show charge, in step 4.
- Regulation (EU) 2015/751 on interchange fees, Article 12, as it applies in the UK, https://www.legislation.gov.uk/eur/2015/751/article/12, read 23 September 2026: the per transaction information from your acquirer that lets you match a disputed transaction to its settlement, in step 6.

# chargebacks

## You are given
One chargeback notification from the owner's acquirer, stating the transaction reference, the amount, the notification date and the dispute condition number exactly as the acquirer wrote it. The transaction receipt or terminal record. The booking or order record where one exists. Any correspondence with the customer. The owner's defend or accept decision for this dispute, already made, with the reason in the owner's own words. The owner's list of documents they hold against this dispute, each named as a file. The acquirer's stated response deadline for this dispute, in the owner's own words if no exact date was given. All judgement calls, including whether to defend, whether a document proves a point and what the covering response says, have already been made by the owner and Claude, and are supplied to you as finished text and decisions. You do not evaluate evidence, you record it.

## Produce
Write into a `./chargebacks-output/` folder:

1. `dispute-register.csv` with these columns in this order: `dispute_ref`, `notification_date`, `acquirer_name`, `transaction_reference`, `transaction_date`, `transaction_amount_gbp`, `condition_number`, `condition_category`, `card_present_or_absent`, `acquirer_deadline`, `internal_deadline`, `decision`, `decision_reason`, `decision_by`, `decision_date`, `outcome`, `outcome_date`. `dispute_ref` is DSP001 upward, one row per dispute supplied. `condition_category` is exactly one of `fraud`, `authorization`, `processing errors`, `consumer disputes`, copied from what the owner recorded against the condition number, never inferred by you. `card_present_or_absent` is exactly one of `card present`, `card absent`, `not applicable`. `decision` is exactly `defend` or `accept`, copied from the owner. `outcome` is exactly one of `pending`, `won`, `lost`, `withdrawn by cardholder`, and starts as `pending` unless the owner supplied an outcome.
2. `evidence-checklist.csv` with columns: `dispute_ref`, `condition_number`, `evidence_item`, `held_or_missing`, `file_name`, `legible_confirmed_by`, `legible_confirmed_date`, `language`. One row per evidence item the owner's brief names as required for that condition number. `held_or_missing` is exactly `held` or `missing`. `language` is exactly `English` or `translated with English copy attached`. Every row where `held_or_missing` is `missing` is also listed in `gaps.md`.
3. `deadline-calendar.csv` with columns: `dispute_ref`, `notification_date`, `acquirer_deadline`, `internal_deadline`, `days_remaining_from_notification`, `response_sent_date`. `internal_deadline` must be earlier than `acquirer_deadline` in every row; where the owner supplied deadlines that do not satisfy this, record both dates as supplied and list it in `gaps.md`, do not correct it yourself.
4. `pattern-summary.csv` with columns: `condition_number`, `condition_category`, `dispute_count`, `defended_count`, `accepted_count`, `won_count`, `lost_count`, `card_present_count`, `card_absent_count`. One row per distinct condition number appearing in `dispute-register.csv`, counted from that file only. No percentage, rate or ratio column. No row for a condition with a single dispute is described as a pattern; that word is not used anywhere in this file.
5. `gaps.md` a numbered list of: every evidence item marked `missing`; every dispute with no acquirer deadline supplied; every dispute where the internal deadline is not earlier than the acquirer deadline; every dispute with a `decision` field left blank; every document marked `held` with no `legible_confirmed_by` entered; and any figure or date supplied without a clear source.

## Rules
- Codex records, counts and calendars. It never decides whether to defend or accept a dispute, never writes or edits the covering response sent to the acquirer, never judges whether a document proves a point, and never estimates a missing date or amount.
- Never state a win rate, a chargeback rate, a percentage or any comparison to a typical or average business, in any file. No such figure exists for a single independent UK venue and none is to be recorded.
- Never mark evidence `held` because a document of that general type usually exists. Only a document the owner named as supplied is `held`. Everything else is `missing`.
- Never carry a decision, a document or a deadline forward from a previous dispute in the register. Each `dispute_ref` is judged only on what the owner supplied for it.
- Never set `outcome` to `won` or `lost` without the owner having supplied that outcome. An unresolved dispute stays `pending`.
- Use British English, GBP written as `GBP` or the pound sign, and DD Month YYYY dates. No em dashes in any file you write, and any supplied text containing one is recorded verbatim and flagged in `gaps.md`.
- Every quoted condition number, deadline and file name is copied exactly as the owner supplied it.
- Every file ends with this line: this is a working document prepared for the owner to check against their own acquirer correspondence, and for their accountant and, where the sum or the allegation is serious, their solicitor to check before anything is sent. It applies supplied facts and decisions to a record and is not a ruling on the outcome of any dispute.

## Return
The absolute path of every file written, the row count of each CSV, the total number of disputes in the register and how many are `pending`, `won`, `lost` and `withdrawn by cardholder`, the count of evidence items marked `missing` and which dispute they sit against, the count of disputes with no acquirer deadline supplied or with an internal deadline not earlier than the acquirer deadline, the condition numbers appearing more than once in `pattern-summary.csv` stated plainly with their counts and no rate attached, and the `gaps.md` item count.