Refunds & Disputes

Who can open

Buyers and sellers can each open a dispute on any order they are a party to. Admins can open on behalf of either side when needed. Buyers whose accounts are under review for other reasons are blocked from opening until the review clears.

Order-state requirements

The order must be in state WAITING or COMPLETED. Refunded, cancelled, or already-disputed orders cannot open a new dispute. Only one dispute exists per order for its lifetime, and a repeat open call is rejected.

Time windows

Two timers gate when the dispute action is available on an order.

• For the first 15 minutes after payment confirms, the dispute button is locked. This short pause gives the seller a chance to deliver before a claim can open.
• After an order is marked completed, you have 10 days to open a dispute. Past that window, the completion is treated as final.

igPlus members bypass the 15-minute post-purchase lock.

Message and reason requirements

The opening message must be at least 30 characters and carry a canonical reason.

• Minimum message length is 30 characters. Empty or one-liner opens are rejected before the dispute is created.
• The reason is stored as one of five canonical values: item_not_received, item_not_as_described, buyer_not_responding, buyer_requested_cancellation, or other. Free-text explanations from API or legacy clients are normalized into one of these buckets.
• The opening message is posted to the shared thread with a system-generated prefix that names the reason and attributes the wording to Buyer, Seller, or Staff. Users cannot spoof a platform-authored announcement inside their own opening message.

Side effects at open

• Any active refund request on the order is auto-declined the moment the dispute opens. The dispute is the newer, more authoritative claim.
• A shared chat thread is created and scoped to the dispute id. Both parties and the platform system speaker share the thread.
• The counterparty is notified through in-app notifications, email (when opted in), and any registered seller webhook.

States

• DISPUTED. Peer phase. Buyer and seller can settle directly, and the dispute opener can self-close.
• WAITING_FOR_REPLY. With igitems staff. Entered on escalation, on the Kinguin auto-escalate path, on chargeback creation, or by any of the automatic sweeps described below.
• ANSWERED. Staff has replied and the user's response is due. If the user does not reply, the case moves back to WAITING_FOR_REPLY.
• CLOSED. Terminal. Carries an optional decision (RESOLVED_IN_DISPUTE, BUYER_WINS, SELLER_WINS, or CUSTOM) and an optional 1 to 5 rating.
• PERMA_CLOSED. Terminal and cannot be reopened by any code path.

※A legacy NEW state exists in the schema but is not entered by any current path. Only historical rows carry it.

Automatic transitions

The scheduled dispute-state job moves cases through these transitions on its own. Each row lists the trigger and the exact timer that governs it.

1. 1
   Open

   A new dispute enters DISPUTED. On Kinguin key orders and on bank chargebacks, it enters WAITING_FOR_REPLY directly instead.

2. 2
   User escalate

   Buyers can escalate manually after 24 hours in DISPUTED. Sellers, admins, moderators, and igPlus members can escalate at any time from DISPUTED. This 24-hour buyer wait is a dashboard gate, not a server-enforced cooldown.

3. 3
   Age sweep

   Any dispute that stays in DISPUTED for more than 10 days is auto-escalated to WAITING_FOR_REPLY.

4. 4
   Seller silence

   If the seller has never posted a message in the dispute chat and the dispute is more than 24 hours old, the case auto-escalates to WAITING_FOR_REPLY.

5. 5
   Inactivity

   If either party stays silent for more than 3 days at any point, the case auto-escalates to WAITING_FOR_REPLY.

6. 6
   Answered timeout

   A case sitting in ANSWERED for 24 hours moves back to WAITING_FOR_REPLY so it re-enters the staff queue.

7. 7
   Assignment reset

   In WAITING_FOR_REPLY, the assigned agent is auto-cleared after 36 hours so the case returns to the general queue.

Terminal decisions

A closed dispute carries at most one decision. These are the five outcomes staff or the system can record.

• RESOLVED_IN_DISPUTE. Cooperative close. The dispute opener chose to end it, or a seller-issued full refund closed it without escalation.
• BUYER_WINS. Full refund executed, or a bank chargeback was lost.
• SELLER_WINS. A bank chargeback was won or the bank warned and closed the case.
• CUSTOM. Bespoke ruling by an igitems agent. Used when the standard three outcomes do not fit.
• Silent close. The case closes without a decision written. An optional action reason and a 1 to 5 rating may still be recorded.

Blocking conditions

• Close is blocked while any linked refund request is in PENDING or ACTION_NEEDED. The refund must resolve first.
• Escalate is blocked when the dispute is not in DISPUTED. Once a case has left the peer phase it cannot be user-escalated again.
• Terminal states cannot be reopened. Only an admin unescalate can move a case back from WAITING_FOR_REPLY or ANSWERED into DISPUTED.

Mid-dispute refund offer

The seller can file a refund request while the dispute is still in the peer phase. The request routes to PENDING_BUYER_CHOICE, where the buyer picks between wallet credit and a refund to the original payment method before it executes.

Manual escalation

Manual escalation is available only from DISPUTED. Buyers see the escalate button unlocked once 24 hours have passed since the dispute opened. That wait is enforced by the dashboard, not by the server.

