Marketplace Development Services on 1C-Bitrix

Marketplace Development on 1C-Bitrix

Let's start with what breaks most projects: the b_sale_order table and its related b_sale_basket were not designed for multi-vendor functionality out of the box. Bitrix has no built-in "marketplace" module — every time it's custom development on top of the sale module. We build a separate module that extends the standard cart: it adds product-to-vendor binding via an order property, splits a single order into sub-orders by seller, and routes each one independently.

Marketplace Models

Classic marketplace — the operator holds no inventory. All product logic rests with the sellers; the platform handles traffic and the payment gateway. Technically, this is a separate vendor infoblock linked through UF_VENDOR_ID in a highload infoblock catalog.

Hybrid model — the operator sells alongside external vendors. The main pain point: catalog ranking. If vendors see that the platform's own product cards always rank higher — they leave. We solve this with a dedicated sorting component where position is determined by rating, shipping speed, and price, with no privileges for "in-house" listings.

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

B2B marketplace — contracts, reconciliation reports, credit lines, EDI. A completely different world: authorization by tax ID, multi-price groups via b_catalog_group, shipment limits.

Monetization Models

Seller Dashboard

The dashboard is the heart of a marketplace. An inconvenient dashboard means an empty platform. There's no out-of-the-box solution, so we build it from scratch using Bitrix components.

• Catalog management — product CRUD via a custom component, bulk CSV/XML upload through CIBlockXMLFile. Nobody is going to manually enter 10,000 SKUs, so import is the first thing we build.
• Order processing — sub-orders land in the dashboard via ajax polling or websocket. Confirmation, invoice printing via CSalePdf, status updates with reverse sync to the main order.
• Financial analytics — a dashboard built on a highload infoblock of aggregated data. Revenue, commissions, payouts — broken down by product and time period. The seller sees what's selling and what's just taking up shelf space.
• Shipping settings — the seller's own rates, linked to sale.delivery.handler.
• Communication — built-in chat without exposing contact details. Implemented via the im module or a custom messages table.
• Promotions — discounts, promo codes via b_sale_discount filtered by vendor_id.

Moderation and Quality Control

A single batch of counterfeit goods destroys a platform's reputation. That's why moderation isn't "nice to have" — it's a mandatory layer.

• Product moderation — status ACTIVE='N' until review is passed. Auto-moderation filters the obvious (prohibited words, missing photos); manual review handles edge cases. The OnBeforeIBlockElementUpdate handler prevents bypass.
• Seller verification — tax ID verification via the Federal Tax Service API, document scan uploads. Statuses: new → verified → premium. Each level unlocks limits on product count and commission rates.
• Rating system — not just stars. The algorithm factors in shipping speed (AVG(ship_date - order_date)), return rate, and response quality.
• Anti-fraud — we detect rating manipulation by patterns (same IP, identical texts, abnormal frequency). Duplicate accounts are caught by tax ID and bank details.

Seller Payout System

The financial module is what brings sellers to the platform.

• Commission calculation — a handler on order status change. Commission depends on category, seller status, and current terms. Stored in a separate vendor_transactions table.
• Periodic payouts — a cron job generates a register: weekly, bi-monthly, or monthly. Minimum payout amount, hold until delivery confirmation.
• Reports and documentation — PDF report generation via PhpOffice\PhpSpreadsheet, automatic numbering, one-click download.
• Hold period — funds are held until the OnSaleStatusOrder event with "Received" status. Reduces disputes and returns.
• Payouts via banking APIs — YooKassa, CloudPayments, direct bank APIs. The seller receives funds without calls or reminders.

Technology Stack

• 1C-Bitrix "Business" or "Enterprise" — sale + catalog modules as the foundation. Multi-vendor layer — custom modules.
• Highload infoblocks — catalogs with over 100,000 SKUs. Standard infoblocks at these volumes choke on filtering: CIBlockElement::GetList with a dozen properties starts generating JOINs across dozens of b_iblock_element_prop_sNN tables. Highload solves this with a flat structure.
• Elasticsearch — full-text search. A user types "nike sneakers" — finds "Nike running shoes." The built-in Bitrix search is unacceptably slow on large catalogs.
• Queues — catalog imports, payout calculations, report generation. Bitrix agents (CAgent) for lightweight tasks, a separate queue via RabbitMQ or supervisor + custom CLI for heavy ones.

Industry-Specific Marketplaces

Each niche has its own pitfalls:

• Building materials — oversized delivery calculations. Pallets, tonnage, floor delivery. A standard shipping calculator doesn't cut it — we build a custom sale.delivery.handler.
• Food products — expiration dates in infoblock properties, temperature requirements, same-day delivery slots. A logistics mistake means write-offs.
• Auto parts — VIN lookup via the laximo API, cross-references, OEM and aftermarket parts. A separate headache: different delivery times from different sellers for the same part.
• Apparel — size charts (EU/US/RU), high return rates. Return processing logic with commission redistribution is a whole separate layer.
• Industrial equipment — B2B with tenders and quote requests. Product cards with 50+ parameters in a tabular format.

Timeline and Phases

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

1. Business model (2-3 weeks) — monetization model, MVP scope. We cut 80% of the wish list that isn't needed at launch.
2. Design (3-4 weeks) — UX, storefront and dashboard prototypes, database architecture.
3. MVP (2-3 months) — catalog, seller registration, orders, basic moderation. First real sales.
4. Pilot (2-3 weeks) — first sellers, test purchases, load testing with ab or k6.
5. Scaling (ongoing) — new features based on feedback, query optimization, horizontal scaling.

MVP in 3-4 months. A fully functional platform — 6-12 months of iterative development.