Overview
Recurring payments represent a transaction model where a customer authorizes a merchant to charge their payment method multiple times, either at scheduled intervals or based on predefined business rules.
Unlike one-off payments, recurring payments separate the initial authorization from future charges. The first interaction typically establishes consent and payment credentials, allowing subsequent transactions to occur without repeated customer interaction.
This model is commonly used in subscription services, memberships, installment plans, and ongoing service agreements.
What Is a Recurring Payment
A recurring payment is a transaction model where:
- The customer authorizes future charges
- The merchant may initiate subsequent transactions
- Charges occur according to a schedule or trigger
- Payment credentials or authorization are reused
From a technical perspective, recurring payments involve:
- An initial setup transaction
- Credential or mandate storage
- Future merchant-initiated transactions
The customer interaction is required only during the setup phase.
When to Use Recurring Payments
Recurring payments are appropriate when payments are not isolated events but part of an ongoing commercial relationship.
Typical scenarios include:
- Subscription-based services
- Software-as-a-Service (SaaS)
- Membership platforms
- Utilities and telecom services
- Installment or financing plans
- Donation programs
They are not intended for single, isolated purchases.
Supported Payment Methods
Within the SIBS ecosystem, recurring payments are supported through:
- Credit Cards (card-on-file model)
- MB WAY Authorized Payments
Each method implements recurring logic differently but follows the same conceptual model: initial authorization + subsequent merchant-initiated transactions.
Execution Models
Although the conceptual model is similar, execution differs by payment method.
Credit Card Recurring (Card-on-File)
The customer provides card details during the first transaction.
The card is tokenized and stored securely.
Subsequent charges are initiated by the merchant using the stored token.
Characteristics:
- Initial customer authentication (may involve 3DS)
- Token generation and storage
- Merchant-initiated recurring charges
- Possible soft declines requiring re-authentication
MB WAY Authorized Payments
The customer grants authorization within the MB WAY application for future payments.
Once authorized:
- The merchant can initiate future payments
- Customer interaction is not required for each charge
- Authorization scope and limits may apply
Characteristics:
- Mobile-based authorization flow
- Explicit consent for recurring charges
- Merchant-triggered subsequent transactions
Transaction Lifecycle
Recurring payments follow a multi-stage lifecycle:
- Initial authorization / mandate creation
- Credential or authorization registration
- Recurring charge initiation
- Processing by financial network
- Final status (success, failed, declined)
Depending on the payment method, recurring charges may require periodic re-authentication.
Advantages of the Recurring Model
From a merchant and integration perspective, recurring payments provide:
- Revenue predictability
- Reduced customer friction
- Automated billing cycles
- Lower checkout abandonment after initial setup
- Support for subscription business models
This model enables scalable long-term commercial relationships.
Particularities in the SIBS Context
When working with recurring payments in SIBS SPG, several platform-specific aspects must be considered:
- Initial transaction may require strong customer authentication
- Subsequent charges are merchant-initiated
- Tokenization or authorization identifiers are required
- Decline handling logic must be implemented
- Mandate validity and cancellation scenarios must be managed
- Some recurring transactions may require re-authentication depending on regulatory requirements
Proper lifecycle handling is critical to ensure payment continuity.
Recurring vs Other Payment Models
To position recurring payments within the broader ecosystem:
| Model | Description |
|---|---|
| One-Off | Single, standalone payment |
| Recurring | Repeated charges using stored authorization |
| Tokenized One-Off | Single payment using stored credentials |
| Pre-Authorization | Two-step charge within one transaction |
This section focuses exclusively on recurring payments. Other models are covered in dedicated sections.
Integration Context
In the SIBS Payment Gateway, recurring payments typically require:
- An initial setup transaction (authorization phase)
- Secure storage of token or authorization reference
- Server-to-server merchant-initiated transactions
Recurring payments are not generally supported via simple hosted form-only flows without backend logic.
Detailed integration guidance is provided in the Integration Flows section.
Summary
Recurring payments extend the one-off model by introducing persistent authorization and merchant-initiated charging capabilities.
They enable subscription and installment business models while requiring additional lifecycle management and compliance considerations.
Understanding the conceptual structure of recurring payments is essential before implementing the technical integration.