Когда маркетплейсу нужна онлайн‑касса по 54‑ФЗ

Касса нужна площадке, если она принимает деньги от покупателя: от своего имени, как комиссионер или агент. Когда деньги идут сразу продавцу, чек выбивает продавец. Ключевой маркер — кто является стороной расчёта в оферте и в платёжном потоке.

Проще говоря, онлайн‑касса на стороне маркетплейса обязательна, когда площадка — «merchant of record» и именно через неё проходит платёж. Если же маркетплейс лишь сводит стороны и не касается денег, фискализирует продавец. По опыту, путаница возникает в гибридных договорах: юридически — агент, технически — платёж уходит принципалу напрямую. Тогда чек и реквизиты агента в чеке — у продавца. Ещё один частый нюанс — предоплата: чек аванса формирует тот, кто принял деньги, а чек полного расчёта — тот же субъект в момент отгрузки. Для цифровых услуг, доставки и работ логика та же, меняется только предмет расчёта и признак способа оплаты.

Если используются сплит‑платежи и технический агрегатор, важно смотреть на юридическую конструкцию: кто оформлен получателем средств. Бывает, что деньги кратко «касаются» счёта площадки в рамках эскроу — тогда чек всё равно на стороне того, кто указан получателем по правилам расчётов. Маркировка, кстати, не отменяет кассу: при продаже маркированных товаров в чеке обязателен код маркировки.

Кто выбивает чек и что там указать

Чек формирует тот, кто принимает оплату. В нём обязательно отражаются предмет расчёта, НДС продавца и признак агента с реквизитами принципала, если площадка действует как посредник.

Техническая правда всегда следует за юридической: если площадка — агент и принимает деньги, чек выбивает площадка, но с реквизитами принципала, чтобы налоговая понимала, чей это доход. Отсюда — аккуратная настройка ККТ, ОФД и номенклатуры: ставки НДС берутся из карточки продавца, признак расчёта — «предоплата», «полный расчёт», «возврат прихода». Ошибки в этих полях рождают цепочку — от отказа ОФД до претензий ФНС. Для служб доставки отдельно указывается предмет «услуга по доставке»; для сервисов со смешанным чеком — корректно разбиваем позиции. Платёжная логика стремится к простоте, но в чеке сложность полезна: она объясняет, кто за что отвечает.

• Признак агента в чеке: комиссионер/агент;
• Реквизиты принципала: ИНН, наименование (обязательно);
• Система налогообложения (СНО) принципала и ставки НДС по позициям;
• Предмет расчёта и способ расчёта: аванс, полный, частичный, кредит;
• Признак способа оплаты: карта, СБП, электронные средства;
• Для маркировки — КМ/модификаторы по каждой позиции.

Когда площадка удерживает комиссию из поступивших средств, это отдельный расчёт между агентом и принципалом: его фискализация — уже не «чек покупателя», а документы между сторонами (акт, счёт‑фактура), хотя иногда применяют внутренние кассовые сценарии для прозрачности возвратов.

Как настроить приём оплат: эквайринг, сценарии и безопасность

Выбирайте эквайринг с понятными тарифами, поддержкой 3‑DS 2.0, сплит‑платежами и быстрыми выплатами. Сразу закладывайте фискализацию через API и раздельные платежи по ролям, чтобы чек шёл туда, где деньги.

Хороший платёжный поток начинается с карты и заканчивается фискализацией без ручной магии. Базовая картина такова: покупатель платит картой, через СБП или кошелёк; платёжный шлюз держит сессию, антифрод и 3‑DS 2.0; средства распределяются — продавцу и площадке (комиссия), иногда через эскроу до подтверждения отгрузки; вебхуки гонят статусы в IT‑ядро маркетплейса и кассу. В этом пазле нет мелочей: SLA выплат, защита от чарджбэков, PCI DSS‑контур (лучше SAQ A), логирование и дубликатные защиты. Если региональная сеть точек — добавляется POS/QR‑эквайринг, но логика с чеком та же. Разумеется, интеграция с ККТ и ОФД должна быть по API, чтобы автоматом пробивать авансы, закрывать их полным расчётом и не путать возвраты.

• Минимальный план интеграции: платёжное API + вебхуки статусов;
• ККТ/ОФД по API: аванс, закрытие аванса, возврат прихода;
• Справочник НДС, СНО, признаки агента — из карточки продавца;
• Логирование и идемпотентность: защита от дублей чеков;
• Блок «disputes»: сбор доказательств для чарджбэков.

Если площадка растёт, добавляются B2B‑инвойсы и MOTO‑платежи (по телефону), но их лучше изолировать: отдельные мерчанты, отдельные кассовые профили. Меньше пересечений — меньше ошибок в отчётности.

Возвраты, предоплата и сроки фискализации

Чек предоплаты выбивается при списании средств, чек полного расчёта — при отгрузке. Возврат денег сопровождается чеком возврата прихода не позднее даты возврата, а при исправлениях — чеком коррекции.

Три частых сценария. Первый: предоплата сегодня, отгрузка завтра — значит, сегодня чек «предоплата», завтра — «полный расчёт» с зачётом аванса. Второй: частичный возврат по одной позиции в корзине — формируется чек возврата по конкретной строке, комиссия площадки возвращается пропорционально или по правилам оферты (если невозвратна — так и фиксируется). Третий: отмена до отгрузки — сторнируется платёж и пробивается чек возврата на всю сумму. Правило срока простое и строгое: передача сведений в ОФД — в момент расчёта, максимум до следующего рабочего дня. Для СБП — те же сроки и признаки. Если продаётся маркированный товар, при возврате — возврат по КМ, иначе швы в отчётности разойдутся. И ещё мелкая, но важная деталь: при смене продавца в заказе нельзя «перекидывать» чек — требуется возврат и новый расчёт.

Для служб доставки дополнительно фиксируется момент оказания услуги: либо вместе с товаром, либо по завершении маршрута — это влияет на «полный расчёт». Для подписок и регулярных списаний удобно использовать рекуррентные платежи с токенами, однако фискализация у них обычная: чек при каждом списании, а не «раз в месяц суммой» — иначе риски претензий.

Если что‑то пошло не так (двойной чек, неверная ставка НДС), спасают чек коррекции и закрывающие документы. Но лучше не доводить: валидаторы номенклатуры, автоматические тесты фискализации на стейджинге и «чёрные ящики» логов берегут нервы всем, честно говоря.

Итог

Онлайн‑касса на маркетплейсе появляется там, где появляются деньги покупателя: площадка принимает оплату — площадка и фискализирует, продавец получает напрямую — чек у продавца. Остальное — техника и дисциплина: корректные роли в оферте, предсказуемый эквайринг, API чекирования и аккуратные возвраты.

Если собрать эту конструкцию сразу — с признаком агента, сплитом, 3‑DS 2.0 и жёстким логированием, — расчёты становятся прозрачными, а вопросы налоговой звучат спокойно и по делу. Текст оферты, платёжный поток и чек начинают совпадать — и вот тогда эквайринг работает бесшумно, как и должно быть.