Интеграция POS должна однозначно связывать банковскую операцию с заказом, не доверяя только ручному вводу суммы кассиром.
Ниже — практический порядок проверки. Он помогает сначала локализовать источник сбоя, затем внести минимальное изменение и проверить результат на реальном сценарии.
Как проявляется проблема
Кассир выбирает заказ, терминал принимает оплату, но сайт не меняет статус либо платеж прикрепляется к другому заказу.
Что проверить в первую очередь
- Зафиксируйте точное время ошибки, пользователя, объект или операцию, на которой она появилась.
- Сравните успешный и проблемный сценарии: входные данные, права, окружение, версию приложения и последовательность действий.
- Проверьте последние изменения в коде, настройках, интеграциях, инфраструктуре и фоновых заданиях.
- Сохраните связанные логи и идентификаторы запроса до повторного запуска или очистки кеша.
Основные причины
Один и тот же внешний симптом может возникать на разных уровнях. Поэтому полезно проверять не только интерфейс, но и данные, права доступа, очередь событий и состояние внешнего сервиса.
- Терминал не передает merchant reference заказа.
- Статус обновляется вручную до подтверждения операции.
- Повторный callback создает вторую запись оплаты.
- Возврат и отмена на POS не синхронизируются с заказом.
Пошаговая диагностика
- Изучите протокол терминала, локального агента или API эквайера.
- Проследите order id от команды оплаты до подтверждения.
- Проверьте timeout, отказ, отмену и повторную доставку результата.
- Сверьте итог дня по POS, платежам сайта и кассе.
Как исправить
Исправление лучше делать небольшими проверяемыми шагами. Перед изменением рабочих данных сделайте резервную копию или подготовьте обратную миграцию.
- Создавайте платежную попытку с уникальным id до команды терминалу.
- Передавайте сумму и reference из заказа без ручного дублирования.
- Обновляйте заказ только по подтвержденному результату.
- Обрабатывайте callbacks идемпотентно и предусмотрите сверку зависших операций.
Как проверить результат
- Оплата, отказ, отмена и возврат корректно отражаются в одном заказе.
- Повторное сообщение терминала не дублирует платеж.
- Повторите исходный проблемный сценарий и минимум один пограничный случай.
- Проверьте логи после исправления: отсутствие ошибки в интерфейсе еще не гарантирует корректную обработку.
- Убедитесь, что правка не нарушила соседние операции, права других ролей и повторную обработку события.
Чего не стоит делать
- Не отключайте проверки безопасности и разграничение доступа только ради исчезновения ошибки.
- Не меняйте массово рабочие данные без выборки, резервной копии и заранее подготовленного отката.
- Не запускайте повторно платежи, рассылки, возвраты или фоновые задачи, пока не проверена идемпотентность.
- Не оставляйте токены, пароли, персональные данные и полные тела запросов в открытых логах.
Как не допустить повторения
- Храните внешний id операции и журнал состояний.
- Добавьте ежедневный отчет расхождений и ручную безопасную сверку.
Что подготовить для разбора
- Ссылку на проблемную страницу, метод API, задание, отчет или интеграцию.
- Точное описание ожидаемого и фактического результата без секретных ключей и паролей.
- Фрагмент лога за нужный период, идентификатор операции и пример входных данных.
- Список последних изменений и информацию о рабочем окружении.
Частые вопросы
Можно ли исправить проблему без полной переделки?
Чаще всего да. Если сначала найти точку расхождения, достаточно локальной правки в проверке, транзакции, обработчике события, настройке или запросе к данным.
Почему ошибка появляется не у всех?
Обычно различаются роль, состояние данных, устройство, регион, способ входа, версия клиента или порядок событий. Поэтому важно получить конкретный воспроизводимый пример.
Итог
Надежная связь POS и сайта строится вокруг единого идентификатора операции и проверяемой машины состояний.
Если самостоятельно локализовать причину не получилось, я могу разобрать логи и код, воспроизвести ошибку, предложить безопасную правку и проверить ее на рабочем сценарии.