Recurring Payments Explained

A recurring payment is a payment that a merchant initiates on a schedule the customer agreed to in advance, without the customer being present for each charge. The customer signs up once, agrees to the amount or the billing rule, and then the merchant collects the money automatically, weekly, monthly, or yearly. Common examples include streaming subscriptions, software licences, insurance premiums, utility bills, and gym memberships. The key difference from a one-off payment is that the customer is absent at the moment of the transaction, so the payment system must rely on credentials stored from the first transaction rather than fresh input from the cardholder. Standing instructions are the mechanism that makes recurring payments possible in card payments. When a customer registers for a subscription, the merchant stores the card details, or more commonly a token that represents them, together with the mandate terms, such as the amount, the frequency, and the end date. This stored credential is called a credential on file. The first transaction is usually customer initiated and fully authenticated, often with 3D Secure, and it establishes the mandate. Every later transaction references that first transaction, which is how the issuer knows the charge is authorised even though the cardholder is not online. Recurring payments behave differently from one-off payments in almost every part of the payment chain. Authorisation rates are lower because issuers apply different risk rules to merchant initiated transactions. There is no cardholder to retry a failed authentication, so a decline is final unless the merchant has a retry process. The merchant must also handle the full lifecycle of the mandate, including changes to the card, cancellations, pauses, and price changes. A one-off payment is a single event, but a recurring payment is a relationship that can last for years, and the system must manage every state change in that relationship correctly. The most common failure modes in recurring payments are easy to list but hard to eliminate. Cards expire, and the stored credential stops working. Customers do not have enough money in the account on the billing date. The issuer declines the transaction because its fraud rules flag an unusual pattern. The card is reported lost or stolen and replaced, which breaks the stored credential. The customer cancels the mandate but the merchant keeps charging, which creates disputes and chargebacks. Each of these failures costs the merchant revenue and trust, and the difference between a good subscription business and a poor one is often just how well it handles these failures. From a business analyst perspective, recurring payments are a rich area because they touch almost every system a merchant owns. The BA must document the mandate setup journey, the billing engine rules, the retry logic, the dunning communication schedule, the cancellation flow, and the reporting that finance needs for revenue recognition. The BA also works with the payment gateway, the card schemes, and the acquiring bank to understand which transaction flags must be sent, such as the stored credential indicator and the scheme reference identifier. Getting these details wrong means failed payments, so precision in the requirements matters more here than in many other payment flows. For example, a customer signs up for a streaming subscription that costs 499 rupees a month. The first payment is authenticated by the customer with a one-time password, and the merchant stores a token for the card. Each month after that, the merchant charges 499 rupees using the stored token, without asking the customer to type the card details again. If the customer cancels, the merchant must stop charging at once, and the next billing date must show as cancelled in the customer account.