Dispute Management
Manage chargeback cases, prepare evidence-backed responses, and follow provider outcomes in DEUNA Admin.
On this page
Dispute Management brings the chargeback workflow into one DEUNA Admin workspace. Operations teams can move from the original payment to the case, the response, and the confirmed provider outcome without losing context.
The optional Disputes Agent can help normalize case context, prioritize deadlines, identify evidence gaps, and prepare a recommended action. It does not expand provider capabilities or grant submission authority; the access, approval, and outcome boundaries in this guide still apply.
Disputes
Prioritize chargebacks by deadline, preparation state, and next action.
| Case | Reason | Provider | Disputed | Deadline | Status |
|---|---|---|---|---|---|
| Product not received | Worldpay | $128.40 | Oct 4 | Needs response | |
| Cardholder did not authorize | Adyen | $82.00 | Oct 7 | Under review | |
| Credit not processed | Stripe | $246.90 | Closed | Won | |
| Duplicate processing | Worldpay | $54.25 | Closed | Lost |
01 / One connected workflow, from intake to outcome#
The workflow follows five stages. A case can enter automatically from a verified provider notification or be registered from an existing chargeback; registration records an existing case and never initiates a chargeback with a bank.
| Stage | Merchant outcome |
|---|---|
| 01 · Receive or register | Connect the provider case to the original payment and processor account. |
| 02 · Understand what is needed | Read the claim, response deadline, available actions, and current requirements. |
| 03 · Prepare and review | Combine structured facts with exact, validated evidence versions and approve the frozen package. |
| 04 · Send the appropriate request | Submit the action allowed for that provider account, case stage, and round. |
| 05 · Follow confirmed progress | Track delivery separately from provider review and the final case outcome. |
One case, three independent tracks
Identity verification first tells you whether DEUNA has matched a reported case to an authoritative provider or payment source. After that, three state tracks answer different operational questions.
02 / Connect once. Use the original account#
A dispute remains bound to the processor account that handled the original payment. DEUNA does not route an existing case to an alternate processor, and checkout enablement alone does not establish dispute access.
Confirm configuration with DEUNA
Before going live, ask your Technical Account Manager to confirm the enabled environments, countries, payment products, and processor accounts. Confirm whether intake is automatic or manual, which case stages and provider actions are supported, and how provider status is refreshed. Also confirm the role model, evidence rules, external-payment support, and any remaining provider-side setup.
If the feature is not enabled, Admin displays an early-access screen with the contact path for your account.
Keep dispute operations separate from anti-fraud feedback
Dispute Management is the workspace for investigating a processor case, preparing the merchant response, submitting an available action, and following the outcome. Chargebacks upload is a separate feedback workflow that sends historical outcomes to an anti-fraud provider. A feedback file does not register a dispute, respond to a provider, or attach evidence to an active case.
Verified API surface
The dispute routes exposed through the DEUNA API Gateway require a private API key or an authorized merchant session. Public browser keys cannot call them. Use X-Idempotency-Key on side-effecting requests and discover capabilities at runtime.
| Purpose | Exposed endpoint |
|---|---|
| Discover configured accounts and readiness | GET /merchants/disputes/connections, GET /merchants/disputes/connections/{processor_account_id}, GET /merchants/disputes/capabilities |
| Register, list, and read cases | POST /merchants/disputes, GET /merchants/disputes, GET /merchants/disputes/{id} |
| Prepare the response | PATCH /merchants/disputes/{id}/draft, PATCH /merchants/disputes/{id}/metadata, GET /merchants/disputes/{id}/requirements |
| Manage evidence and information requests | /merchants/disputes/{id}/evidence and its version routes; /merchants/disputes/{id}/information-requests and its response routes |
| Review and submit | /merchants/disputes/{id}/reviews, POST /merchants/disputes/{id}/reviews/{review_id}/approve, POST /merchants/disputes/{id}/submit |
| Follow changes and attempts | GET /merchants/disputes/{id}/updates, GET /merchants/disputes/{id}/submissions, GET /merchants/disputes/{id}/submissions/{submission_id} |
See the merchant endpoint catalog for the current gateway inventory.
03 / Every step of the case, in one workspace#
Prioritize the cases that need attention
Open Operations > Disputes to compare response deadlines, disputed amounts, claim reasons, preparation state, provider state, and next actions. The queue highlights operator work, cases due within seven days, provider follow-up, and recorded outcomes. Search by order token or provider payment ID, then narrow the view by processor account, status, or creation date.
Bring the case and payment facts together
Use Register dispute when an existing provider chargeback did not enter through automated intake. Start with the provider case ID, merchant reference, original processor account, case stage, round, opening time, and response deadline. Load a DEUNA order when one exists; otherwise provide the authorized external-payment identifiers and context. Finish with the claim reason and the merchant information that DEUNA cannot verify, such as delivery, service use, accepted terms, cancellation, or customer communication.
Understand the case before taking action
The case overview keeps the claim, original and normalized reason, stage, round, disputed amount, deadline, payment, captures, refunds, order items, and next action in one place. Resolve any conflict between provider facts, payment facts, and merchant records before review or submission.
04 / Build one complete defense#
Your response is the product. Files are one way to deliver it. DEUNA combines the business facts, the current requirements, and the exact evidence versions into the representation accepted by the certified processor connection.
Prepare the response
Open Response to build the merchant position from the customer, purchase, disputed items, dated chronology, fulfillment or service use, policies, refunds, and communications. Use plain, factual language and connect every material statement to a source. DEUNA can reuse known order and payment facts, but it does not invent a narrative or treat an order record as fulfillment proof.
Match the response to the claim
Requirements change with the claim reason, processor account, payment method, country, stage, round, and action. These examples show how the content changes; the live requirements remain authoritative.
| Claim | Structured content | Possible supporting evidence |
|---|---|---|
| Product not received | Disputed items, shipping address, carrier and tracking, shipment and delivery dates, merchant explanation. | Authorized carrier record, delivery-date proof, or signed delivery confirmation. |
| Digital service not received | Service description, account reference, service period, access or usage dates, cancellation context. | Access logs, service-use records, service agreement, or relevant customer communication. |
| Credit not processed | Original payment, refund reference, amount, currency, completion state and time. | Official refund or credit confirmation. A pending refund is not a completed refund. |
| Duplicate transaction | Both transaction references, dates, amounts, separate orders or items, and the commercial difference. | Receipts or order records establishing distinct purchases. |
| Subscription canceled | Agreement, accepted policy version and time, renewal notices, and cancellation chronology. | Applicable terms, consent record, and relevant correspondence. |
| Unauthorized purchase | Available authentication results, consent facts, and permitted account, device, or session context. | Original authentication or consent records and relevant fulfillment proof; never full PAN, CVV, credentials, or secrets. |
Completeness does not establish truth or guarantee a favorable provider decision.
Keep evidence connected
Evidence is more than an uploaded filename. Each item has a category, event date, description, related order items, supported response fields, and immutable file versions. Uploading or replacing a file creates a version; it does not submit the response. The file formats and size limits for dispute evidence are summarized below.
| Evidence contract | Current DEUNA limit |
|---|---|
| Accepted base formats | PDF, JPEG, PNG, plain text, and RFC 822 email messages |
| File size | 25 MiB per file version |
| Evidence count | 50 logical evidence items per case |
| Version history | 20 immutable versions per evidence item |
A processor can impose a smaller size, count, page, format, or evidence-role limit. After upload, the version must pass validation and security checks before it becomes Ready. Only a ready, security-cleared version can enter a review.
Resolve missing information
An information request turns a missing, unreadable, or conflicting fact into a traceable task. It identifies the affected response path, evidence role, order item, requirement, assignee, and response target. A merchant response triggers revalidation; it does not automatically resolve the request, approve the case, or pause the provider deadline.
Prepare and review the exact package
A review freezes the provider action, structured response, current requirements, and exact evidence versions. The reviewer compares that locked package with the current draft. A relevant content change or a new latest evidence version makes the old approval stale; create and approve a new review before submitting.
Submit and reconcile
Submit only while the approved package is complete, current, and eligible. The selected action depends on the provider connection and case; it may defend, supplement, accept liability, or withdraw a response when supported. A queued or transmitting action proves only that DEUNA accepted the operation for processing.
If execution reaches Outcome unknown, reconcile the original attempt before trying again. A blind retry can send the same provider action twice.
05 / Follow confirmed progress#
Open Activity to see registration, provider observations, response changes, evidence completion, information requests, reviews, approvals, submission attempts, and outcomes in chronological order. Submission history retains the exact action, attempts, receipt, and execution result even when the working draft later changes.
For API integrations, GET /merchants/disputes/{id}/updates returns case changes while the submission endpoints support action reconciliation. Always retain the observation source, timestamp, and freshness. A successful upload is not provider acknowledgement, and acknowledgement is not a favorable case decision.
Status reference
| Track | State | Meaning |
|---|---|---|
| Preparation | draft, needs_information, under_review, ready, approved, submitted, completed | Describes whether the merchant response can advance. |
| Action execution | queued, transmitting, reconciling, succeeded, rejected, outcome_unknown, cancelled_before_send | Describes one provider action attempt. Uncertainty must be reconciled before retry. |
| Provider lifecycle | unknown, needs_response, under_review, won, lost, accepted, withdrawn, closed | Describes only the last verified provider state. |
A missed local deadline is an alert, not proof that the provider marked the case as lost. Likewise, accepted means confirmed merchant acceptance of liability; it does not mean the provider accepted evidence.
Return to the original payment
When a payment has related disputes, the order detail page shows each case with its disputed amount, provider state, preparation state, next action, and response deadline. Select Manage dispute to open the case or View all disputes for this order to return to the filtered queue.
06 / See the portfolio behind the queue#
Open Portfolio analytics to understand chargeback exposure and recovery for a selected period and currency. The portfolio view keeps the cohort definition explicit and does not convert amounts between currencies.
| View | What it explains |
|---|---|
| Exposure | Chargeback rate, disputed amount, and daily trends in the context of eligible processed payments. |
| Outcomes | Won, lost, and pending cases, plus win rate and confirmed recovered amount. Pending cases are excluded from win rate. |
| Breakdowns | Volume, amount, win rate, and recovery by provider, together with the mix of dispute reasons. |
Choose a 30-day or 90-day period and an available currency. Portfolio filters are independent from queue filters.
Operating principles#
Key terms#
| Term | Meaning |
|---|---|
| Claim reason | Why the issuer, network, or provider says the payment is disputed. |
| Defense reason | The merchant's permitted response position. |
| Execution error | A problem preparing or delivering an action; not a claim reason or case outcome. |
| Evidence | A versioned file connected to one or more response facts. |
| Information request | A specific question or missing requirement that needs a response or resolution. |
| Review | A frozen snapshot of the action, response, requirements, and exact evidence versions. |
| Submission | The request to execute the approved provider action. |
| Provider outcome | The authoritative decision or closure reported by the provider. |