Dispute and Arbitration System Setup for 1C-Bitrix Marketplace
A buyer received the wrong item or didn't receive anything — opens a dispute. Seller disagrees with the claim. A third party is needed — the platform. 1C-Bitrix has no ready-made dispute tool; this is custom development on top of the order system.
Dispute Data Model
Dispute is linked to sub-order. Table mp_disputes:
| Field | Type | Description |
|---|---|---|
| ID | int, AI | |
| SUB_ORDER_ID | int | FK to sub-order |
| INITIATOR_ID | int | Buyer's USER_ID |
| VENDOR_ID | int | FK to seller |
| REASON | varchar | not_received / wrong_item / damaged / other |
| DESCRIPTION | text | Problem description |
| STATUS | varchar | open / seller_response / arbitrage / resolved / closed |
| RESOLUTION | varchar | refund / partial_refund / reject / exchange |
| ADMIN_USER_ID | int | Manager-arbiter |
| CREATED_AT | datetime | |
| RESOLVED_AT | datetime |
Dispute attachments (photos) — separate table mp_dispute_attachments with FILE_ID (via CFile).
Dispute Process
Stage 1 — Opening dispute. Buyer opens dispute through personal account if order is in delivered status and deadline hasn't passed (e.g., 14 days from receipt). Sub-order status changes to dispute_open, seller's payout is frozen.
Stage 2 — Seller response. Seller receives notification, must respond within N days (e.g., 3): agree to refund, offer partial refund, or argue refusal. Response is recorded in mp_dispute_messages table.
Stage 3 — Arbitration. If sides don't agree or seller doesn't respond in time — dispute escalates to arbitration. Platform manager reviews correspondence, photos, order data. Makes decision (RESOLUTION).
Stage 4 — Decision execution. On refund — initiate refund to buyer via payment system API, entry in mp_finance_log decreases seller balance. On reject — seller's payout is unlocked.
Interfaces
Buyer: dispute opening form, chat with seller, review status.
Seller: notification of new dispute, response form with ability to attach documents, decision result.
Administrator: list of open disputes with SLA timer (time remaining before overdue), detailed conversation view, decision-making form.
Dispute correspondence — separate table mp_dispute_messages with fields DISPUTE_ID, SENDER_TYPE (buyer/seller/admin), TEXT, CREATED_AT. Interface updates — via polling or WebSocket.
Timeline
Basic dispute system (opening, seller response, admin decision) — 2–3 weeks. Automating overdue responses and decision execution — additional 1 week.