Recurring payments: how they work and how to cut failed charges

What are recurring payments?

A recurring payment has two parts. The first payment is made by the customer, authenticated and used to set up a mandate or stored credential. Every later payment is initiated by the merchant using that credential. Card schemes, direct debit schemes and wallets each have their own rules for how this consent is captured and referenced.

Recurring billing vs subscription payments vs instalments

Business-model questions such as pricing tiers, trials and churn are covered in our subscription payments guide. This page covers the payment mechanics.

Customer-initiated vs merchant-initiated transactions

A customer-initiated transaction (CIT) happens with the customer in session. A merchant-initiated transaction (MIT) happens without them, based on an earlier agreement.

• The first payment in a series is a CIT. In the EEA it normally needs strong customer authentication, usually via 3-D Secure 2.
• Later charges are flagged as MIT and reference the original transaction ID. Under the EBA's SCA rules, MITs are generally outside the SCA requirement because the customer is not present (EBA).
• Missing or wrong MIT flags are a common reason for soft declines on renewals.

Card on file and network tokens

Card on file means storing the card credential (as a token, never as raw card data in your own systems) with the customer's consent to charge it later. Card networks publish a stored-credential framework that defines how the first and following transactions must be labelled.

Network tokens replace the card number with a scheme-issued token that is updated automatically when the card is reissued. That can reduce declines from expired or replaced cards. See our network tokenization guide.

Why recurring charges fail

Examples:

• Soft declines: insufficient funds, issuer temporarily unavailable, "do not honour". These can often succeed on a later retry.
• Hard declines: card closed, stolen or invalid account. Do not retry; ask the customer for a new payment method.
• Expired or reissued cards: often addressed by account updater services or network tokens.
• Authentication requested: the issuer asks for SCA on an MIT. Bring the customer back into session.

Retry and dunning logic

Steps:

1. Read decline codes Read the decline reason code before retrying. Scheme rules limit retries on the same card, and repeated retries on hard declines can lead to fees.
2. Space retries Space retries out (for example, a few days apart, or around typical pay dates).
3. Dunning and payment update Send a dunning message with a payment-update link after the first failure.
4. Route soft declines Where you have more than one provider, route the retry to another acquirer for soft declines (see payment cascading).
5. Measure by reason Track recovery rate per reason code, not one global number.

Recurring payments with alternative payment methods

Card is not the only option. SEPA Direct Debit uses a mandate and suits B2B and utilities in the euro area. Wallets such as PayPal use billing agreements. Local methods vary: BLIK has recurring flows, iDEAL is used together with a SEPA mandate. Compare options on our payment methods hub.

How OrsunPay helps with recurring payments

OrsunPay is a payment orchestration platform that connects the providers you already use behind one API; it does not process or hold funds itself. For recurring billing you can route renewals and retries across connected providers with smart routing, see declines by reason code in one place, and score the first payment with RiskCogs before you store the credential. Plans are on the pricing page.