Dispute and Arbitration System for a Marketplace

We configured a dispute system for a marketplace with 5,000 sellers and 200,000 orders per month. A buyer receives the wrong item or nothing at all — they open a dispute. The seller disagrees with the claim. A third party is needed — the platform. 1C-Bitrix has no built-in tool for disputes; this is custom development on top of the order system. Our experience shows that without arbitration automation, conflicts drag on for weeks, and trust in the platform drops. We offer a solution that includes a dispute database, status logic, SLA timers, and integration with payment systems.

Why Arbitration Is Critical for a Marketplace

Statistics: up to 15% of orders on large marketplaces trigger disputes. Without a clear system, sellers leave and buyers complain. Compare: manual dispute handling takes 3–5 days, automated takes a few minutes. In the first case, the client risks a negative review; in the second, loyalty grows. We guarantee that after setup, your managers will spend no more than 10 minutes per day on disputes.

Dispute Data Model

A dispute is linked to a sub-order. Table mp_disputes:

Dispute attachments (photos) are stored in a separate table mp_dispute_attachments with FILE_ID (via CFile). Indexes on SUB_ORDER_ID and STATUS are created for query performance.

Dispute Process

Stage 1 — Dispute Opening

The buyer opens a dispute in their personal account if the order is in delivered status and within the allowed period (e.g., 14 days from receipt). The sub-order status changes to dispute_open, and the seller's payment is frozen.

Stage 2 — Seller Response

The seller receives a notification and has 3 days to respond: agree to a return, offer a partial refund, or provide a reasoned refusal. The response is recorded in mp_dispute_messages.

Stage 3 — Arbitration

If the parties cannot agree or the seller misses the deadline, the dispute moves to arbitration. A platform manager reviews the correspondence, photos, and order data, then issues a decision (RESOLUTION).

Stage 4 — Execution of Decision

If refund — a return is initiated via the payment system API; an entry in mp_finance_log reduces the seller's balance. If reject — the seller's payment is unfrozen.

Arbitration is the final decision that both parties must comply with. Our team ensures deadlines are met and logic complies with 54-FZ.

Interfaces

• Buyer: dispute opening form, chat with seller, status tracking.
• Seller: notification of new dispute, response form with attachment capability, result of decision.
• Admin: list of open disputes with SLA timer (time left until deadline), detailed view of correspondence, decision form.

Dispute correspondence is stored in mp_dispute_messages with fields DISPUTE_ID, SENDER_TYPE (buyer/seller/admin), TEXT, CREATED_AT. Interface updates are done via polling or WebSocket.

What’s Included in the Dispute System Setup

• Development of a dispute module with entities Dispute, DisputeMessage, DisputeAttachment
• Integration with payment gateway for freezing/refunding funds
• Configuration of SLA timers and automatic notifications
• Development of interfaces for buyer, seller, and administrator
• Documentation and staff training

We are certified 1C-Bitrix developers with 8 years of experience, having implemented over 50 projects for marketplaces. We provide a contractual guarantee.

How to Automate Arbitration

Arbitration automation relies on SLA timers and business processes. If the seller does not respond within 3 days, the system automatically escalates the dispute to arbitration and notifies the administrator. When a dispute is resolved, the order status and payment freeze are updated automatically. This reduces managers' time by up to 70% compared to manual mode.

Timelines and Cost

Base system (data model, stages, interfaces) — 2–3 weeks. Automation of overdue responses and integration with fiscal data operators — another 1–2 weeks. Cost is calculated individually based on integration complexity. We will assess your project for free.

If you want to implement a reliable dispute and arbitration system, get a consultation on the project. Contact us — we'll discuss the details.

Marketplace Development on 1C-Bitrix: Overcoming Standard Architecture Limitations

