Recurring Payment Cycle: Mermaid Flowchart

Recurring Payment Cycle flowchart diagram

About Source

The recurring payment cycle is the operational loop that billing systems execute on every renewal interval — typically triggered by a scheduled job. It is the lower-level mechanical process underneath the higher-level subscription lifecycle.

The cycle begins when a scheduler wakes at a configured interval and queries for subscriptions whose next billing date is on or before the current date. These subscriptions are loaded into a processing queue to decouple the scheduling from the charging work. Each subscription is processed independently to prevent a single payment failure from blocking others.

For each subscription in the queue, the system fetches the associated stored payment method token — never the raw card data, which should never be persisted — and constructs a charge request for the renewal amount. The charge is submitted to the payment gateway. On success, the invoice is marked paid, the next billing date is calculated by adding one billing interval, and the subscription record is updated. A renewal confirmation is sent to the customer.

On failure, the system records the attempt, increments the failure counter, and schedules the next retry based on the dunning configuration. The subscription status may be updated to past_due to surface the issue in the merchant dashboard without immediately revoking access.

A critical implementation detail: all database state changes (marking an invoice paid, advancing the billing date) must be performed atomically, ideally in a single transaction. A crash between charging and updating the database could result in a double-charge on the next run if the idempotency key is not correctly managed. Payment gateways support idempotency keys for exactly this reason — passing the same key on a retry returns the original result without charging again. The full retry scheduling logic is detailed in Payment Retry Logic.

Frequently asked questions

The recurring payment cycle is the automated loop a billing system runs on each renewal interval. A scheduler identifies subscriptions due for billing, submits charges through the payment gateway, updates invoice and subscription state, and queues notifications for the customer.

A cron job or event-driven scheduler queries for subscriptions whose next billing date is on or before today. Each subscription is pushed onto a processing queue, charged independently using the stored payment method token, and its billing date advanced by one interval on success. Failures increment a counter and schedule a retry.

Always. Mark the invoice paid and advance the billing date in a single database transaction. A crash between the successful gateway response and the database write can cause a double-charge on the next run if the idempotency key is not correctly persisted before the charge is submitted.

mermaid

flowchart TD
    A([Scheduler triggers billing job]) --> B[Query subscriptions due for renewal]
    B --> C{Any subscriptions found?}
    C -->|No| Z([End — nothing to process])
    C -->|Yes| D[Load subscriptions into processing queue]
    D --> E[Dequeue next subscription]
    E --> F[Fetch stored payment method token]
    F --> G[Calculate renewal amount]
    G --> H[Submit charge to payment gateway with idempotency key]
    H --> I{Charge result}
    I -->|Success| J[Mark invoice as paid]
    J --> K[Calculate next billing date]
    K --> L[Update subscription record atomically]
    L --> M[Send renewal confirmation to customer]
    M --> N{More subscriptions in queue?}
    I -->|Failure| O[Record failed attempt]
    O --> P[Increment failure counter]
    P --> Q[Schedule next retry]
    Q --> R[Update status to past_due]
    R --> N
    N -->|Yes| E
    N -->|No| Z