chargeback_evidence_readiness v1.0.0

name: chargeback_evidence_readiness description: "Prepare and submit a chargeback response that can win: read the reason code and the processor deadline first, decide accept or fight, match evidence to what each card network expects for that code (Visa 10 to 13, Mastercard 4837, 4808, 4834, 4853, Amex letter codes), assemble delivery, usage, and communication records in reviewer order, catch contradictions and broken exhibit references with a shipped case tracker, write the rebuttal letter, and submit before the window closes with a copy kept for the next dispute. Use when a chargeback, dispute, or inquiry notice arrives, when building an evidence packet or rebuttal, or when setting up a repeatable dispute process."

Chargeback Evidence Readiness

Purpose

A chargeback is decided by an issuer reviewer who reads one packet, fast, against one reason code. Most merchant losses are self-inflicted: the response answers a claim nobody made, leads with an order confirmation when the claim is non-delivery, cites records that contradict each other, or arrives after the deadline and is decided by default. This skill runs the full response, from the notice to a submitted, saved packet. It covers Visa, Mastercard, and American Express, with Discover inquiry handling noted where it changes the work. A gap check on one file is only one step inside it. The decision to accept a valid chargeback is part of the workflow, and spending the response window on a case the records cannot support helps nobody.

Workflow

1. Read the notice before collecting anything. Record case id, network, reason code, amount, currency, transaction date, notice date, and the response deadline printed on the notice into a case file. Start one with python3 scripts/chargeback_tracker.py new --network visa --code 13.1 --case-id CASE-ID --processor-deadline YYYY-MM-DD --amount-cents 8400 from this skill folder, then read the file back against the notice once. The deadline on your notice binds you. Two clocks run on every case: the network window, which runs to the acquirer, and the processor window, which is earlier and is yours. Stripe puts the merchant window at usually 7 to 21 days depending on the network, Mastercard gives the acquirer 45 days, Amex gives the merchant 20 days, and a processor can shorten any of those. Plan from the notice date, never from a network number quoted in an article.
2. Set the internal dates. Run python3 scripts/chargeback_tracker.py deadlines CASE.json. It sets review done 3 days before the deadline, evidence frozen 2 days before, and submission 1 day before. A response filed on the deadline day has no room left for a failed upload or a missing page.
3. Name the dispute type from the code, then check the claim wording. Use references/evidence-map.md to map the code: Visa sorts disputes into Fraud 10.x, Authorization 11.x, Processing Errors 12.x, and Consumer Disputes 13.x. Mastercard has consolidated most cases into 4837 fraud, 4808 authorization, 4834 point-of-interaction error, and 4853 cardholder dispute, with older codes such as 4841 and 4855 still appearing. Amex uses letter codes, F for fraud, C for cardmember disputes, A for authorization, P for processing, and R for inquiry outcomes. If the customer's own words describe a different problem than the code says, raise the miscoding with your acquirer or processor and still answer the code on the case.
4. Make the accept or fight call, in writing, on day one. Accept when the claim is true, when a refund was already promised, when the charge followed a recorded cancellation with no later usage, or when your own records show the error the code names. Fighting a valid chargeback costs the fee, the window, and credibility with your processor. Fight when a record exists that directly answers the code. Record the call and the reason in the case file.
5. Answer an inquiry like a chargeback. Amex usually opens with an inquiry, a document request with no debit attached, and an unanswered or thin reply escalates it. Amex codes that outcome directly: R13 for no reply inside the time frame, R03 for an insufficient reply. Discover inquiries carry the same risk, and a dispute that escalates from an ignored inquiry may not be challengeable at all. The inquiry packet gets the same evidence order and the same audit as a chargeback packet.
6. Collect evidence in reviewer order, lead record first. The per-reason map in references/evidence-map.md names the lead record for each dispute type. For fraud, lead with the authentication record and, for Visa 10.4, test the Compelling Evidence 3.0 path before writing anything: two earlier undisputed transactions on the same credential, 120 to 365 days before the dispute, with at least two matching data elements and one of them the IP address or device ID. For not received, lead with a delivery scan showing date and full address, or access logs for digital goods. For credit not processed, lead with the refund record or with the policy that denies the credit. Pull delivery records, usage logs, and customer communication from their source systems, and keep the source date on each record.
7. Give every exhibit an id, a label, and a one-sentence proves line. The proves line states what the record shows, in plain words, with the date or amount inside it. An exhibit with no proves line is filler, and filler dilutes the lead record. Cut marketing material, full policy documents where one clause is the point, and any record the letter will not cite.
8. Audit the case file before writing the letter. Run python3 scripts/chargeback_tracker.py audit CASE.json. It checks the deadline status, missing evidence kinds for the dispute type, lead evidence position, duplicate or uncited exhibit ids, and contradictions: delivery before the transaction date, delivery ZIP against order ZIP, refund amount against disputed amount, disputed amount above the transaction amount, and a charge after cancellation with no usage recorded. Fix errors at the source record, not by editing the finding away. A contradiction the auditor can find, the issuer reviewer can find, and one contradiction is enough for a reviewer to stop trusting the packet.
9. Write the rebuttal letter last, from the audited exhibits. Structure: case id, reason code, and transaction details in the header, a one or two sentence summary of why the chargeback does not hold, a labeled exhibit list in packet order using the proves lines from the case file, and a close that asks for reversal of the specific amount. Keep it to one page where the processor format allows it. Neutral tone, no claims about the customer's character or intent, no facts that no exhibit supports. Every exhibit is cited in the letter and every citation points at a real exhibit.
10. Submit through the processor, early, and confirm the submission landed. Save the confirmation, the submitted packet exactly as sent, and the final case file together under the case id. The issuer then usually takes 60 to 75 days to decide and the full lifecycle can run two to three months, so the saved file has to make sense to someone who never saw the order. If the case escalates to pre-arbitration or a second dispute arrives on the same transaction, the saved packet is the starting point and its exhibit ids stay unchanged.