The b_sale_order table and related b_sale_basket are not designed for multivendor out of the box. Bitrix has no built-in 'marketplace' module — each time it's custom development on top of the sale module. The standard sale module cannot split orders by different suppliers: if the cart contains items from three sellers, Bitrix creates a single order with one number, status, and total. It's impossible to send each sub-order to a separate dashboard, calculate commissions for each seller, or allow partial shipment. We have to redefine the entire logic: from cart to status model. Additionally, the standard search (Sphinx) and caching are not optimized for a multivendor catalog — with 100,000 items from 500 suppliers, filters by supplier lead to performance degradation (queries with WHERE on IBLOCK_ELEMENT_PROPERTY become 5–10 times slower). We write a separate module that extends the standard cart: adds item-to-supplier binding via order property, splits a single order into sub-orders by seller, and routes each separately.

Why Standard Solutions Are Not Suitable for Multivendor Platforms?

Marketplace Models

Classic marketplace — the operator does not hold inventory. All product logic lies with sellers, the platform handles traffic and payment gateway. Technically, this is a separate supplier infoblock linked via UF_VENDOR_ID in the highload catalog infoblock.

Hybrid model — the operator sells alongside external suppliers. The main pain: ranking in the catalog. If suppliers see that the platform's own listings always rank higher, they leave. We solve this with a separate sorting component where position is determined by rating, shipping speed, and price, without privileges for 'own' items.

Service marketplace — requests, tenders, escrow. Here, instead of b_sale_basket, a custom request entity works with a workflow via Bitrix business processes.

B2B marketplace — contracts, reconciliation statements, credit lines, EDI. Authorization by TIN, multi-price groups via b_catalog_group, shipping limits.

What Technical Problems Does Marketplace Development on 1C-Bitrix Solve?

Monetization Models

What Does the Seller Dashboard Include?

The dashboard is the heart of a marketplace. An inconvenient dashboard = empty platform. No standard solution exists; we build from scratch using Bitrix components.

• Catalog management — CRUD for products via custom component, bulk CSV/XML upload via CIBlockXMLFile. Nobody manually enters 10,000 SKUs, so import is the first thing we do.
• Order processing — sub-orders land in the dashboard via ajax-polling or websocket. Confirmation, invoice printing via CSalePdf, status update with back-sync to the main order.
• Financial analytics — dashboard on highload infoblock of aggregated data. Revenue, commissions, payouts — details by product and period. The seller sees what sells and what just occupies the showcase.
• Delivery settings — seller's own tariffs, binding to sale.delivery.handler.
• Communication — built-in chat without revealing contacts. Implemented via im module or custom message table.
• Promotions — discounts, promo codes via b_sale_discount with filter by vendor_id.

Moderation and Quality Control

One batch of counterfeit goods kills the platform's reputation. Therefore, moderation is mandatory.

• Product moderation — status ACTIVE='N' until verification. Auto-moderation filters obvious violations (banned words, missing photos), manual moderation handles disputes. Handler OnBeforeIBlockElementUpdate prevents bypass.
• Seller verification — TIN check via Federal Tax Service API, document scans upload. Statuses: new → verified → premium. Each level unlocks limits on product count and commissions.
• Rating system — not just stars. The algorithm considers shipping speed (AVG(ship_date - order_date)), return rate, and answer quality.
• Anti-fraud — detect rating manipulation by patterns (same IP, identical texts, abnormal frequency). Duplicate accounts caught by TIN and bank details.
• Typical mistake: storing supplier data in a regular infoblock — with 1000+ sellers, queries become slow. Use highload infoblocks.

How Is the Seller Payout System Structured?

The financial module is why sellers join the platform.

