Оплата своей картой прошла, но клиент сообщает: банк подтвердил операцию, а заказ всё ещё ожидает оплаты. Другой покупатель не смог открыть платёжную форму, третий оплатил заказ, но не получил чек. Повторный тест владельца снова успешен — и создаётся впечатление, что проблемы нет.
Короткий ответ: один успешный платёж проверяет только один набор условий. Чтобы найти частичный сбой, нужно сопоставить успешный и неуспешный сценарии и определить первый этап, на котором их результаты разошлись. Проверять следует не только списание денег, но и состояние заказа, чек и передачу данных в связанные системы.
Пока состояние платежа не сверено, не просите покупателя платить повторно и не меняйте статус заказа вручную без согласованного порядка. Иначе можно создать дубль, скрыть техническую причину или нарушить связь между оплатой, чеком и возвратом.
Сначала определите, что именно не сработало
Фраза «не проходит оплата» может описывать разные ситуации:
- платёжная форма не открылась или вернула ошибку;
- покупатель не завершил подтверждение в банке;
- банк или платёжный сервис подтвердил операцию, но сайт не обновил заказ;
- заказ отмечен оплаченным, но электронный чек не сформировался;
- оплата отражена на сайте, но сведения не дошли до системы учёта, склада или доставки;
- повторная попытка создала второй заказ или риск повторного списания.
Эти симптомы нельзя объединять в одну неисправность. У каждого своя точка проверки, а число заказов в административной части не всегда показывает масштаб: попытка могла оборваться ещё до создания заказа.
Как устроен путь оплаты
Платёж на сайте — это цепочка событий. Сайт получает состав заказа и данные покупателя, создаёт заказ, фиксирует сумму и обращается к платёжному сервису. Покупатель подтверждает операцию выбранным способом. После решения банка платёжный сервис меняет состояние операции и уведомляет сайт. Сайт сопоставляет уведомление с заказом, проверяет сумму и результат, затем обновляет статус.
После этого могут запускаться другие процессы: формирование электронного чека, уведомление менеджера, изменение остатка, передача заказа в систему учёта или доставку. Успех одного этапа не подтверждает остальные.
Возврат покупателя на сайт не равен подтверждению платежа
Покупатель может закрыть вкладку, потерять связь или не вернуться из банковского приложения. Поэтому страница «Спасибо за заказ» не должна быть единственным основанием для смены статуса. Итог операции подтверждается отдельным уведомлением платёжного сервиса.
Такое уведомление может прийти с задержкой или повторно. Повторная обработка не должна создавать новый заказ, повторно выдавать услугу или дважды запускать связанные действия. Этот сценарий проверяют в безопасном тестовом контуре.
Платёж, заказ и чек имеют разные состояния
Деньги могут быть приняты, пока заказ остаётся в ожидании. Заказ может стать оплаченным, а чек — задержаться. Поэтому для спорной операции отдельно сверяют:
- состояние платежа у платёжного сервиса;
- статус и сумму заказа на сайте;
- состояние электронного чека;
- передачу данных в связанные системы.
Если деньги приняты, покупателя не отправляют платить заново. Если отсутствует чек, проверяют маршрут фискализации и привлекают ответственного за бухгалтерскую часть; технический специалист проверяет передачу и обработку данных.
Безопасная первичная диагностика
Возьмите два примера, желательно близких по времени: один успешный и один неуспешный. Для каждого зафиксируйте:
- дату и точное время с часовым поясом;
- номер заказа и сумму;
- способ оплаты;
- устройство, браузер и тип сети;
- шаг, на котором остановился покупатель;
- текст ошибки или снимок экрана без платёжных реквизитов;
- состояние операции в кабинете платёжного сервиса;
- статус заказа, наличие чека и результат передачи данных дальше.
Разместите события по времени. Сначала сравните создание заказа, затем открытие формы, подтверждение операции, получение уведомления сайтом, изменение заказа и последующие действия. Первая точка, где успешный сценарий имеет ожидаемый результат, а неуспешный — нет, задаёт направление технической проверки.
Для диагностики не нужны полный номер карты, код CVV/CVC, пароль покупателя или секретный ключ платёжного сервиса. Не включайте их в переписку и снимки экрана. Доступы передавайте только согласованным защищённым способом.
Что проверять по типу симптома
Форма оплаты не открылась
Проверяют, был ли создан заказ, корректны ли сумма и валюта, доступна ли платёжная форма и не истёк ли срок ожидания. Воспроизводить ошибку нужно в сопоставимых условиях: с тем же способом оплаты и похожим составом заказа, но без серии реальных списаний.
Деньги приняты, а заказ не оплачен
Сверяют операцию у платёжного сервиса, доставку уведомления на сайт, результат его проверки и изменение заказа. Важны точное время, идентификаторы операции и заказа, сумма и ответ обработчика. Ручная смена статуса до этой сверки может уничтожить полезный диагностический след.
Заказ оплачен, но чека нет
Проверяют запуск задачи на формирование чека, ответ онлайн-кассы и порядок повторной обработки. Решение должно исключать второй чек для уже обработанной операции и сохранять связь с исходным заказом.
Ошибка возникает только у части покупателей
Сравнивают способы оплаты, устройства, браузеры, сети, суммы, состав корзины и время. Различие помогает сузить поиск, но само по себе ещё не доказывает причину. Вывод подтверждают журналами событий или воспроизведением в тестовом контуре.
Менеджер не видит оплаченный заказ
Если платёж и статус заказа уже подтверждены, проверяют передачу в систему учёта клиентов и заявок, склад или доставку. Такой сбой может задержать обработку заказа, хотя сама оплата прошла.
Когда можно разобраться самостоятельно
Владелец сайта может без разработчика собрать два сравнимых примера, сверить состояние операции в кабинете платёжного сервиса, проверить заказ и чек, а также выяснить, дошли ли сведения до менеджера. Иногда этого достаточно, чтобы обнаружить не технический сбой, а незавершённое подтверждение покупателем.
Самостоятельная проверка должна остановиться там, где требуются изменение рабочего кода, повторная обработка уведомлений, ручная корректировка финансовых состояний или работа с секретными данными. Эти действия выполняют по утверждённому порядку, после сохранения журналов и с возможностью отката.
Что запросить у подрядчика
Полезный результат диагностики — не фраза «у нас всё работает», а проверяемое объяснение. В нём должны быть:
- схема пути от оформления заказа до платежа, чека и связанных систем;
- источник достоверного состояния для каждого этапа;
- временная линия успешного и неуспешного примера без платёжных реквизитов;
- первая подтверждённая точка расхождения;
- перечень затронутых способов оплаты и сценариев;
- план исправления, тестирования, выпуска и отката;
- порядок безопасной повторной обработки и финансовой сверки;
- критерии приёмки обычных и граничных сценариев.
После изменения проверяют не только обычную оплату, но и задержанное или повторное уведомление, отмену, возврат и недоступность связанной системы — в пределах сценариев, которые поддерживает конкретный проект.
Когда нужна техническая диагностика
Если операция подтверждена, а заказ, чек или связанная система показывают другое состояние, нужен разбор всей цепочки. OpenStart начинает с фактического симптома: сопоставляет события по времени, проверяет журналы и очереди, воспроизводит нужные сценарии на тестовом контуре и локализует первый разрыв. Затем можно исправлять конкретный участок, а не менять настройки наугад.
Для первичного разбора достаточно подготовить время сбоя, номер заказа, сумму, способ оплаты, точный симптом и состояние операции у платёжного сервиса — без карточных реквизитов и секретов.