Штрафы на Wildberries и Ozon: как отсечь риск для ИП через API

С 1 января 2026 года для белорусских ИП торговля через маркетплейсы стала не просто вопросом логистики, а вопросом квалификации сделки. Я разбираю, где у Wildberries и Ozon появляется юридический риск, и как закрыть его на уровне интеграции, чтобы не ловить штрафы, блокировки и спор с бухгалтерией.

С 1 января 2026 года тема маркетплейсов для белорусских ИП стала заметно жестче. Если раньше многие смотрели на Wildberries и Ozon как на обычный канал продаж, то теперь этого уже мало: нужно понимать, что именно происходит по документам и по фактической схеме поставки. МНС прямо пишет, что ИП могут работать только по видам деятельности из перечня, утвержденного постановлением Совмина № 457, а МАРТ отдельно разложил по полкам, когда продажа через интернет-площадку считается розницей, а когда — оптом. Для ИП это не академический спор: незаконная квалификация деятельности — это уже риск административки, а со стороны площадки — еще и штрафов, удержаний, блокировки кабинета или отказа в приемке поставки.

Почему проблема вообще появилась

Ключевая точка здесь простая: белорусский Закон № 128-З о торговле разделяет оптовую и розничную торговлю не по кнопке в личном кабинете маркетплейса, а по сути сделки. В официальном разъяснении МАРТ сказано прямо: если продавец реализует товар владельцу интернет-площадки и товар не собственного производства, для продавца это оптовая торговля; если продавец продает конечному покупателю-физлицу для личного использования, это розница. Отсюда и главный вывод, который я бы зашивал в любую интеграцию: для белорусского ИП риск определяется не названием схемы FBO/FBS/FBW, а тем, кому по документам и по потоку данных продается товар.

У МНС формулировка тоже без сантиментов: если ИП работает вне разрешенного перечня, такая деятельность считается незаконной, со ссылкой на Закон № 365-З от 22.04.2024 и нормы ГК. Я бы не переоценивал здесь бытовую логику формата “мы же просто грузим на склад маркетплейса”. Для инспекции и для спора с площадкой решают не ощущения селлера, а договор, реквизиты получателя, тип накладной, роль агента и маршрут отгрузки.

Где у Wildberries и Ozon появляется риск

У Wildberries сама структура интерфейса и API подталкивает к автоматизации. WB API дает методы для работы с товарами, FBS-заказами и поставками, а отдельный раздел по FBW Supplies позволяет строить отгрузочные сценарии со склада площадки. Параллельно в базе знаний Wildberries есть отдельные инструкции по FBS и по модели «Склад WB» / FBW. Технически это удобно. Юридически — не всегда безопасно для ИП из Беларуси.

У Ozon логика похожая: площадка отдельно описывает FBO, FBS и realFBS, а Seller API позволяет управлять продажами по FBO, FBS и realFBS из внешней системы. С инженерной стороны это нормальная история: ERP или 1С дергает API, маркетплейс отвечает статусами, остатками, сборочными заданиями. С белорусской правовой стороны вопрос не в том, доступен ли метод API, а в том, не оформляешь ли ты через этот метод запрещенную для ИП хозяйственную модель.

На Wildberries есть еще одна практическая деталь, которую многие недооценивают. В инструкции по обработке FBS-заказов площадка прямо пишет, что заказы от юридических лиц помечаются плашкой «Юрлицо», и такие заказы нужно собирать отдельно от заказов физлиц. Для меня это сильный сигнал: интеграция обязана различать B2C и B2B поток не “на глаз”, а машинно, еще до того, как заказ поедет дальше по системе.

Почему штрафы и блокировки тут не абстракция

У Wildberries ответственность продавца завязана на оферту и перечень штрафов. В правилах портала площадка прямо указывает, что за нарушение обязанностей продавца взимается неустойка по перечню штрафов, а независимо от штрафа кабинет могут заблокировать или удалить. Там же видно, что Wildberries считает достаточным доказательством и сохраненную копию страницы с карточкой товара или иным нарушением. То есть спорить потом “мы не так поняли процесс” — слабая стратегия. Лучше не допускать опасную операцию вообще. Страница по штрафам и правила портала это подтверждают.

У Ozon механизм другой по форме, но по сути близкий. В правилах о балльной системе нарушений площадка пишет, что если продавец не сможет доказать отсутствие нарушения, кабинет заблокируют, а штраф начислят за каждый товар с нарушением. Я бы не привязывался к конкретным ставкам без проверки свежей оферты — они меняются. Но сама логика санкций публична: сначала у тебя возникает нарушение по товару или процессу, потом это бьет по деньгам и по доступу к кабинету.

Какую защиту я бы ставил в интеграционный слой

Если у клиента ИП и он работает на Wildberries или Ozon, я не стал бы надеяться на дисциплину менеджера или бухгалтера. Я бы ставил отдельный compliance-gateway между учетной системой и API маркетплейса. Его задача не “ускорить обмен”, а не дать системе отправить запрещенную отгрузку.

Минимальный набор проверок у меня обычно такой:

seller_legal_type: ip или company
sales_model: fbo | fbs | realfbs | fbw
buyer_type: individual | legal_entity | marketplace_operator | unknown
is_own_production: true | false
shipment_route: to_marketplace_warehouse | to_end_customer | via_marketplace_agent
risk_flag: low | medium | high | blocked

Логика грубо такая:

