Marketplace Development on 1C-Bitrix
The company wants to launch a marketplace. It seems simple: take an online shop on 1C-Bitrix, add a few sellers—done. In practice, an online shop and a marketplace are two fundamentally different architectures. A shop has one seller, one warehouse, one bank account. A marketplace has dozens and hundreds of sellers, each with their own goods, their own inventory, their own shipping conditions, and their own share of the sale. Trying to force one onto the other ends with hacks that fall apart when scaling.
Developing a marketplace on 1C-Bitrix is designing a multi-vendor platform from scratch: seller architecture, product moderation, payment splitting, order routing, and commission model.
Multi-vendor Architecture
The key difference between a marketplace and a shop is multiple sellers on one platform. Architecturally this requires:
- Seller entity — separate table (or highload block) with data: legal entity, details, contact person, rating, moderation status, commission percentage.
-
Product binding to seller — each product in catalog belongs to specific seller. Property
VENDOR_IDin product infoblock. - Data isolation — seller sees only their goods, orders, and statistics. Access limited at API and interface level.
- Unified catalog — buyer sees products from all sellers on one platform. Filtering, sorting, search work across entire catalog, but each product shows its seller.
1C-Bitrix has no built-in marketplace module. Multi-vendor logic is realized through custom modules, event handlers, and extending standard entities.
Seller Cabinet
Seller works in separate site section—no access to 1C-Bitrix admin panel. Cabinet functionality:
Product management:
- Add, edit, delete products.
- Photo upload with automatic resize and watermarks.
- Manage variants (size, color, specifications).
- Mass import from CSV/Excel.
- Manage inventory and prices.
- Publishing after passing moderation.
Order management:
- List of orders with seller's products (multi-vendor order is split to show specific seller items).
- Change status: confirmed → packed → shipped → delivered.
- Print invoices and labels.
- Process returns.
Finance:
- Balance: earned, paid out, withheld (commission).
- Transaction history.
- Acts and reports per period.
- Request funds withdrawal.
Analytics:
- Sales per period: amount, number of orders, average check.
- Top products.
- Product card conversion.
- Seller rating and customer reviews.
Product Moderation
Without moderation, marketplace quickly becomes a dump: duplicates, poor photos, prohibited goods, incorrect descriptions. Moderation system:
- Automatic check — when product is added, script verifies: required fields filled, category matches, photo format acceptable, no prohibited words in description.
- Manual moderation — moderator in admin panel reviews new products, approves or rejects with comment.
- Moderation statuses — draft → on moderation → approved → rejected → needs revision.
- Mass moderation — for experienced sellers with high rating, auto-approval can be enabled.
Moderation is realized via 1C-Bitrix business processes or custom workflow.
Commission Model
Marketplace earns on commission from sales. Models:
| Model | Description | When to use |
|---|---|---|
| Fixed % | Uniform percentage on all sales | Simple marketplace, one category |
| By category | Different % for different product categories | Multi-category marketplace |
| By seller | Individual % for each seller | Large anchor sellers with special terms |
| Tariff plans | Subscription fee + reduced commission | High-volume sellers |
| Combined | Subscription + % by category | Mature marketplace |
Technically: when order is created, system calculates each seller's share and platform commission. Data written to separate financial transactions table.
Payment Splitting (Split Payment)
Customer pays for one order. But money must be split between sellers and platform. Options:
Option 1: Platform as agent. Money arrives to platform's account. Platform withholds commission and transfers remainder to sellers. Requires agent agreement with each seller.
Option 2: Split payments via payment provider. Services YooKassa, CloudPayments, АТОЛ Онлайн support marketplace split: at payment, recipients and amounts are specified. Money distributes automatically.
Option 3: Escrow / holding account. Money freezes until delivery confirmed. After confirmation—distributes. Protects buyer.
For 1C-Bitrix, split-payment integration is realized via custom payment system handler. Standard handlers don't support splitting—needs development.
Order Routing
Customer adds items from three different sellers to cart. At checkout:
- Cart splits into sub-orders — by seller. Each has own shipping terms, timeframes, warehouse.
- For each sub-order shipping cost is calculated—from seller's warehouse to buyer.
- Buyer sees total cost with breakdown by seller (or unified if marketplace consolidates shipping).
- After payment each seller gets notification of their order part.
- Statuses update independently: seller A shipped, seller B still packing.
In 1C-Bitrix this is realized via shipment mechanism (\Bitrix\Sale\Shipment)—each seller forms their shipment within one order.
Shipping
Marketplace can operate on different shipping models:
- Seller ships themselves — each seller sets own shipping methods and rates.
- Unified platform logistics — marketplace picks from sellers and delivers (FBO model like Ozon/Wildberries).
- Hybrid model — seller chooses: ship self or via platform.
For each model—different shipping cost calculation. Integration with transport companies (CDEK, Boxberry, Russian Post) via API.
Rating and Reviews
Customer trust in marketplace is built on seller reputation:
- Seller rating — average score per order. Considers: product quality, shipping speed, description match.
- Product reviews — linked to product and seller. Moderation: automatic (profanity, spam filter) + manual.
- Penalty system — late shipping, high return rate, customer complaints. Auto rating drop or account block.
Catalog and Search
Unified catalog with products from all sellers requires:
- Unified category structure — seller picks category from platform tree, doesn't create own.
- Uniform characteristics — each category has defined set of required properties (size, material, brand). Seller fills by template.
- Deduplication — if multiple sellers sell same product, buyer sees one card with offers from different sellers (offer model).
- Faceted search — filtering by properties, price, seller, rating, availability.
- Full-text search — via Sphinx or Elasticsearch. Standard 1C-Bitrix search can't handle 100 000+ items.
Financial Reports and Payouts
Platform must maintain financial accounting for each seller:
- Sales register — per period: product, quantity, amount, commission, net to seller.
- Service performed act — platform provides service to seller (placement, advertising) and withholds commission.
- Payment schedule — weekly, biweekly, monthly. Configurable per seller.
- Minimum payout — don't pay until minimum accumulated.
- Deductions — fines, returns, buyer compensation.
Automatic report and act generation for accounting—via integration with 1C:Accounting or document management module.
Technical Requirements
Marketplace is high-load project. Technical solutions:
- 1C-Bitrix edition — "Business" or "Enterprise". Lower editions don't support needed modules.
- Server infrastructure — dedicated server or cloud. For 50 000+ items catalog—SSD, minimum 16 GB RAM, separate MySQL/PostgreSQL server.
- Caching — 1C-Bitrix composite cache + Memcached/Redis for sessions and data.
- CDN — product photos served via CDN (Cloudflare, AWS CloudFront).
- Task queues — background operations (product import, rating recalculation, report generation) via queues (cron-agents or RabbitMQ).
- Monitoring — track response time, errors, database load.
Security
- Data isolation — at SQL query level. Seller can't get other seller's data even via API.
- Seller verification — check legal entity (TIN, OGRN), confirm contact data, sign offer.
- Buyer protection — return guarantee, escrow payments, review moderation.
- PCI DSS — if payments flow through platform (split-payment providers handle PCI DSS requirements).
- Fraud protection — monitor suspicious orders, limit withdrawals for new sellers.
Development Stages
| Stage | What we do | Result |
|---|---|---|
| Analysis | Describe business model, roles, scenarios | Technical specification |
| Design | DB architecture, API, interfaces | Project documentation |
| Framework | Basic catalog, seller registration, cabinet | MVP |
| Payments and commissions | Split payment, commission model, payouts | Finance module |
| Orders and shipping | Order routing, sub-orders, transport integration | Logistics module |
| Moderation | Product verification, content policy | Moderation module |
| Analytics and reports | Dashboards for sellers and admin | BI module |
| Load testing | Tests on 10 000+ products, 100+ sellers | Performance report |
| Launch | Data migration, onboard first sellers | Production |
What Distinguishes Marketplace from E-shop
- Catalog scalability — you don't fill catalog, sellers do. Hundreds of thousands of items without content management costs.
- Commission model — revenue without buying goods and maintaining warehouse.
- Complexity — multi-vendor logic, payment splitting, order routing—not a boxed solution, but custom development.
We develop marketplaces on 1C-Bitrix with full cycle: from architecture design to launch with first sellers. Multi-vendor catalog, seller cabinet, commissions, split payments, moderation, analytics—all the logic that makes a marketplace different from regular shop.