Tariff Automation for 1C-Bitrix Marketplace: Seller Billing

Tariff Setup for Marketplace Sellers on 1C-Bitrix

Imagine: your marketplace is growing, sellers are already in the hundreds, and each tariff has to be renewed manually. Managers spend 3 hours a day issuing invoices, errors in limits lead to lost profits, and sellers leave due to suboptimal conditions. Without a flexible tariff system, the platform loses up to 30% of revenue — losses reach 300,000 RUB per month with 200 sellers. When scaling, manual administration becomes a bottleneck: support is overloaded, and late payments hit 20%.

We develop a billing module for marketplaces on 1C-Bitrix that automates all stages: from tariff creation to funds write-off. Our experience shows that proper tariff configuration increases seller LTV by 20% and halves support load. In this article, we’ll cover how to build a tariff architecture on HL-blocks, configure limits, and integrate recurring payments. Automation reduces administration time by 80%.

What Problems Does Tariff Automation Solve?

Manual tariff management creates three typical problems: invoicing takes 2–3 hours a day and leads to errors; rigid limits prevent flexible conditions for different seller categories (50 products for basic tariff, 500 for premium); lack of automatic transition — a seller with an expired tariff continues trading, reducing monetization. These problems are solved by a unified system on HL-blocks with checks in component 2.0.

How Are Limits Configured for Different Seller Categories?

Tariffs are stored in an HL-infoblock or custom table with a set of parameters: maximum number of products, commission, access to analytics, search priority. Each tariff is a record with numeric and boolean fields.

Example structure:

Limit checking occurs in component 2.0 on each seller action:

function checkVendorLimit(int $vendorId, string $feature): bool
{
    $vendor = VendorTable::getByPrimary($vendorId)->fetch();
    $tariff = TariffTable::getByPrimary($vendor['UF_TARIFF_ID'])->fetch();

    switch ($feature) {
        case 'add_product':
            $currentCount = getVendorProductCount($vendorId);
            return $tariff['UF_MAX_PRODUCTS'] === 0
                || $currentCount < $tariff['UF_MAX_PRODUCTS'];
        case 'advanced_analytics':
            return (bool)$tariff['UF_ADVANCED_ANALYTICS'];
    }
    return false;
}

When a limit is reached, the seller sees a clear message with an offer to upgrade to a higher tariff. For mass administration, an interface with group operations (tariff change, renewal) is provided.

Why Does Automatic Renewal Increase LTV by 20%?

Automatic payment via payment system APIs (Tinkoff, YooMoney) eliminates the human factor. A Bitrix agent initiates a charge N days before tariff expiration. If the payment fails, the system sends a notification and provides a grace period. Without renewal, the seller is moved to a free tariff or products are deactivated.

Manual renewal loses 15% of clients due to delays — automation is 5 times more effective. In one project, we implemented auto-renewal for 200 sellers: the number of delinquencies dropped from 30% to 2%. Integration with payment gateways is done via REST API.

Comparison of Tariff Approaches

What Timelines and Guarantees Do We Offer?

Basic functionality (manual management) — 1–2 weeks. With automatic payment — 2–4 weeks. We guarantee stable operation under load up to 10,000 sellers. Our team’s experience: over 10 years in 1C-Bitrix and 50+ implemented marketplaces. Savings from automation reach 150,000 RUB per year due to reduced client churn.

What’s Included in Tariff Setup Work?

1. Analysis of current business logic — requirements gathering, tariff table design.
2. Development of HL-blocks and UF-fields — storing tariffs and linking to sellers.
3. Implementation of limit checks — component 2.0 with caching.
4. Integration with payment API via REST API — recurring charges, webhooks.
5. Administrative interface — tariff management, mass operations, payment journal.
6. Documentation and training — API description, instructions for managers.

How We Work on Tariff Setup?

1. Analytics — determine tariff structure, limits, business rules.
2. Design — database schema, API, interfaces.
3. Development — iterative with client demos.
4. Testing — unit tests, load testing.
5. Deployment — agent setup, monitoring.

Contact us for a cost estimate for your project. Get a consultation on tariff setup — we’ll prepare a quote in one day.

Order tariff setup for your marketplace.

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.