Урок 12. Диагностика: оплата, фискализация и закрытие заказа
Условия для выполнения:
- Просмотреть
Модуль 12 · Блок C · ~3 часа · критический модуль (проходной балл 100%)
Диагностика: оплата, фискализация и закрытие заказа
Цель модуля: Дать безопасные модели поведения в сценариях, где ошибка стоит денег: зависшая оплата, отсутствующий чек, незакрытый заказ и рассинхрон статусов.
Результаты обучения — после модуля специалист сможет:
- разделять этапы: оплата, фискализация, закрытие — и не решать одну проблему через другую;
- устанавливать фактический статус транзакции до любых действий;
- не допускать двойного списания и дублей заказов;
- распознавать массовый инцидент и корректно его оформлять.
Урок 12.1. Три этапа, которые нельзя смешивать
| Этап | Что означает сбой | Чего делать нельзя |
|---|---|---|
| Оплата | Деньги не списаны или статус неясен | Повторять оплату без установления статуса первой попытки |
| Фискализация / чек | Деньги списаны, но фискальный этап не завершён | Повторять оплату из-за отсутствия чека |
| Закрытие заказа | Деньги списаны, заказ не перешёл в закрытое состояние | Проводить повторную оплату или создавать новый заказ |
Ключевая мысль модуля: Если деньги списались — проблема больше не является «неуспешной оплатой». Это проблема следующего этапа: фискализации или закрытия. Решать её через повторную оплату означает списать с гостя второй раз.
Урок 12.2. Оплата: POS, Kaspi и повторные попытки
| Симптом | Что проверить | Что делать |
|---|---|---|
| POS не получает сумму | Стабильность iPad и терминала; связь между ними; сеть; настройки интеграции; зависший старый экран оплаты | Проверить видимость терминала, сеть; перезапустить устройства, если статус предыдущей оплаты чистый; повторно передать сумму |
| POS не принимает оплату | Включён ли терминал и не завис ли; питание; сеть; передалась ли правильная сумма; нет ли зависшей предыдущей попытки | Повторять оплату только после проверки, что предыдущая попытка действительно не завершилась |
| Терминал завис во время оплаты | Есть ли признаки, что платёж ушёл в обработку; подтверждение банка или системы; запись о транзакции; завис только экран или сам сценарий | Уточнить статус, не повторять автоматически. Если транзакция не проходила — безопасно завершить зависший сценарий |
| Сумма на POS не совпадает с заказом | Итоговую сумму на iPad; состав корзины; комбо и модификаторы; не менялся ли заказ перед оплатой; не завис ли терминал со старой суммой | Прервать оплату. Запускать повторно только после устранения расхождения |
| Оплата по QR / Kaspi не проходит | Совпадение суммы; не обрывался ли интернет; не зависла ли система после предыдущей попытки; нет ли частично проведённой транзакции; текст ошибки платёжного сервиса | Проверить фактический статус. Если статус чистый — повторить. Если неясен — сначала выяснить |
| QR / Kaspi настроен некорректно | Активирован ли нужный способ оплаты для точки; правильная ли конфигурация Киоска; настройки платёжного сценария; доступность оплаты для этой точки и режима | Сверить настройки, перезапустить приложение после изменений, провести тестовый сценарий |
Главное правило повторной оплаты: Если статус первой транзакции неясен — повторная оплата запрещена до выяснения. Проверяется: что показывает терминал, есть ли запись в системе, было ли фактическое списание, есть ли подтверждение банка, не завис ли заказ между этапами.
Система предлагает оплатить снова, хотя оплата прошла
Это рассинхрон статусов, а не повод к новой оплате. Ориентироваться нужно не на экран, а на фактический статус транзакции и заказа. Не повторять оплату, подтвердить фактический статус и разбирать проблему статусов.
Урок 12.3. Фискализация и чек
| Симптом | Логика разбора |
|---|---|
| После оплаты не вышел чек | Сначала подтвердить факт оплаты, затем отдельно проверить печать и фискальный контур: работает ли устройство печати; доходит ли система до этапа печати; нет ли ошибки кассы или фискализации |
| Непонятно, должен ли был выйти чек | Проверить тип оплаты и сценарий точки: должен ли чек печататься автоматически; есть ли подтверждение оплаты; есть ли запись о фискализации; на каком этапе оборвался процесс |
| В iiko есть оплата, но нет фискализации | Считать платёж фактически совершённым. Не терять оплаченный заказ. Отдельно диагностировать фискальную часть и восстанавливать фискальный сценарий |
| Заказ не фискализируется | Проверить интернет, доступность фискального сервиса, статус фискализации в iiko, кассовую конфигурацию, массовость проблемы |
| Проблема с webkassa / фискальным сервисом | Сохранить точный текст ошибки и время; проверить, повторяется ли на других точках; при массовой проблеме эскалировать как внешний сбой, при локальной — проверять кассовую конфигурацию и подключение |
Ошибки кассы
| Ошибка | Разбор |
|---|---|
| CashRegisterOperationFailed | Проверить тип оплаты, режим кассы, связь с интернетом, работу фискального сервиса, нет ли уже завершённой оплаты. Если оплата прошла — не повторять её автоматически, устранять кассовую ошибку отдельно |
| Не настроена кассовая интеграция / нет обязательного ключа | Проверить обязательные ключи и параметры, привязку точки, пропущенные настройки интеграции. Дозаполнить, перезапустить сценарий, провести тестовую оплату |
| Не создан тип оплаты, стол или режим кассы | Донастроить недостающие сущности, проверить конфигурацию точки, повторить оплату только после исправления |
Урок 12.4. Закрытие заказа и рассинхрон статусов
| Симптом | Что делать |
|---|---|
| Заказ не закрылся после оплаты | Подтвердить факт оплаты, проверить фактический статус заказа в iiko, не запускать повторное закрытие автоматически, понять, где произошёл разрыв: после оплаты, при подтверждении POS или при финализации в iiko |
| Оплата прошла, заказ остался открытым | Зафиксировать, что платёж прошёл. Не повторять оплату. Проверить историю статусов и, если логика точки требует, перевести заказ в корректный конечный статус по служебному процессу |
| Заказ закрылся не полностью или некорректно | Сопоставить все фактические статусы, определить незавершённый этап, довести заказ до корректного состояния по служебному сценарию, зафиксировать рассинхрон |
| Order closure error | Не повторять закрытие автоматически. Проверить, есть ли оплата, статус в iiko, чек и фискализацию, подтверждение платёжного контура, не был ли заказ уже закрыт частично. Восстанавливать статус от реального состояния |
| Заказ завис в промежуточном статусе | Проверить цепочку статусов, найти место разрыва, не создавать повторный сценарий закрытия как новый, восстановить статус от фактического состояния |
| Заказ уже закрыт, но система пытается закрыть повторно | Подтвердить фактический статус, не запускать повторное закрытие, определить источник рассинхрона |
| Киоск показывает открытый заказ, а в iiko он закрыт | Источник истины — iiko. Не повторять закрытие. Обновить фронт или перезапустить Киоск, если это безопасно |
| Статусы фронта и системы не совпадают | Взять фактический статус из системы как основной ориентир, локализовать, где потерялся или не обновился статус, исправить через корректный сценарий |
Массовый инцидент
Если после оплаты массово не закрываются заказы — это уже не одиночный кейс. Порядок действий:
- Зафиксировать время начала массового сбоя.
- Собрать несколько примеров заказов.
- Не допускать хаотичных повторных закрытий и повторных оплат.
- Перевести ситуацию в режим системного инцидента.
- Передать на техническую эскалацию как массовую проблему финализации.
Тестовые и зависшие заказы
Осторожно: Главная ошибка — принять реальный зависший заказ за тестовый и удалить его. Проверяйте время создания, сумму, совпадение с моментом тестового запуска, наличие оплаты и следы реального клиентского сценария. При малейшем сомнении разбирайте заказ как клиентский инцидент.
Практическое задание
- Составьте личную памятку «три этапа и три запрета» и держите её на выездах.
- Кейс: гость оплатил 6 800 ₸, деньги списались, заказ остался открытым, администратор просит «пробить заново». Напишите развёрнутый ответ администратору и план ваших действий.
- Кейс: на трёх точках подряд заказы зависают после оплаты. Опишите, по каким признакам вы классифицируете это как массовый инцидент и что передадите технической команде.
Критерий прохождения: Тест 100% (число попыток не ограничено) + зачтены все три практических задания.
Тест: вопросы этого модуля загружаются в Moodle отдельно, из банка вопросов (категория «Модуль 12»).