Если продавец — юрлицо, жесткий белорусский фильтр по ИП не включается.
Если продавец — ИП, система проверяет, не уходит ли товар по модели, где получателем по документам выступает владелец площадки.
Если это ИП и товар не собственного производства, сценарий с поставкой на склад маркетплейса должен получать статус blocked, пока человек не подтвердит, что договорная схема безопасна.
Если заказ идет конечному физлицу и площадка выступает как витрина/агент, операция может идти дальше.
Все спорные кейсы не должны “проходить по умолчанию”. Только через ручной review с логом решения.

Это не юридическая магия. Это нормальный технический контроль, который переводит правовое требование в код. Опытно скажу так: почти все дорогие ошибки в интеграциях происходят не потому, что API плохой, а потому что бизнес-правила живут у кого-то в голове, а не в middleware. Вырулить потом дороже, чем один раз поставить фильтр. Вывод про опт/розницу здесь опирается на разъяснение МАРТ, а техническая возможность автоматизации — на WB API и Ozon Seller API.

Пример на FastAPI: блокируем опасную поставку до вызова API

Python

from enum import Enum
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI()


class LegalType(str, Enum):
    ip = "ip"
    company = "company"


class SalesModel(str, Enum):
    fbo = "fbo"
    fbs = "fbs"
    realfbs = "realfbs"
    fbw = "fbw"


class BuyerType(str, Enum):
    individual = "individual"
    legal_entity = "legal_entity"
    marketplace_operator = "marketplace_operator"
    unknown = "unknown"


class ShipmentRequest(BaseModel):
    seller_legal_type: LegalType
    sales_model: SalesModel
    buyer_type: BuyerType
    is_own_production: bool
    sku: str
    quantity: int


def detect_compliance_risk(payload: ShipmentRequest) -> tuple[bool, str]:
    if payload.seller_legal_type == LegalType.company:
        return True, "company_flow_allowed"

    # Жесткий фильтр для ИП
    risky_buyer = payload.buyer_type in {
        BuyerType.legal_entity,
        BuyerType.marketplace_operator,
        BuyerType.unknown,
    }

    risky_model = payload.sales_model in {SalesModel.fbo, SalesModel.fbw}

    if risky_model and risky_buyer and not payload.is_own_production:
        return False, "blocked_for_ip_non_own_goods_to_marketplace"

    return True, "allowed_with_review_trace"


@app.post("/shipments/precheck")
def precheck_shipment(payload: ShipmentRequest):
    allowed, reason = detect_compliance_risk(payload)

    if not allowed:
        raise HTTPException(
            status_code=409,
            detail={
                "error": "compliance_block",
                "reason": reason,
                "message": (
                    "Shipment blocked: risky marketplace flow for Belarusian sole proprietor."
                ),
            },
        )

    return {"status": "ok", "reason": reason}

Это, конечно, не боевой код. Но паттерн правильный: сначала precheck, потом только реальный вызов внешнего API. Я бы еще добавил аудит-лог с request_id, seller_id, снапшотом полей риска, версией правил и ручным override только для роли compliance_admin. Иначе через полгода никто не вспомнит, почему конкретную поставку пустили. Сам факт, что маркетплейсы активно двигают продавцов в API-интеграции, виден по документации WB API и документации Ozon Seller API.

Какие поля я бы добавил в базу и 1С-обмен

Самая частая ошибка — пытаться решить вопрос флажком is_ip. Этого мало. Нужна нормальная модель данных.

Я бы добавил как минимум:

origin_country
producer_name
is_own_production
contract_flow_type
allowed_marketplace_models
last_compliance_review_at
last_compliance_review_by
compliance_comment

Почему это нужно? Потому что для ИП критична не только схема доставки, но и происхождение товара. В разъяснении МАРТ прямо различается продажа собственных товаров и реализация чужих товаров владельцу площадки. Если у тебя в карточке товара нет признака собственного производства, система физически не может принять грамотное решение. А если ты полагаешься на комментарий менеджера в Excel, это уже не архитектура, а лотерея.

Отдельно я бы хранил маппинг “какая хозяйственная логика стоит за каждой интеграционной операцией”. Не “это FBO”, а “это передача товара на склад площадки по такой-то договорной модели”. И да, если бизнесу не нравится такой уровень бюрократии, у меня плохая новость: после 1 января 2026 бюрократия уже встроена в саму среду, остается только выбрать, она живет в коде или в будущих проблемах. Формально проверять актуальность лучше по МНС, МАРТ и свежим офертам площадок.

Что это значит на практике

Если ты фрилансер или интегратор, вывод простой: клиенту-ИП на Wildberries или Ozon уже недостаточно “подключить API и синхронизировать остатки”. Нужен слой контроля, который понимает белорусские ограничения по ИП и режет опасные сценарии до отправки в маркетплейс.

Если ты владелец ИП, вывод еще проще: не смотри только на тарифы логистики и удобство FBO/FBS. Сначала проверь, как сделка выглядит по белорусскому праву. В ряде кейсов проблема не в том, что маркетплейс “запрещает”, а в том, что твоя схема для ИП может выглядеть как запрещенный опт.

Если ты работаешь через 1С, МойСклад, самописную ERP или просто таблицы с выгрузкой, лучше один раз поставить precheck на отгрузку, чем потом разбираться, почему кабинет словил санкции или почему бухгалтер отказывается подписывать документы задним числом. На момент написания статьи опорные точки такие: постановление № 457, разъяснение МАРТ по интернет-площадкам, правила Wildberries и правила Ozon по нарушениям. Уточняй актуальность в официальных источниках, потому что оферты и регламенты площадок меняются быстрее, чем статьи на юридических блогах.

Если тебе нужно поставить такой фильтр между 1С, ERP и Wildberries/Ozon без лишней магии — пиши через velutich.com или в Telegram.