Sellers, admins, moderators, and igPlus members can escalate from DISPUTED at any time. There is no buyer-side bypass unless the account carries igPlus.

On escalation, the dispute state moves to WAITING_FOR_REPLY, the wasEscalated flag is set, and any live refund request on the order is auto-declined so the escalation supersedes it.

Automatic escalation triggers

The scheduled job that watches active disputes escalates cases when any of these conditions apply.

1. 1
   Age

   In DISPUTED for more than 10 days.

2. 2
   Seller silence

   The seller has posted no messages and the dispute is more than 24 hours old.

3. 3
   Inactivity

   Either party has stayed silent for more than 3 days.

4. 4
   Answered timeout

   The case has sat in ANSWERED for 24 hours after a staff reply.

5. 5
   Kinguin

   Disputes on Kinguin key orders skip DISPUTED entirely and enter WAITING_FOR_REPLY at open.

6. 6
   Chargeback

   A bank chargeback creates the dispute already in WAITING_FOR_REPLY with the chargeback and wasEscalated flags set.

After escalation

Once in WAITING_FOR_REPLY, the case is assigned to an igitems agent. If the agent does not act within 36 hours, the assignment clears and the case returns to the general queue. When the agent replies, the state moves to ANSWERED and the user has 24 hours before it queues back. Admins can also unescalate a case back to DISPUTED in the rare situations where returning it to the peer phase is the right call.

FX anchoring

Refund accounting is anchored in USD. The rate is derived from the payment record rather than pulled fresh at refund time, so the amount you receive is not exposed to intra-window rate drift.

Full vs partial refund detection

The refund is full when the cumulative refunded amount plus any buyer-borne transaction fee reaches the original order total, allowing a 1-cent tolerance for rounding. Anything below the threshold is a partial.

Partial refund dynamic scaling

On a partial refund, the order's price fields are rescaled in a single atomic Mongo aggregation-pipeline update. The multiplier is the ratio of remaining principal after the refund to remaining principal before it. The scaled fields are originalPrice, price, and igCoins.

Consecutive partial refunds compose. After the n-th partial, originalPrice equals the original value times (remaining_n / tx_total).

Two targets

WALLET credits the buyer's igitems balance instantly and is reversible internally. PROVIDER routes the refund through the original payment gateway on standard settlement windows. Orders that were paid from wallet in the first place always route back to WALLET, because sending them to a provider would be circular.

Buyer choice window

When the buyer is asked to pick a target, the choice window is 120 hours (5 days). Past that window, a scheduled job applies a default: WALLET on igitems-native orders, PROVIDER on BoostRoyal-routed orders. The BoostRoyal default protects the real buyer on the partner side from an unexpected igitems wallet credit they did not ask for.

Provider-target review gate

Provider refunds above $500, or any provider refund on an order that has already been paid out to the seller, require admin review before they execute. This prevents an automated buyer-pick from moving significant money out of the platform without a second pair of eyes.

Wallet credit is gross USD

When you take a refund as wallet credit, the balance is topped up with the gross USD amount originally received on the order, not the amount net of payment processor fees. You do not silently absorb the gateway cost a second time.

※The platform recoups its gateway fee separately, through the service fee charged on the replacement order you eventually spend the balance on. The offset lives on that new order, not on the wallet credit itself.

Cashback claw-back on refund

Any cashback previously credited on the order is proportionally reverted at refund time. The revert scales with the fraction of the order being refunded. It is a fairness mechanism, not a penalty. The buyer keeps cashback earned on the portion of the order they retain.

Evidence types accepted

In-platform artifacts are the primary evidence: order chat messages, dispute chat messages, delivery proofs (screenshots and identifiers) posted to those threads, and the external reference on refund requests (transaction ids, ticket numbers, or URLs). Everything staff considers must live somewhere on the platform.

Evidence explicitly ignored

Off-platform communications are not acknowledged. Screenshots of external chats, forum posts, or emails to your personal address are not evidence for the case. Harassment, personal attacks, and knowingly false claims made inside the dispute chat are also disregarded and can attract account-level consequences.

Terminal outcomes

One of the five outcomes below closes the case. Staff also pick the order-state the case returns to on close.

• RESOLVED_IN_DISPUTE. Peer-side settlement, no staff ruling required.
• BUYER_WINS. Full refund goes to the buyer.
• SELLER_WINS. Seller keeps the funds.
• CUSTOM. Non-standard ruling written by staff.
• Silent close. Closed with no decision on file.

On close, staff pick whether the order returns to WAITING (default, the natural lifecycle resumes) or COMPLETED (the completion effects fire: cashback grants, paid-orders count, and any related downstream hooks).

Chargebacks

A bank chargeback is a buyer-initiated claim filed through their card issuer or bank. When the gateway forwards it to igitems, the platform auto-opens a dispute in WAITING_FOR_REPLY with the chargeback and wasEscalated flags set, freezes the funds, and files a response with the bank on the seller's behalf using in-platform evidence.

If the bank rules in the seller's favor, the case closes as SELLER_WINS and the order returns to its pre-chargeback state. If the bank rules against the seller, the case closes as BUYER_WINS and the refund is issued. Buyers who file chargebacks after receiving the item or after a refund face permanent account action.