Описание
Шаблон запускается по Webhook при получении события о неуспешном платеже от платежного шлюза, но прямых готовых интеграций со Stripe, Shopify, PayPal или WooCommerce в составе нет. Данные приводятся к единому формату, затем логика классифицирует отказ как временный, постоянный или подозрительный. Для временных отказов отправляется письмо через Gmail со ссылкой на повторную оплату, дополнительно уходит уведомление в Slack и применяется задержка между попытками. Для постоянных и fraud-случаев retry-поток не запускается, вместо этого отправляется отдельное Slack-уведомление. Все случаи записываются в Supabase, поэтому на выходе бизнес получает уведомления, клиентские retry-email и таблицу событий для отчетности.
Как устроено
Ключевые ноды: Webhook для приема событий, Function для нормализации и классификации, Slack для внутренних оповещений, Gmail для писем клиентам, Wait для задержки и Supabase для логирования. Состояние retry реализовано через счетчик внутри выполнения и лимит попыток, что подходит для простого сценария, но может быть слабым местом без проверки фактического статуса платежа перед повторным письмом. Ошибки внешних сервисов описаны как настраиваемые вручную, явной централизованной error-ветки или компенсационной логики не видно. HITL отсутствует: fraud и hard decline только уведомляются, но не создают задачи на ручную проверку. AI-модели нет, несмотря на нерелевантную категорию AI Summarization.
Применение
- Повторные письма при временных отказах оплаты
- Оповещение Slack о подозрительных платежных отказах
- Журналирование failed payments в Supabase
- Разделение отказов оплаты на retryable, non-retryable и fraud
- Мониторинг неуспешных платежей по интернет-заказам