A recurring payment is easier to understand as a sequence of states than as a repeated transaction.
The commercial record comes first. Payment attempts happen against it. Finance work continues after the customer has paid.
The lifecycle at a glance
Recurring rule → Due invoice → Payment attempt → Provider state → Paid or Recovery → Reconciled → Settlement evidence
1. Recurring rule
The merchant defines what repeats: amount or pricing rule, frequency, billing date, grace policy and service consequence.
2. Due invoice
When the next period arrives, the billing system creates one commercial record for what the customer owes.
3. Payment attempt
The customer chooses an enabled payment method, or the merchant initiates an approved payment flow. The attempt gets its own ID and provider references.
4. Provider state
The payment may be awaiting customer action, pending, successful, failed, expired or unresolved. The raw provider result is preserved and mapped to an internal state.
5A. Paid
Sufficient provider evidence confirms success. The invoice closes once, collection messages stop and downstream service logic can react.
5B. Recovery
If the invoice remains due, recovery may send a reminder, allow a new attempt, offer another enabled method or wait while an unresolved payment is verified.
6. Reconciled
Finance matches the successful payment to the invoice and provider evidence. The customer can already be Paid while reconciliation is still Pending.
7. Settlement evidence
The merchant or finance team records the settlement information supplied under its provider relationship. Payment success and settlement are not the same event.
One invoice can have several attempts
A failed or expired attempt does not create another commercial obligation. The same invoice remains due until it is paid, adjusted, cancelled or otherwise satisfied.
Why this lifecycle matters
Keeping these stages separate prevents three common errors: retrying an unresolved payment, treating a payment request as payment success, and keeping customer collection open while finance is merely waiting for reconciliation or settlement evidence.
For implementation detail, use the dedicated guides on payment state, recovery and reconciliation rather than expanding this lifecycle page into a technical reference.
The two checkpoints that prevent most mistakes
Before creating a new attempt, check whether the invoice is still due and whether an earlier attempt is unresolved. Before changing customer access, check whether the invoice state is final enough to justify the action. Those two checkpoints keep the payment cycle from turning provider timing into business policy.
They also explain why the lifecycle is not a straight line. A customer can move from recovery back to a successful payment, and finance can keep reconciling after the customer-facing cycle is already complete.
