Описание
VPOS Fiscal связывает подтвержденную онлайн-оплату с выпуском фискального чека, очередью повторных попыток и журналом ошибок.
Почему чек нельзя привязывать только к redirect
Фискальный чек должен выпускаться после надежного подтверждения оплаты, а не после того, как пользователь вернулся на страницу "спасибо". Redirect может не произойти, произойти дважды или прийти раньше финального ответа провайдера.
VPOS Fiscal отделяет событие оплаты от события фискализации. Это дает понятный audit trail: когда платеж был создан, когда подтвержден, когда чек поставлен в очередь и чем завершилась попытка выпуска.
Как работает очередь чеков
После подтверждения оплаты создается fiscal job. Если внешний сервис, ERP или внутренний API временно недоступны, задача не теряется, а остается в очереди с ограниченными повторными попытками и причиной ошибки.
Оператор видит не общий "не выпущено", а конкретный статус: ошибка данных, таймаут, недоступен провайдер, требуется ручная проверка или чек уже выпущен ранее.
- Повторные попытки не создают дубли чеков
- Критичные ошибки сохраняются для разбора
- Ручное вмешательство отделено от автоматического retry
Возвраты и спорные статусы
Фискальная логика должна учитывать не только успешную продажу, но и возврат, частичный возврат, отмену до списания и расхождение между CRM и платежным провайдером.
Для пилота важно заранее определить, какие статусы создают чек, какие создают возвратный документ, а какие требуют ручной проверки до любых фискальных действий.
Частые вопросы
Когда должен выпускаться фискальный чек?
Чек должен выпускаться после подтвержденной оплаты и проверки данных заказа. Browser redirect или нажатие кнопки пользователем не являются достаточным основанием для фискального действия.
Что делать, если чек не выпустился сразу?
Задача должна оставаться в fiscal queue с причиной ошибки и ограниченными retry. Если ошибка связана с данными или дублем, ее лучше перевести в ручную проверку.