Заказ
Проверяем создание заказа, состав, сумму, валюту, обязательные поля и уникальный идентификатор до перехода.
Платёжный сценарий
Не работает оплата на сайте
Проверяем путь от создания заказа до подтверждённого статуса: параметры, подпись, платёжную страницу, возврат клиента и серверный webhook. Исправляем сбой без хранения или передачи карточных данных через сайт.
Контроль по этапам
Где прерывается
платёж
Оплата включает пользовательский переход и независимое серверное подтверждение. По требованиям PCI SSC область ответственности зависит от того, откуда загружаются элементы платёжной страницы, поэтому не переносим карточные поля на сайт ради быстрого ремонта.
Запрос провайдеру
Сверяем магазин, режим, разрешённые адреса, подпись, формат суммы и фактический ответ API без раскрытия ключей.
Платёжная страница
Проверяем редирект или виджет, HTTPS, блокировки браузера и корректное отображение на мобильном устройстве.
Webhook
Проверяем доступность callback, подпись, код ответа, повторную доставку и безопасную обработку одного события.
Статус заказа
Сопоставляем идентификаторы, фиксируем переходы состояний и не считаем возврат браузера доказательством оплаты.
Уведомления и аналитика
Письмо, CRM и цель запускаются после подтверждённого статуса, без дублей при повторном webhook.
Результат
Оплата и заказ синхронизированы
Понятный статус
Успех, ожидание, отказ и возврат не смешиваются.
Повторяемый webhook
Дубликат уведомления не создаёт повторный заказ или действие.
Безопасный интерфейс
Платёжные данные обрабатываются выбранным провайдером.
Матрица тестов
Проверяем не только успешную карту
Сбой часто проявляется на отказе, закрытии окна или повторном уведомлении. Используем тестовый режим и фиксируем ожидаемый статус каждого сценария.
Успех
Заказ подтверждается один раз и получает платёжный идентификатор.
Отказ
Причина показана корректно, повтор доступен без нового лишнего заказа.
Отмена и тайм-аут
Неоплаченный заказ не становится успешным по возвратному URL.
Повтор callback
Одинаковое событие обрабатывается идемпотентно.
Безопасность
Не просим данные банковской карты
Для диагностики нужны идентификаторы заказа и операции, время и технические ответы. Номер карты, срок действия и защитный код не запрашиваются и не должны попадать в заявку или журнал сайта.
Для начала подготовьте
- URL оформления и способ оплаты;
- номер тестового заказа;
- время и точный этап ошибки;
- статус в кабинете провайдера;
- последние изменения модуля или CMS.
Реальные платежи, возвраты и финансовые операции не выполняем без отдельного подтверждения.
Сценарии сбоя
Где прерывается оплата
Жалоба «не проходит платёж» может относиться к созданию заказа, переходу к провайдеру, решению банка или обработке уведомления. Мы фиксируем этап и проверяем его отдельно.
До платёжной формы
Магазин должен создать заказ, рассчитать итог и передать обязательные поля. Проверяем валюту, идентификатор магазина, подпись, URL возврата и ответ API. Ошибку в браузере сопоставляем с серверным журналом.
У провайдера
Тестируем отказ, отмену, превышение времени и повторную попытку. Код ответа показывает, связана ли операция с настройкой магазина, способом оплаты или решением банка.
После списания
Успех подтверждает серверный webhook, а не страница «Спасибо». Сверяем подпись, сумму, номер заказа, защиту от повторной обработки и изменение статуса.
Касса и аналитика
Проверяем состав заказа, НДС и контакт покупателя. Цель оплаты должна отправляться один раз с тем же идентификатором, который записан в CMS.
Безопасная проверка
Сначала тестовый контур
Используем тестовые ключи, если провайдер их предоставляет. Реальное списание проводим только после согласования владельца. Перед изменением обработчика сохраняем код и настройки webhook. Результат подтверждают четыре сценария: успех, отказ, отмена и повторное уведомление. Сумма и статус должны совпасть в CMS, кабинете провайдера и кассе.
После восстановления
Наблюдаем за уведомлениями
В первые дни контролируем долю заказов со статусом «ожидает оплаты», время между платежом и webhook, ошибки проверки подписи и повторные уведомления. Резкий рост одного кода ответа показывает новый сбой до обращения покупателей.
Для поддержки сохраняем версию SDK, адрес кабинета провайдера, расположение журналов и контрольный тестовый сценарий. Секреты остаются в защищённой конфигурации. Если провайдер меняет API или сертификаты, сначала проверяем тестовый магазин и только потом рабочий обработчик.
Что подготовить
Данные для точной диагностики
Нужны URL оформления, название платёжного сервиса, тестовый магазин и два номера заказа: успешный и проблемный. Скриншот без номера операции редко помогает, потому что провайдер ищет событие по своему идентификатору и времени.
Журнал операции
Сохраняем время, сумму, валюту, ID заказа, ID платежа и код ответа. Секретный ключ, данные карты и полный токен в переписку не копируем.
Состояния заказа
Описываем разрешённые переходы: новый, ожидает оплаты, оплачен, отменён, возвращён. Webhook не должен переводить возвращённый заказ обратно в оплаченный.
План отката
Перед заменой SDK или обработчика сохраняем рабочую версию и параметры магазина. Если новая схема не проходит контрольные сценарии, возвращаем предыдущую без потери заказов.
Самостоятельно можно проверить статус тестового магазина, URL уведомления и совпадение суммы. Не стоит повторно отправлять боевой callback вручную или менять секрет на рабочем сайте без синхронизации: старые уведомления перестанут проходить проверку подписи.
Вопросы
Перед исправлением
Почему нет перехода к оплате?
Проверяем заказ, поля, сумму, подпись, настройку магазина и ответ провайдера.
Деньги списаны, но заказ не оплачен?
Проверяем webhook, подпись, идентификаторы и повторную обработку события.
Нужна реальная карта?
Нет, сначала используем тестовый режим. Реальное списание требует отдельного согласования.
Что тестируется?
Успех, отказ, отмена, тайм-аут, повторный callback и обновление заказа.
Первый шаг
Опишите этап ошибки
Пришлите URL, номер тестового заказа, время и статус у провайдера. Карточные данные не отправляйте.