Когда подключаешь Stripe впервые, кажется, что документация покрывает всё. Но именно в деталях интеграции прячутся расходы, которые не бросаются в глаза до первого счёта.
Повторные вебхуки без идемпотентности
Stripe отправляет вебхук несколько раз, если не получает ответ 200 в течение нескольких секунд. Если сервер медлит, одно событие payment_intent.succeeded обрабатывается дважды. Результат — двойное начисление бонусов, дублирование заказов, ручная корректировка. Решение простое: сохраняй stripe_event_id в базе и проверяй перед обработкой.
Запросы без кэша на статичные данные
Некоторые команды делают запрос к Stripe API при каждом рендере страницы с тарифами — чтобы показать актуальные цены. Stripe считает запросы, и при высоком трафике это влияет на лимиты и производительность. Достаточно кэшировать ответ на 10–15 минут через Redis или простой in-memory кэш.
Лишние поля в метаданных
Разработчики иногда пишут в metadata полные объекты пользователя — имя, адрес, история заказов. Stripe хранит это, но объём метаданных ограничен. Когда данные не помещаются, запрос падает с ошибкой, которую обрабатывают через retry-логику. Каждый retry — это лишний API-вызов. Храни в metadata только id записи из своей базы.
Эти три паттерна встречаются в большинстве первых интеграций. Исправить их занимает пару часов, а экономия на поддержке и ручных правках ощутима уже в первый месяц.