Интеграция рекуррентных платежей: токенизация и dunning стратегия

Автоматические списания по подпискам делают доход от подписок стабильным. Но до 30% рекуррентных платежей отклоняются: карты просрочены, не хватает средств, банк блокирует операцию. Без автоматической обработки отказов вы теряете до 15% выручки от подписок. При ежемесячном обороте это ощутимые потери. Интеграция рекуррентных платежей с токенизацией и dunning стратегией возвращает до 80% неудачных списаний. Мы реализовали такие системы для Stripe и CloudPayments в проектах с тысячами подписчиков. Опыт — 10+ лет в обработке платежей и более 50 проектов с подписками. Получите консультацию по интеграции уже сегодня.

Как реализовать интеграцию рекуррентных платежей с помощью токенизации?

Токенизация — сохранение платёжных данных в виде токена у шлюза. Первый платёж проходит с участием пользователя, последующие инициирует сервер. Stripe использует SetupIntent для безопасного сбора карты, затем PaymentIntent с параметром off_session: true для списания без 3DS. Это стандартный подход в документации Stripe.

Сервер — сохранение метода оплаты

\Stripe\Stripe::setApiKey(config('services.stripe.secret')); $stripeCustomer = \Stripe\Customer::create([ 'email' => $user->email, 'metadata' => ['user_id' => $user->id], ]); $user->update(['stripe_customer_id' => $stripeCustomer->id]); $setupIntent = \Stripe\SetupIntent::create([ 'customer' => $user->stripe_customer_id, 'usage' => 'off_session', 'automatic_payment_methods' => ['enabled' => true], ]); return response()->json(['clientSecret' => $setupIntent->client_secret]); 

Сервер — последующее списание без участия пользователя

public function chargeRecurring(User $user, int $amountCents): void { \Stripe\Stripe::setApiKey(config('services.stripe.secret')); $paymentMethod = $user->default_payment_method_id; try { $paymentIntent = \Stripe\PaymentIntent::create([ 'amount' => $amountCents, 'currency' => 'usd', 'customer' => $user->stripe_customer_id, 'payment_method' => $paymentMethod, 'confirm' => true, 'off_session' => true, 'description' => "Subscription - {$user->id}", ]); if ($paymentIntent->status === 'succeeded') { $this->recordSuccessfulCharge($user, $paymentIntent); } } catch (\Stripe\Exception\CardException $e) { $this->handleFailedCharge($user, $e->getError()->decline_code); } catch (\Stripe\Exception\InvalidRequestException $e) { if ($e->getStripeCode() === 'authentication_required') { $this->sendAuthenticationEmail($user, $e->getError()->payment_intent->id); } } } 

Почему до 30% платежей отклоняются?

Основные причины: истекший срок действия карты, недостаток средств, банковский фрод-мониторинг, технические сбои. При ручной обработке каждый отказ — потерянный доход. Автоматическая стратегия повторов (dunning) позволяет вернуть большую часть этих платежей. Например, у нас на проектах с облачным сервисом после внедрения dunning отказ снизился с 25% до 8%.

Обработка неудачных списаний

Неудачи — норма для рекуррентных платежей. Применяем dunning с экспоненциальной задержкой: первая попытка через 1 день, вторая через 3 дня, третья через 7 дней. Если после трёх попыток списание не проходит, подписка переводится в статус past_due, клиент получает письмо с просьбой обновить карту. Дополнительно запускается dunning-процесс — серия из 3-5 напоминаний. Вот пример класса для обработки:

class RecurringChargeJob implements ShouldQueue { public int $tries = 3; public function backoff(): array { return [86400, 259200, 604800]; } public function handle(): void { $subscription = Subscription::find($this->subscriptionId); if ($subscription->failed_attempts >= 3) { $subscription->update(['status' => 'past_due']); Mail::to($subscription->user)->send(new PaymentFailedMail($subscription)); return; } try { app(RecurringPaymentService::class)->charge($subscription); $subscription->update([ 'failed_attempts' => 0, 'status' => 'active', 'next_charge_at' => now()->addMonth(), ]); } catch (PaymentFailedException $e) { $subscription->increment('failed_attempts'); throw $e; } } } 

Stripe Billing — готовое решение

Если управлять расписанием самостоятельно не хочется, Stripe Billing делает это за вас. Просто создайте продукт и цену, затем подписку. Webhook обработает все события: успешные платежи, сбои, продления. Stripe Billing реализуется в 2 раза быстрее, чем собственная токенизация, и снижает нагрузку на сервер.

\Stripe\Stripe::setApiKey(config('services.stripe.secret')); $product = \Stripe\Product::create(['name' => 'Pro Plan']); $price = \Stripe\Price::create([ 'unit_amount' => 2900, 'currency' => 'usd', 'recurring' => ['interval' => 'month'], 'product' => $product->id, ]); $subscription = \Stripe\Subscription::create([ 'customer' => $user->stripe_customer_id, 'items' => [['price' => $price->id]], 'payment_behavior' => 'default_incomplete', 'expand' => ['latest_invoice.payment_intent'], ]); 

Webhook-обработчик должен слушать события invoice.payment_succeeded, invoice.payment_failed, customer.subscription.updated. Каждое событие обновляет статус подписки в локальной БД. Важно идемпотентно обрабатывать повторные уведомления — проверять по Stripe Event ID. Для тестирования используйте Stripe CLI с командой stripe listen --forward-to localhost/webhook.

Какой подход выбрать: токенизация или Subscription API?

Выбор между токенизацией и Subscription API определяет уровень контроля и скорость разработки. Токенизация даёт полный контроль над расписанием и данными, но требует больше кода и тестирования. Subscription API упрощает управление подписками за счёт шлюза, но привязывает к нему и ограничивает гибкость.

Сравнение токенизации и Subscription API

Получите консультацию по выбору подхода для вашего бизнеса.

Что входит в работу

• Документация: API-спецификация интеграции, описание webhook-событий, схема базы данных подписок.
• Доступы: настройка окружений (dev/staging/prod), создание аккаунтов шлюзов, настройка webhook-секретов.
• Обучение: передача знаний команде, демонстрация админ-панели управления подписками.
• Поддержка: гарантийное обслуживание 1 месяц после сдачи, исправление багов по hotfix.

Процесс работы

1. Аналитика — изучаем вашу бизнес-логику, частоту списаний, требования к dunning.
2. Проектирование — выбираем стек (Stripe, CloudPayments), модель токенизации или Subscription API.
3. Реализация — интеграция платёжного шлюза, создание таблицы подписок, webhook-обработчики, джобы.
4. Тестирование — проверка оплаты, отказов, grace-периодов, повторных попыток.
5. Деплой и мониторинг — настройка алертов, логирование ошибок, обновление документации.

Свяжитесь с нами для обсуждения деталей вашего проекта.

Сроки и стоимость

Базовая интеграция с одним шлюзом — от 3 до 6 недель. Если нужны сложные биллинг-циклы, несколько шлюзов или нестандартные стратегии повторов — срок увеличивается до 8–10 недель. Стоимость рассчитывается индивидуально.

Закажите интеграцию рекуррентных платежей под ключ — мы гарантируем надёжность и прозрачность на всех этапах.