Перейти к содержанию

Как устроена фискализация в интернет-эквайринге

Эта статья задает карту мира. Она не про тесты и не про внутренние отчеты проекта, а про то, как устроен путь от оплаты до кассового чека в банковском интернет-эквайринге.

Что такое расчет

54-ФЗ использует слово «расчет» шире, чем бытовое «деньги списались с карты». Расчетом может быть прием денег, зачет аванса, предоплата, возврат, выдача выигрыша, погашение кредита и другие операции, если они связаны с оплатой товаров, работ или услуг.

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

Касса, ФН, ОФД и ФФД

ККТ — это кассовая техника, которая формирует фискальный документ. Внутри кассы находится фискальный накопитель: он подписывает, хранит и защищает фискальные данные.

ОФД — оператор фискальных данных. Он принимает документы от кассы, передает их в ФНС и обычно показывает человеку публичную страницу чека.

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

Пример: мерчант передал признак способа расчета full_payment. Если кассовый сервис сформировал валидный фискальный документ, но Первый ОФД не вывел на витрину строку «полный расчет», это само по себе не ошибка. Нужно смотреть ФФД, payload в кассовый сервис и итоговый фискальный документ, а не только красивую страницу ОФД.

Облачная и наземная касса

Наземная касса находится в месте расчета: в магазине, у курьера, в кафе, в пункте оплаты. Она может быть связана с принтером и выдавать бумажный чек.

Облачная касса физически стоит в ЦОД кассового провайдера. Для банка и мерчанта она доступна через API. Такая касса удобна для дистанционных расчетов: интернет-магазина, приложения, подписки, доставки, платежа в личном кабинете.

Но облачная касса не превращает офлайн-продажу в интернет-продажу. Если покупатель находится в торговой точке и взаимодействует с продавцом, сценарий может требовать наземную ККТ. Поэтому для табака и алкоголя ответ в контексте облачных касс банка простой: через интернет их продавать нельзя, а облачная касса не применяется как касса на точке. Значит, через платежный шлюз банка и облачную кассу такой сценарий не фискализируется.

Роль платежного шлюза банка

Банк не «печатает чек». Банк принимает от партнера платежные и чековые данные, проверяет их на уровне своего API, маршрутизирует запрос к выбранному кассовому сервису и возвращает статус.

Ответственность за то, что именно продается, когда происходит передача товара и какой фискальный сценарий выбран, остается у партнера. Банк дает инструмент: автоматическую фискализацию при оплате, отдельное создание чека, повтор, коррекцию, получение статуса. Но банк не может легализовать запрещенный товар и не должен угадывать бизнес-событие вместо партнера.

Карта движения данных

Покупатель
  |
  | 1. Оплачивает заказ на сайте, в приложении или личном кабинете
  v
Партнер / мерчант
  |
  | 2. Решает, нужен ли чек сейчас:
  |    продажа, предоплата, закрывающий чек, возврат, коррекция
  |    и передает в банк состав чека
  v
Платежный шлюз банка
  |
  | 3. Проверяет запрос, выбирает сценарий и маршрут:
  |    автоматическая фискализация, doReceipt, retryReceipt,
  |    doCorrection, getReceiptStatus
  v
Кассовый сервис
  |
  | 4. Преобразует запрос в задание для конкретной ККТ
  v
ККТ + фискальный накопитель
  |
  | 5. Формирует фискальный документ по ФФД
  v
ОФД
  |
  | 6. Передает документ в ФНС и дает ссылку/витрину чека
  v
ФНС

Если есть маркировка

Для маркированных товаров появляется еще один участник — ГИС МТ / Честный ЗНАК. В ФФД это связано с ОИСМ и кодом маркировки.

Партнер передает товар и код маркировки
  |
  v
Платежный шлюз передает данные кассовому сервису
  |
  v
Касса / кассовый сервис проверяет или фиксирует сведения о КМ
  |
  v
ОИСМ / Честный ЗНАК возвращает результат проверки
  |
  v
ККТ формирует чек, ОФД передает данные в ФНС и ГИС МТ

Маркировку нельзя сводить к вопросу «какое поле передать». Сначала нужно понять, разрешен ли сам сценарий продажи через интернет и облачную кассу. Только потом обсуждать mark_code, planned_status, товарную группу и поведение конкретного кассового сервиса.

Где заканчивается зона банка

Банк отвечает за понятный API, маршрутизацию к кассовому сервису, статусы, повторные попытки, отдельные фискальные операции и корректный маппинг полей.

Кассовый сервис отвечает за прием задания, работу с ККТ, ошибки кассы и передачу фискального документа.

ОФД отвечает за передачу в ФНС и отображение чека для человека.

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

Источники