• Commission calculation — handler on order status change. Commission depends on category, seller status, current conditions. Stored in a separate table vendor_transactions.
• Periodic payouts — cron task generates a register: weekly, bi-monthly, or monthly. Minimum payout amount, holding until confirmation.
• Acts and reports — PDF generation via PhpOffice\PhpSpreadsheet, automatic numbering, one-click download.
• Holding — funds held until product received. Reduces disputes and returns.
• Payouts via banking API — YooKassa, CloudPayments, direct banking APIs. Seller receives money without calls or reminders.
• Important: splitting orders at the OnSaleOrderSaved handler leads to status mismatch. Split at the cart stage.
• Manual fiscalization of each sub-order violates 54-FZ. Use a single receipt with 'agent' attribute. On one project, fiscalization automation saved significant monthly costs. On another, search optimization via Elasticsearch reduced catalog loading time by 80% (from 3 seconds to 0.6 seconds).

How We Build Marketplace Architecture

1. Define business model — choose marketplace type and monetization scheme.
2. Database design — highload infoblocks for catalogs over 50,000 SKU, separate tables for sub-orders (orders_split) and transactions.
3. Core development — create module marketplace.vendor, implement product-to-supplier binding, order splitting mechanism, agents for commission calculation.
4. Payment gateway and 54-FZ integration — configure fiscalization via ATOL Online or CloudPayments.
5. Load testing — use k6 or ab to verify 5000 orders per day.

Typical Mistakes in Bitrix Marketplace Development

• Storing suppliers in a regular infoblock — causes slowdowns with >1000 records. Use highload infoblocks.
• Splitting orders after saving — breaks the status model. Split at the cart stage.
• Manual fiscalization of each sub-order — violates 54-FZ. Fiscalize with a single receipt with agent attribute.
• Ignoring tagged caching for the catalog — with multivendor, cache is invalidated entirely. Configure tags by vendor_id.

Technology Stack

• 1C-Bitrix 'Business' or 'Enterprise' — sale + catalog modules as foundation. Multivendor wrapper — custom modules.
• Highload infoblocks — catalogs over 100,000 SKU. Regular infoblocks at such volumes fail on filtering: CIBlockElement::GetList with a dozen properties generates JOINs on dozens of b_iblock_element_prop_sNN tables. Highload solves this with a flat structure.
• Elasticsearch — full-text search. Elasticsearch processes queries 10 times faster than the built-in search module (Sphinx). User types 'nike sneakers' — finds 'Nike sneakers'.
• Queues — catalog import, payout calculation, report generation. Bitrix agents (CAgent) for light tasks, separate queue via RabbitMQ or supervisor + custom CLI for heavy tasks.

We guarantee that the developed module will handle a load of up to 5000 orders per day on a standard VPS. Certified 1C-Bitrix specialists (over 10 years of experience, 50+ completed projects) perform architecture audit before development starts. At a scale of 2000 sellers, average moderation time is 15 minutes, and 95% of orders are processed automatically.

Industry Marketplaces

Each niche has its own pitfalls:

• Building materials — oversized delivery calculation. Pallets, tonnage, floor lift. Standard delivery calculator cannot handle it; we write custom sale.delivery.handler.
• Food products — expiration dates in infoblock properties, temperature regime, same-day delivery slots. A logistics error means write-off.
• Auto parts — VIN selection via Laximo API, cross-references, originals and analogs. A separate headache is different delivery times from different sellers for the same part.
• Clothing — size charts (EU/US/RU), high return rate. Return processing logic with commission redistribution is a whole layer.
• Industrial equipment — B2B with tenders, quotation requests. Product card with 50+ parameters in table form.

Timelines and Stages

Trying to launch everything at once is a sure way to launch nothing.

MVP in 3-4 months. Full-featured platform — 6-12 months of iterative development.

What Is Included

• Documentation: architecture diagram, API description, seller instructions.
• Access: code repository, test environment, admin panel.
• Training: two sessions for administrators and managers.
• Support: 1 month free support after launch, then according to SLA.
• Warranty on developed modules — 12 months.

Contact us for an assessment of your project — we will calculate timelines and cost individually. Request a consultation, and we will show on a real case how we solve the multivendor problem in 30 minutes. Get a detailed development plan for your marketplace today.