> ## Documentation Index > Fetch the complete documentation index at: https://waffo.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Chargeback Evidence Guide > How to choose representment evidence: the three questions every defence has to answer, which question each dispute reason turns on, how the material differs for physical goods, digital goods and services, what to send when the reason is unknown, why a second cycle can appear without any action from you, and why a customer dispute can close on its own. > [!NOTE] > > Everything on this page is **guidance for improving your chances**, not a promise about > outcomes. Chargeback decisions are made by the issuing side under card scheme and payment > method rules; assembling every recommended item does not guarantee a case is won, and Waffo > does not warrant a result. Use the **Evidence Requirements** list on the individual case as > the authoritative statement of what that case needs. [Chargeback & Dispute FAQ](/docs/en/support/chargeback-faq) covers the process — how cases arrive, how to submit, deadlines and statuses. This page is about *what to put in the submission*. Field-level meanings are in [Chargeback field reference](/docs/en/support/chargeback-field-reference). ## How does Waffo decide what evidence to recommend for my case? Every case carries an **Evidence Requirements** list, generated from the case's dispute reason and marking each item as mandatory or recommended. A submission missing a mandatory item is blocked before it is sent, so read the list before you start collecting. Underneath that list is a single idea worth understanding, because it lets you assemble a strong submission even when the list is thin: whatever the reason code, a defence is only ever answering three questions. ## What are the three questions a defence has to answer? | Dimension | The question | What answers it | | - | - | - | | **A — Transaction authenticity** | Did this transaction genuinely happen, initiated by this person? | The authorisation result, device and IP information, account and login activity, prior transaction history with the same account | | **B — Fulfillment** | Was the product or service actually delivered? | Delivery or access confirmation, usage records, invoices and receipts | | **C — Policy compliance** | Were cancellation and refund handled according to your published policy? | The policy exactly as it was shown at checkout, the buyer's acknowledgement of it, your communication with the buyer | The dispute reason decides which of the three carries the weight; the **product type** decides what form the evidence takes. The industry you are in changes neither — it only changes the vocabulary of the same documents. ## Which question does each dispute reason turn on? Ten reasons cover essentially all cases. Use this to know where to spend your effort; use the case's own Evidence Requirements to know exactly what to attach. | The buyer is claiming | Primary dimension | Also worth including | | - | - | - | | Fraud / the transaction was not authorised | **A** — authenticity | B, to show the buyer received and used what they paid for | | The goods or service were never received | **B** — fulfillment | A, to tie the delivery to the same account | | The goods or service did not match the description | **B** — fulfillment | C, for your returns policy and any prior resolution offered | | The goods or service were cancelled | **C** — policy compliance | B, to show what had already been delivered at the point of cancellation | | A subscription was cancelled but was still charged | **C** — policy compliance | A, for the record of the authorisation given for recurring charges | | A refund was promised but never arrived | **B** — the refund itself is the fact in dispute | C, for the communication trail | | The charge was duplicated, or already paid another way | **A** — authenticity of *each* charge | B, to show two separate fulfilments where there were two | | The transaction was processed incorrectly (amount, currency, date) | **A** — authenticity | — | | Something authorisation-related | **A** — authenticity | — | | Reason unknown | **B** first, then C — see below | A where you have it | The two patterns to notice: a **fraud or authorisation** claim is answered with authenticity, and a **cancellation or subscription** claim is answered with your policy. Sending delivery proof against a "subscription cancelled but still charged" claim answers a question nobody asked. ## What changes when I sell digital goods or services rather than physical goods? The dimension stays the same; the document changes. This is where most weak submissions come from — a digital business sending nothing under dimension B because it has no shipping paperwork. | Dimension | Physical goods | Digital goods | Services | | - | - | - | - | | **A** authenticity | Authorisation result, device / IP, account history | Same, plus the account's login and session record | Same, plus the booking or account record | | **B** fulfillment | Delivery confirmation and tracking, and where possible a signature or handover record | Download, activation, entitlement or access logs showing the buyer's account actually used what was bought | Records that the service was rendered — appointments kept, sessions attended, work delivered | | **C** policy compliance | Returns and refund policy as shown at checkout, plus the buyer's acknowledgement | Same, plus the cancellation path actually available in the product | Same, plus the terms of the engagement | "Delivered" for a digital or service purchase means **the buyer's own account consumed it**. A record showing that the entitlement was granted is weaker than one showing it was used. Where you can show usage, lead with usage. ## The reason code is unknown or unhelpful. What do I send? Send the fallback combination: 1. **Proof of delivery or access** (dimension B) 2. **The invoice or receipt** for the transaction 3. **Your communication record** with the buyer (dimension C) Together these answer "it happened, it was delivered, and here is how we handled it" without committing to a defence of a specific claim. Before submitting, try to find out what the actual claim is — the case file on the issuing side, or a direct conversation with the buyer, usually reveals it — and then add the material for that claim. A targeted submission beats a broad one. ## Are there file format or size limits I should know about? The upload API itself accepts JPG, JPEG, PNG and PDF up to 10 MB per file — see [Chargeback & Dispute FAQ](/docs/en/support/chargeback-faq). Beyond that, some payment methods enforce stricter file type or file size rules than the API does, so a file Waffo accepts can still be refused further along. Where a case has such a restriction, it is stated in that case's Evidence Requirements. If you are producing evidence programmatically, generating PDFs rather than large images is the safer default. ## The case came back as `MORE_EVIDENCE_REQUIRED`. Do I re-upload everything? No — and re-uploading everything can lose you material. When more evidence is asked for, the case returns to an evidence-required state and you submit again, but the submission is a **field-level replace**: a field you send replaces whatever was in it before, and a field you omit is left untouched. So the correct move is to send only the field carrying the new material. If you resend a field with a shorter list of file references than before, the earlier references in that field are gone. Keep your own record of what you attached in each field on each round; the case shows you the current state, not the history of what each field held. `MORE_EVIDENCE_REQUIRED` is also a signal about content, not just quantity. It usually means one of the three questions was left unanswered rather than that more of the same is wanted — re-read the case's Evidence Requirements and check which dimension is thin before adding anything. ## What can I actually submit in a second cycle? A defence note, and nothing else. Second-cycle (Pre-Arbitration) cases **do not accept evidence files at all** — the submission is the decision to defend, optionally with a note. Most card scheme rules also refuse material at this stage that was not presented in the first cycle, so there is generally nothing new to add even where a channel would take it. The practical consequence is that **the first cycle is your one real opportunity**. Material you hold back, or do not have ready in time, cannot be introduced later. Assemble the full submission the first time round rather than sending a minimum and planning to supplement it. Mechanics for both cycles are in [Chargeback & Dispute FAQ](/docs/en/support/chargeback-faq). ## I passed 3DS and the buyer still claimed fraud. Why did a second cycle appear when I never responded? Under some card scheme flows, a chargeback raised as fraud on a transaction that **was** 3DS-authenticated is defended on your behalf — the defence is submitted without waiting for a response from you, because the authentication record itself is the answer to the claim. That defence can succeed, and a successful defence is exactly what allows the issuing side to escalate the case to a **second cycle (Pre-Arbitration)**. The consequence catches merchants out: * You never chose to defend, so you were not expecting a second cycle at all. * A second cycle books **another chargeback fee** against you — see [Chargeback field reference](/docs/en/support/chargeback-field-reference) for the settlement lines. * If you have set a blanket strategy of never defending, that strategy did not prevent this, because the first-cycle defence was not yours to decline. What to do about it: watch for the `AUTO_SUBMITS_EVIDENCE` timeline event, which is how a submission made on your behalf shows up on the case, and treat any case whose Life Cycle is `SECOND_CYCLE` as needing a decision even if you never touched the first cycle. If the fee exposure from this pattern matters to your business, raise it with Waffo rather than assuming your default strategy covers it. ## Will I be warned before an evidence deadline passes? Do not build your process on being warned. Every case carries its own `expiryDateTime`, and that value is authoritative. Two things you can rely on: * Both dispute lists offer an **expiring soon** filter, returning open cases whose deadline falls in the next **3 days**. * A deadline event appears on the case timeline (`NOTIFY_OVERDUE`), so a case that was flagged shows it in its own history. Poll the lists, or track `expiryDateTime` per case from the API, and act on your own schedule. The deadline consequence differs sharply by case type — an expired chargeback is a loss, an expired customer dispute is still workable — which is set out in [Chargeback field reference](/docs/en/support/chargeback-field-reference). ## My customer dispute went to `CLOSED` and I did not close it. Did I lose? No — `CLOSED` on a customer dispute is not a verdict. It is the end of that record, and a customer dispute never books money against you by itself. Three things move a customer dispute to `CLOSED`: | How it closed | What it means | | - | - | | You or Waffo closed it in the Portal | Recorded as closed by the merchant side | | A close event arrived from the payment method's side | The complaint was resolved or withdrawn there | | The **linked chargeback** reached a final status | The case was already escalated; the chargeback outcome is the real outcome | The third is the one that surprises people: once a chargeback exists on the same payment, the customer dispute record stops being the place the decision happens, and it is closed out when the chargeback finishes. Look at the chargeback for the result — and remember that a `CLOSED` customer dispute can reopen if the buyer complains again. ## How do I stop the Chargeback Alert service? Not from the Portal — it is not a self-service switch. Alert coverage is held as part of your merchant configuration, and it is enabled and disabled **per alert service type**, so you can stop one and keep another. To stop it, contact Waffo and say which service type you want deactivated. Waffo sets that entry to inactive; it stops applying from that point. Fees already incurred on alerts already delivered still clear — billing follows delivery, which is covered in [Chargeback & Dispute FAQ](/docs/en/support/chargeback-faq). Worth deciding deliberately rather than reflexively: stopping alerts removes the chance to refund before a chargeback is raised, so the cases that alerts were absorbing arrive as chargebacks instead, with the chargeback fee and the amount attached. Compare against what the alerts were costing you before switching them off. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.