Output Contract

• A case file for the dispute, created from the notice, with case id, network, reason code, dispute type, amounts, transaction and notice dates, and the processor deadline.
• The deadline plan from the tracker: days remaining, internal review date, evidence freeze date, and submit date, all ahead of the processor deadline.
• The accept or fight decision, with the reason, recorded before evidence collection starts.
• An evidence packet ordered lead record first, each exhibit with an id, a label, and a proves line, matched to the evidence map entry for the reason code.
• The final audit output for the submitted packet, with zero errors, and every warning either fixed or carrying a written reason in the case file.
• A rebuttal letter in the structure above, citing every exhibit and nothing that no exhibit supports.
• A saved submission bundle: confirmation, packet as sent, and final case file, kept together under the case id for the next dispute or escalation.
• A worked dispute carried from notice to submission lives in references/worked-dispute.md, with its passing case file in examples/worked-case.json and its earlier failing draft in examples/broken-case.json.

Operating Rules

1. The date on the case notice is the deadline. Network windows, article summaries, and another processor's timetable are background only.
2. Evidence answers the code, not the order. Proof that a purchase happened never answers a claim that it did not arrive, was not authorized, or was already refunded.
3. Lead with the answering record. Reviewers read in order and stop early. The strongest record for the code goes first, support follows in the map order.
4. Accept valid chargebacks fast. A true claim fought to the end still loses, and the response window is the scarcest resource in the process.
5. Never submit a packet with a known contradiction in it. Fix the source record or explain the difference with its own exhibit. Silence about a visible mismatch reads as carelessness about all the other records.
6. Never invent or round a date, amount, tracking status, or match result. If a record does not exist, say the packet does not have it and decide on that basis. A shipped scan is not a delivery scan.
7. Do not copy a reason code or evidence set from a previous case or a template for another network. The same complaint carries different codes and different lead evidence on Visa, Mastercard, and Amex.
8. Keep cardholder data inside the processor channel. Submit through the processor or acquirer route the notice names, keep full card numbers out of the packet and out of this case file, and keep the saved bundle in the same access-controlled place as other payment records.
9. One case, one file, one packet version submitted. If new evidence arrives after submission, send it through the processor as a supplement tied to the same case id, and update the saved bundle so the record of what the issuer saw stays complete.