Тестирование оплаты на сайте — обязательный этап перед запуском приёма денег. Даже если вы используете готовые модули или плагины, важно проверить песочницу PSP (Payment Service Provider), корректность вебхуков платежных систем, обработку статусов, идемпотентность запросов и стратегию ретраев. От этого зависит, будет ли заказ оформлен, чек пробит, а пользователь вовремя увидит результат платежа.
Если вы только выбираете провайдера, начните со страницы «Подключение платежной системы к сайту» и «Сравнение провайдеров РФ». Для карт, СБП и альтернатив см. «Методы оплаты: карты и СБП».
Песочница PSP имитирует боевую среду и позволяет прогонять полный цикл: авторизация, 3‑D Secure, холд/списание, отмена, возврат, вебхуки, фискализация. Большинство провайдеров (например, ЮKassa, CloudPayments, Тинькофф Касса) дают тестовые ключи и тестовые карты 3DS.
Основные кейсы песочницы:
| Кейс | Что проверяем | Ожидаемый результат |
|---|---|---|
| Успешная оплата картой | Редирект/виджет, 3‑D Secure, возврат на сайт | Статус Paid/Captured, e-mail/страница «успех» |
| Отказ по карте | Обработка decline-кодов | Понятная ошибка на фронте, запись в логи транзакций |
| 3‑D Secure челлендж | Тестовые карты 3DS | Корректный флоу 3DS1/3DS2, отсутствие бесконечных редиректов |
| СБП | QR/Deep Link | Webhook с успешным статусом, корректное ожидание пользователя |
| Частичный/полный возврат | API Refund | Статус Refunded, корректная бухгалтерия и уведомления |
| Предавторизация/капча | Hold/Capture | Правильная логика фулфилмента до/после capture |
| Сбой вебхука | Повторная доставка | Идемпотентная обработка, ретраи провайдера |
| Фискализация | 54‑ФЗ | Успешная передача в ОФД, сверка с оплатой |
Советы:
Вебхуки платежных систем — это серверные уведомления о смене статуса платежа. Они приходят асинхронно и могут дублироваться. Правильная обработка вебхуков — ключ к верной «обработке статусов платежей» и стабильной аналитике.
Лучшие практики:
Разные PSP возвращают схожие жизненные циклы. Приведём обобщённую модель.
| Статус PSP | Что это значит | Ваше действие в системе | Сообщение пользователю |
|---|---|---|---|
| pending/awaiting_action | Платёж инициирован, ждёт действия (3DS/SBP) | Держите заказ в “Ожидании” | «Ожидаем подтверждение платежа…» |
| authorized | Средства заблокированы (hold) | Не отгружайте до capture, либо готовьте резервы | «Оплата авторизована, мы подтверждаем заказ» |
| captured/paid | Деньги списаны | Подтверждайте заказ, запускайте фулфилмент | «Оплата прошла успешно» |
| canceled/voided | Платёж отменён | Закрывайте заказ, освобождайте резервы | «Оплата отменена» |
| refunded/partially_refunded | Вернули деньги | Синхронизируйте возвраты, уведомляйте клиента | «Сделан возврат по заказу» |
| chargeback/dispute | Чарджбэк | Внутренняя процедура и документы | Нейтральное уведомление о споре |
Совместите webhook-поток со сторожевым pull-опросом при задержках. Это минимизирует расхождения между фронтом и бек-офисом.
Идемпотентность — обязательное требование как для исходящих запросов к PSP, так и для входящих вебхуков.
Где нужна идемпотентность:
Практические советы:
Сети нестабильны: время от времени падают PSP, провайдеры СМС, ваш сервер, интернет у пользователя. Правильно настроенные ретраи и экспоненциальный backoff сохраняют деньги и нервы.
Рекомендуемая стратегия ретраев для запросов к PSP и обработке вебхуков:
| Этап | Ретраи | Пауза | Комментарий |
|---|---|---|---|
| Исходящий запрос (create/capture/refund) | 3–5 попыток | 0.5с, 2с, 8с, 30с | Только при сетевых/5xx; не ретраить 4xx |
| Входящий вебхук (consumer) | 5–8 попыток | 0с, 1м, 5м, 15м, 1ч | Идемпотентно, с DLQ при истечении |
| Reconcile job (poll PSP) | До N часов | каждые 5–15 минут | Останавливать после финального статуса |
Не забудьте про dead-letter queue (DLQ) для событий, которые не обработались автоматически — их удобно чинить вручную.
Даже с вебхуками возможны рассинхронизации: таймауты, потеря уведомления, сбой сети. Механизм retry reconciliation периодически сравнивает статусы заказов вашей системы со статусами PSP и дотягивает отстающие.
Как настроить:
Сверяйте также фискализацию: интеграция по 54‑ФЗ и онлайн‑кассам должна иметь собственный retry и мониторинг, чтобы чек не потерялся.
Логи транзакций — ваша “чёрная коробка”. Без них невозможно доказать правоту в споре, отладить редкий баг или пройти аудит.
Что логировать:
Метрики для мониторинга отказов:
Алерты:
Мы помогаем настроить и проверить интеграции:
![Схема потока: пользователь → виджет/редирект → PSP → вебхуки → очередь → обработчик → БД → фискализация/ERP, с ретраями и идемпотентностью]
Кратко: фронт инициирует платёж, бекенд создаёт платёж с Idempotency-Key, пользователь проходит 3DS/СБП, PSP шлёт вебхук, ваш обработчик в очереди валидирует подпись, идемпотентно меняет статус, запускает фискализацию и фулфилмент. Параллельно работает retry reconciliation, который дотягивает подвисшие заказы.
Надёжная оплата — это не только кнопка «Оплатить», но и песочница PSP, правильные вебхуки, идемпотентность, ретраи и наблюдаемость. Пройдите чек-лист, включите мониторинг отказов и настройте retry reconciliation — и вы избежите большинства инцидентов в проде.
Нужна помощь с настройкой и тестированием? Откройте «Подключение платежной системы к сайту» или начните с выбора провайдера в «Сравнение провайдеров РФ». Если вы уже интегрируетесь — переходите к этой странице в закладки: «Тестирование, вебхуки и песочница» и действуйте по плану.