Dispute management basics

How IVOTIA dispute requests work after they are opened, what the current request types and statuses mean, and when a case moves from a user-to-user resolution request into support escalation.

Updated: 2026-06-05

What the Resolution Center is for

IVOTIA’s Resolution Center is where buyers and sellers handle order problems that cannot be solved through normal fulfilment alone.

On the current product, the page can show both the newer cancellation and extension request controls and the older structured dispute request system. The dispute-management article is about that structured dispute path after a case is created.

If the normal cancellation options do not solve the issue, the page lets the user move into a formal dispute-style request so the order state and requested remedy are recorded clearly.

When a dispute request can be opened

A dispute request can only be opened by someone who is actually part of the order. IVOTIA checks that the current user is either the buyer or the seller tied to that order.

Only one active `OPEN` dispute request is allowed for the same order at a time. If an open request already exists, IVOTIA rejects any attempt to start a second one until the first request is resolved, rejected, or escalated out of the open state.

Opening a dispute also requires the order to be in a status that can legally move into `DISPUTED` in IVOTIA’s order state machine.

The request types currently available

The current Resolution Center shows different request types depending on the user’s role in the order.

Buyers can currently open `CANCEL` and `REFUND` requests in the old dispute system. Sellers can currently open `CANCEL`, `EXTEND`, `REFUND`, and `MODIFY` requests.

In the UI, these appear with plain-language labels such as `Order Cancelation`, `Extend Delivery`, `Partial Refund`, and `Modify Order Scope`.

What happens when a dispute is opened

When a dispute request is created, IVOTIA records the request with its type, reason, and any optional requested amount or requested days.

At the same time, the order’s escrow status moves into `DISPUTED`, the `disputedAt` timestamp is stored, and any automatic release timer is cleared. That matters because payout should not continue normally while the issue is under review.

From that point on, the dispute becomes part of the order record, and both parties can view the request history from the Resolution Center.

How the other party responds

The other party on the order can respond to an open request by accepting or rejecting it. The person who opened the request cannot respond to their own dispute.

If the request is rejected, the dispute record moves to `REJECTED` and the order does not automatically take the requested change.

If the request is accepted, IVOTIA marks the dispute `RESOLVED` and then applies the matching order change based on the request type.

What acceptance means for each request type

A `CANCEL` acceptance refunds the buyer side and moves the order into a refunded state. IVOTIA also creates the corresponding escrow ledger refund record.

An `EXTEND` acceptance adds the requested number of days to the estimated delivery date when a date exists, then clears the dispute lock so the order can continue in a held state.

A `REFUND` acceptance is treated as a partial-refund style adjustment in the current implementation. The order returns to a completed-style state and the seller payout amount is reduced by the requested amount when one was supplied.

A `MODIFY` acceptance increases the order gross amount in the current implementation and clears the dispute lock. The code itself notes that a real production-grade buyer recharge step would still be needed for that path.

Statuses you will see in dispute history

The current dispute history on the page shows statuses such as `OPEN`, `RESOLVED`, `REJECTED`, and `ESCALATED`.

An `OPEN` request still needs a response or escalation. `RESOLVED` means the request was accepted and the matching order update was applied. `REJECTED` means the other side declined the request. `ESCALATED` means the issue was pushed to support review.

The Resolution Center also keeps older entries in the history list so users can review what was requested, when it was created, and what final status it reached.

When to escalate to support

If the other side will not cooperate, the issue is too serious for a direct accept-or-reject outcome, or the dispute needs platform intervention, the dispute can be escalated to support.

Escalation changes the dispute status to `ESCALATED` so the case is no longer just a simple open request between the two parties.

At that point, support may need the same core evidence as any other serious case: order identifiers, timeline, chat context, delivery facts, and a clear explanation of what outcome you believe is correct.

Important things to know

A dispute request is not just a message. It changes the protected order state by moving the order into `DISPUTED` and freezing auto-release behavior.

Only one open dispute request is allowed per order at a time, so make the request type and reason count.

If you are not sure whether to use a cancellation option, a dispute request, or general support, start with the most structured path available on the order page and escalate only when the normal resolution flow is no longer enough.

Was this article helpful?

Related articles