Recurring payments: tokens, merchant-initiated transactions and retries that keep subscriptions paid
A recurring payment is a charge without the payer present: the card was stored once as a token, the first payment was authenticated, and every next one is a merchant-initiated transaction under the schemes' rules. The work is in the details: tokens that survive a change of acquirer, retries that do not harm the merchant's standing, expired cards updated without asking the payer, and local methods that have their own mandates.
How it works on the platform
- The payer pays once on the checkout with 3-D Secure; the card goes into the vault and the merchant receives a token.
- The merchant creates the next payment with the token through the API, marked as merchant-initiated, with the subscription’s reference.
- Routing picks the acquirer as for any payment; a cascade applies to soft declines within the schemes’ limits.
- The result is journaled and sent by webhook; the merchant’s subscription system updates its state.
Customer-initiated, merchant-initiated
The schemes distinguish a payment the customer makes in person, on a checkout with authentication, from a payment the merchant charges later under an agreement: a subscription, an instalment, an unscheduled top-up. The first must be authenticated and establishes the agreement; the later ones carry the indicator of a merchant-initiated transaction and a reference to the first, which is what lets them go through without the payer and without 3-D Secure. The platform sets the indicators and keeps the references, so a merchant that creates a payment with a token and marks it recurring gets the scheme’s rules applied without reading them.
The details that decide the retention
- Retries on a schedule, with the reason of the decline deciding whether to retry at all.
- Decline events by webhook so the merchant can write to the payer before the subscription lapses.
- Amount changes within what the first mandate allowed; a larger amount starts a new authenticated payment.
- The journal of every charge, its attempts and the acquirer that approved it, per merchant in the cabinet.
- Expiry checks every hour in the vault, with a webhook that tells the merchant which subscriptions need a new card before the next charge.
Which declines to retry
| Decline | Retry | How |
|---|---|---|
| Insufficient funds | yes, on a schedule | Later in the month, within the schemes’ limits on reattempts |
| Issuer unavailable, timeout, acquirer error | yes, soon | A cascade to another acquirer that holds the token, or the same acquirer later |
| Expired card | after an update | The payer’s new card; the vault flags the expiry in advance |
| Do not honour with a hard reason, lost or stolen card | no | The merchant writes to the payer; the token is retired |
| Cardholder’s cancellation of the agreement | no | The merchant stops the subscription; a charge after a cancellation becomes a chargeback |
The schemes count reattempts of declined transactions and penalise excessive ones; the platform caps the attempts per payment and stops on hard declines, and the journal shows every attempt with its reason.
Local alternatives
Cards are not the only way to charge again. UPI mandates in India give subscription merchants a rail without card declines, enabled with the providers that offer them, with the same webhooks and reports; SEPA direct debit and variable recurring payments over Open Banking are planned for the catalogue. Wallets with stored agreements, where the provider offers them, follow the same model.
For a PSP with subscription merchants
The vault, the indicators and the retry rules are the platform’s; the PSP enables the acquirers, sets the retry limits per merchant and watches the renewal rates in the back office. A merchant moving to the PSP from another platform re-tokenises its cards on the first successful payment where the acquirer allows it; the migration page describes the path.
Updated: 2026-11-08