Dispute/Representation: How to Win

1) The purpose of Representation and the principle of the "right package"

Representation is the counter-argument of the chargeback merchant by the rules of the scheme. You do not win "true in general," but an exact match: the reason for the chargeback ↔ acceptable evidence ↔ deadlines ↔ format. Key: send relevant artifacts in the right form and on time.

2) Process and deadlines (high-level)

1. Retrieval/Inquiry - request information.
2. Chargeback - write-off; start of window for response.
3. Representation is your evidence package.
4. Pre-Arbitration (Pre-Arb) - Extra Round.
5. Arbitration (Arb) - the final of the scheme, high fees.

3) Reason map → what to prove

3. 1 Фрод / «No Cardholder Authorization»

Purpose: to show that the holder is authenticated and/or the transaction is performed legitimately by this particular client.

• 3DS 2. x: ECI, CAVV/AVV, dsTransID/threeDSServerTransID, ARes/CRes референсы (liability shift).
• Device/IP fingerprint, timestamps, geo coincidence with profile, login history.
• KYC status, account activities (deposits, sessions, conclusions).
• Notifications/letters/fluffs and customer confirmations.

3. 2 Service dispute ("Service not provided/not in compliance")

Purpose: to prove that the service was provided in accordance with the offer.

• Game session logs: time, IP/device, bets/wins, balance movements.
• Account statements: deposit → game → withdrawal/balance.
• Version of the Rules/ToS/bonus conditions at the time of the transaction + consent.
• Ticket history and support responses, settlement proposals.

3. 3 Technical/operational (doubles, amounts, currencies)

Purpose: to show the absence of an error or its timely correction.

• Idempotence log, 'payment _ id ↔ psp_txn_id ↔ arn/rrn'.
• Reconciliation logs (authorization/kapchur/return).
• Return confirmation (if made) with dates and amounts.

4) "Storytelling" package: how to issue

1. Case summary (1 page): chargeback reason, position thesis, attachment list, timeline.

2. Facts/Chronology: point by point, with reference to timestamps.

3. Proofs: Attachments with numbering and brief annotations.

4. Regulatory reference: the rule clause of the scheme/acquirer under which your case falls (at the level of wording without citing internal regulations, if not required).

5. Conclusion: what are you asking for (reject the chargeback).

5) Argumentation templates (ready-made formulations)

• "The transaction is authenticated by EMV 3DS 2. x: ECI=X, CAVV=…, dsTransID=…. In accordance with the rules, responsibility is transferred to the issuer. Additionally, we attach a device/IP match and account activity immediately after the deposit."

• "There is a coincidence of the device/browser, IP-country, normal game session after the deposit, withdrawal of funds for the same payment method. The probability of compromise is low; transaction is legitimate."

• "Game activity is confirmed by logs (time, bets, results), rules and restrictions were available and accepted. A return request has been received after the service/bonus has been used.

• "Duplication is fixed by the idempotency mechanism; excess amount returned to T + 1, ARN/rrn attached. Please close the dispute."

6) Automation: What an orchestrator should do

Automatic collection of 3DS artifacts (ECI, CAVV, dsTransID) and binding to 'payment _ id'.
Event logs: Auth/Capture/Refund/Chargeback/Representation in a single feed.
Showcase "Case Builder": checklists, generation of title page and timeline from logs.
Integration with DWH: fast offloader of sessions/balance.
SLA alerts: T-3/T-1 to deadline, package completeness control.
Text templates for reason types in the desired language.

7) Success Metrics (KPIs) and Target Levels

Win Rate (general) - target: ≥ 60-70% for fraud cases with 3DS; ≥ 40-50% for service dispute.
Coverage Rate - the share of cases with a full package (target: 95% +).
Time-to-Respond p95 - no later than T-1 to the acquiring deadline.
Repeat CB (recurrence) by client/device - QoQ reduction.
Cost per Case/ROI protection - increased return on prepared packages.
3DS Liability Shift Protected% - the share of fraud cases closed due to 3DS.

8) Practical script playbooks

A. "No Auth," 3DS passed (frictionless/challenge success)

1. Checking 3DS artifacts → 2) Add device/IP/geo → 3) Short storytelling → 4) Send.

Goal: fast win due to liability shift.

B. "Service not provided," sessions available

1. Upload game/balance logs → 2) Attach ToS/bonus terms → 3) Attach ticket screen → 4) Send.

Purpose: Show actual consumption.

C. Doubles/amount/currency

1. Check idempotency → 2) Make a return on confirmation → 3) Attach ARN/rrn → 4) Request to close.

Purpose: Remove technical complaint.

9) Working with the acquirer and the "tonality" of correspondence

Keep a channel with a list of escalation contacts (L1/L2/L3 at the acquirer).
Write briefly, structurally, without emotion, with links to attachments and timecodes.
Do not argue with "opinions" - operate with the rules of the scheme, the facts of the logs, 3DS, KYC.

10) Legal and compliance notes

GDPR/PII: include minimum required information; mask addresses, e-mail, phones.
PCI DSS: no PAN/CVV; only/last4 tokens and transaction IDs.
Local requirements: for some countries - texts in the local language/time zone/currency.

11) Frequent mistakes (and how to avoid them)

Late with the package → automatic loss. Solution: SLA alerts, backup performers.
No key 3DS artifacts → lost fraud case. Solution: Autocomplete in orchestrator.
Weak storytelling: "many screens without logic." Solution: a single template.
Extra PII/PAN → PCI/GDPR risks. Solution: pre-filter export.
Confused identifiers (payment_id/psp_txn_id/arn) → the case is not mixed. Solution: map of correspondences in the lager.

12) Representation checklist (short version)

• The reason is correct and the argument template is selected.
• 3DS artifacts (ECI/CAVV/dsTransID) collected and verified.
• Session/balance logs and statements: yes, readable, annotated.
• ToS/bonus terms at the time of the deal - attached.
• End-to-end identifiers are 'payment _ id ↔ psp_txn_id ↔ arn/rrn'.
• Format/language/time stamps - according to the requirements of the acquirer.
• GDPR/PCI verification: no extra PII/PAN.
• SLA: filed no later than T-1, proof of shipment recorded.
• The final conclusion (what you are asking for) is formulated explicitly.

13) Cover sheet template (example)

Case ID: CB-2025-001234

• Transaction: payment_id/ psp_txn_id/arn/date-time/amount/currency
• Summary: (1-2 paragraphs of position)
• Evidence List: E1—3DS (ECI/CAVV/dsTransID), E2—Device/IP, E3—Session Logs, E4—Wallet Ledger, E5—ToS, E6—Support Tickets
• Timeline: t0—Auth, t1—Game, t2—Withdrawal, t3—CB, t4—Representment

14) Retrospective and improvements (after each case)

Update risk rules (if lost due to a specific pattern).
Add templates (new wording and examples).
Revise the routing/3DS policy on BIN/issuer if there is a surge in the segment.
Train support/finance on real cases (best/worst).

15) Summary

1. automatic collection of key artifacts (3DS, logs, lager),

2. Clear storytelling template for the reason

3. strict discipline of deadlines and package quality,

4. win rate metrics and feedback to risk rules and routing.

This way you increase the share of won cases, reduce the cost of disputes and protect conversion without unnecessary blocking of honest customers.