Сценарии фискализации¶
Сценарий фискализации начинается не с названия API-метода, а с бизнес-события: деньги приняли, товар передали, аванс зачли, платеж вернули, ошибку исправили. API только оформляет это событие в фискальный документ.
Оплата и передача товара одновременно¶
Самый простой случай: покупатель оплатил товар и сразу получил его. В чеке обычно используется признак способа расчета «полный расчет» / full_payment.
Для интернет-эквайринга важно понять, действительно ли передача произошла одновременно с оплатой. Если товар будет доставлен позже, это уже не тот же сценарий.
Оплата сегодня, доставка позже¶
Если покупатель оплатил заказ сегодня, а товар будет передан через неделю, возникает два фискальных события.
Первое событие — получение денег. Формируется чек на предоплату или предоплату 100%, в зависимости от состава корзины и модели договора.
Второе событие — передача товара. Формируется закрывающий чек: в нем отражается зачет ранее принятой предоплаты и полный расчет по переданному предмету расчета.
В банковском шлюзе второй чек делается не новым платежом, а отдельной фискальной операцией, например doReceipt.
Состав корзины известен или неизвестен¶
Если в момент оплаты понятно, какие именно товары или услуги оплачены, в первом чеке можно указывать конкретные предметы расчета.
Если состав будущей поставки еще неизвестен, первый чек может отражать платеж/аванс как предмет расчета, а конкретные товары появляются уже в закрывающем чеке.
Это важно для методологии: вопрос не только в поле payment_method, но и в том, что именно считается предметом расчета на момент первого чека.
Маркированный товар¶
Для маркированного товара в чеке появляются дополнительные реквизиты: код маркировки, товарная группа, планируемый статус товара и связанные поля ФФД.
Но техническая возможность передать код маркировки не означает, что товар можно продавать через интернет. Для табака и алкоголя в контексте облачной кассы банка правильный ответ — не «передайте DataMatrix», а «такой сценарий через интернет-эквайринг и облачную кассу невозможен».
Возврат¶
Возврат отражает обратное движение относительно исходного расчета. Для банка важно связать возврат денег и возвратный чек, но это все равно два разных слоя: платежный и фискальный.
Если деньги возвращены, а чек возврата не сформирован, ситуацию нужно проверять по фискальному статусу, а не только по платежному.
Чек коррекции¶
Чек коррекции нужен, когда нужно исправить фискальную ошибку по правилам 54-ФЗ и ФФД. Это не универсальная кнопка «переделать чек». Перед коррекцией нужно понимать, что именно исправляется: неприменение ККТ, ошибка реквизитов, неверная сумма, неправильный признак расчета или другой фискальный дефект.
В банковском шлюзе для этого используется отдельный сценарий, например doCorrection, если он поддержан для партнера и кассового провайдера.
Повтор фискализации¶
Повтор нужен, когда платежное событие уже произошло, но чек не дошел до финального успешного статуса из-за временной ошибки: кассовый сервис недоступен, ККТ не ответила, истек таймаут, была техническая ошибка маршрута.
retryReceipt не должен менять бизнес-смысл чека. Он повторяет фискализацию того же события, а не создает новый сценарий.
Статус чека¶
getReceiptStatus нужен, чтобы не смешивать статус платежа и статус фискализации.
Платеж может быть успешным, но чек еще в обработке. Чек может быть принят шлюзом, но отклонен кассовым сервисом. Чек может быть сформирован, но публичная страница ОФД может показать не все реквизиты, которые ожидал клиент.
Поэтому при разборе вопроса всегда нужны оба слоя: платежный статус и фискальный статус.