Чек создается после подтвержденной оплаты
Фискальный процесс нельзя запускать только по frontend-событию или неподтвержденному redirect.
Фискальный чек должен быть связан с подтвержденной оплатой. Если чек создать слишком рано, можно получить чек без успешного платежа. Если создать слишком поздно или без retry, можно получить успешную оплату без корректной фискальной истории.
Правильный подход - запускать фискальный workflow после server-side подтверждения оплаты. При этом чек лучше обрабатывать как отдельный процесс со своим статусом, журналом и повторными попытками.
- Не запускать чек только по success redirect.
- Связать чек с order id и payment id.
- Хранить отдельный fiscal status.
- Показывать ошибку чека отдельно от ошибки оплаты.
Фискализация должна быть асинхронной
Сервис чеков может отвечать медленно или временно недоступен, поэтому его нельзя делать слабым местом оплаты.
Если фискальный сервис недоступен, это не должно ломать весь платежный callback. Сначала нужно надежно сохранить факт успешной оплаты, а затем поставить фискальную задачу в очередь.
Очередь позволяет повторить отправку, показать менеджеру статус, а также не потерять данные при временном сбое сети или API. Для критичных сценариев нужен ручной режим повторной отправки.
- Отдельная таблица или журнал fiscal jobs.
- Повторные попытки с ограничением.
- Dead-letter статус для ручного разбора.
- Аудит ответа фискального сервиса.
Какие edge cases нужно учесть
Чековая интеграция ломается не на happy path, а на возвратах, частичных оплатах и повторных событиях.
При проектировании важно заранее описать, что делать при повторном webhook, возврате, частичном возврате, отмене заказа и ошибке фискального сервиса. Эти события должны быть видны в журнале, а не исчезать внутри интеграции.
Также нужно разделять статус оплаты и статус чека. Оплата может быть успешной, а чек временно в ошибке. Это не одно и то же состояние, и интерфейс поддержки должен показывать разницу.
- Повторный webhook не должен создавать второй чек.
- Возврат должен иметь отдельный fiscal workflow.
- Частичный возврат требует отдельного правила.
- Ручная коррекция должна логироваться.
FAQ
Можно ли создавать чек синхронно внутри платежного webhook?
Технически возможно, но надежнее сохранять платежное событие и запускать чек через очередь, чтобы сбой фискального сервиса не ломал прием webhook.
Что делать, если чек не создался, а оплата успешна?
Нужен отдельный fiscal status, retry-механизм и ручной разбор. Статус оплаты не должен теряться или откатываться из-за ошибки чека.
Как не создать два чека при повторном callback?
Использовать idempotency по order id/payment id и хранить связь между платежом и фискальной задачей.
