Recurring Payment Integration: Tokenization & Dunning Strategy

Recurring payment subscriptions make income predictable. But up to 30% of recurring transactions fail: expired cards, insufficient funds, bank blocks. Without automatic failure handling, you lose up to 15% of subscription revenue. For a monthly turnover, that's a tangible loss. Integrating recurring payments with tokenization and a dunning strategy recovers up to 80% of failed charges. We have implemented such systems for Stripe and CloudPayments on projects with thousands of subscribers. Experience: 10+ years in payment processing and over 50 subscription projects. Get a consultation on integration today.

How to implement recurring payment integration using tokenization?

Tokenization means storing payment data as a token at the gateway. The first payment requires user involvement; subsequent ones are server-initiated. Stripe uses SetupIntent for securely collecting card details, then creates a PaymentIntent with off_session: true to charge without 3DS. This is the standard approach in Stripe documentation.

Server — saving the payment method

\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]); 

Server — subsequent charges without user interaction

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); } } } 

Why do up to 30% of payments fail?

The main reasons: expired card, insufficient funds, bank fraud monitoring, technical errors. With manual handling, each failure is lost revenue. An automatic retry strategy (dunning) recovers most of these payments. For example, on our cloud service projects, after implementing dunning, the failure rate dropped from 25% to 8%.

Handling failed charges

Failures are normal for recurring payments. We apply dunning with exponential backoff: first retry after 1 day, second after 3 days, third after 7 days. If after three attempts the charge still fails, the subscription status changes to past_due, and the client receives an email to update their card. Additionally, a dunning process starts — a series of 3-5 reminders. Here is an example class:

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 — a ready-made solution

If you don't want to manage schedules yourself, Stripe Billing does it for you. Simply create a product and price, then a subscription. Webhooks handle all events: successful payments, failures, renewals. Stripe Billing is implemented 2x faster than custom tokenization and reduces server load.

\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'], ]); 

The webhook handler should listen for invoice.payment_succeeded, invoice.payment_failed, and customer.subscription.updated events. Each event updates the subscription status in your local DB. It is important to handle duplicate notifications idempotently — check by Stripe Event ID. For testing, use Stripe CLI with stripe listen --forward-to localhost/webhook.

Which approach to choose: tokenization or Subscription API?

The choice between tokenization and Subscription API determines the level of control and development speed. Tokenization gives full control over scheduling and data but requires more code and testing. Subscription API simplifies subscription management by relying on the gateway but ties you to it and limits flexibility.

Comparison of tokenization and Subscription API

Get a consultation on choosing the right approach for your business.

What is included in the work

• Documentation: API specification of the integration, description of webhook events, subscription database schema.
• Access: environment setup (dev/staging/prod), creating gateway accounts, configuring webhook secrets.
• Training: knowledge transfer to your team, demonstration of the admin panel for subscription management.
• Support: 1 month warranty service after delivery, bug fixes via hotfix.

Process

1. Analysis — we study your business logic, charge frequency, and dunning requirements.
2. Design — we choose the stack (Stripe, CloudPayments), tokenization model or Subscription API.
3. Implementation — integrating the payment gateway, creating subscription tables, webhook handlers, jobs.
4. Testing — verifying payments, failures, grace periods, retry attempts.
5. Deployment and monitoring — setting up alerts, logging errors, updating documentation.

Contact us to discuss the details of your project.

Timelines and cost

Basic integration with one gateway takes from 3 to 6 weeks. If you need complex billing cycles, multiple gateways, or non-standard retry strategies, the timeline increases to 8–10 weeks. Cost is calculated individually.

Order a turnkey recurring payment integration — we guarantee reliability and transparency at every stage.