Pending - это не ошибка, а промежуточное состояние
Платеж может требовать подтверждения, обработки банком, 3-D Secure или повторной доставки webhook.
Ошибка многих магазинов - воспринимать pending как сбой. На практике это нормальное состояние: клиент мог пройти 3-D Secure, банк может завершать авторизацию, callback может задержаться, а backend может ждать финальную проверку статуса.
Правильный ответ для сайта: заказ остается в pending payment, товар не выдается, CRM не закрывает сделку как paid, а система запускает повторную проверку по расписанию или ждет signed webhook. Клиенту нужно показать понятный экран: "Платеж проверяется, мы обновим статус автоматически".
- не переводить заказ в paid по browser redirect;
- не создавать новый заказ при каждом retry;
- хранить payment attempt отдельно от order status;
- показывать клиенту понятный промежуточный статус.
Как долго ждать финальный статус
Timeout должен быть бизнес-правилом, а не случайным числом в коде checkout.
Единого универсального времени ожидания нет: оно зависит от провайдера, метода оплаты, 3-D Secure, capture-логики и внутренних процессов. Но правило должно быть явным. Например, первые минуты система часто проверяет статус автоматически, затем переводит заказ в "требует проверки" или "истекло".
Важно не отменять заказ слишком рано, если провайдер еще может прислать успешный статус. И наоборот, нельзя бесконечно держать корзину и резерв товара, если платеж не завершился. Поэтому pending policy должна быть согласована с продажами, складом и поддержкой.
- первые проверки делать автоматически через backend;
- дальше создавать задачу поддержки или оператора;
- отдельно обрабатывать успешный webhook после истечения UI-сессии;
- логировать причину финального failed или expired.
Что должна видеть CRM и поддержка
Менеджеру нужен не raw provider status, а понятное действие: ждать, позвонить, повторить ссылку или закрыть заказ.
CRM должна получать нормализованный статус. Если платеж pending, менеджер должен видеть, когда была последняя проверка, какой provider reference, сколько попыток уже было и что делать дальше.
Для поддержки полезны готовые сценарии: если клиент говорит, что деньги списались, оператор проверяет provider reference и reconciliation queue, а не просит клиента оплатить еще раз без проверки. Это снижает риск двойной оплаты и конфликтов с клиентами.
- pending_check - система еще ждет финальный статус;
- action_required - клиент должен завершить шаг у банка;
- manual_review - нужен оператор или бухгалтерия;
- expired - ссылка или payment attempt больше не активны.
FAQ
Можно ли показывать клиенту кнопку "оплатить еще раз", если статус pending?
Можно, но новая попытка должна быть отдельным payment attempt, привязанным к тому же заказу. Перед этим желательно повторно проверить статус старой попытки.
Что делать, если клиент утверждает, что деньги списались, а сайт показывает pending?
Нужно проверить provider reference, статус у провайдера и reconciliation queue. Нельзя просить клиента платить повторно, пока старая попытка не разобрана.
Когда pending можно закрывать как failed или expired?
После явного ответа провайдера или после согласованного timeout, когда система еще раз проверила статус и сохранила причину финального решения.
Источники
- Stripe Documentation - PaymentIntents lifecycleОфициальное описание lifecycle платежа и промежуточных статусов вроде requires_action и processing.
- Stripe API Reference - PaymentIntentsСправочник по статусам PaymentIntent как пример формальной модели платежного lifecycle.
- Stripe Documentation - Webhook delivery behaviorДокументация по доставке webhook-событий, retries и отсутствию гарантии порядка событий.
