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
- Stored payment credentials or authorization references are reused
From a technical perspective, recurring payments involve:
- An initial setup transaction
- Credential or mandate storage
- Future merchant-initiated transactions
Within SPG, subsequent recurring charges are typically executed as Merchant Initiated Transactions (MIT), following an initial customer-authorized setup transaction.
Customer interaction is typically required during the setup phase, while subsequent recurring charges are initiated by the merchant according to the authorized payment model.
Each recurring operation executed through SPG generates its own transactionID and independent transaction lifecycle.
The SPG transactionID should be treated as the authoritative identifier for transaction monitoring, webhook correlation, reconciliation, recurring charge tracking, refund operations, and Status Inquiry requests.
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
The following diagram illustrates the generic operational lifecycle commonly followed by Recurring payment transactions in SPG.
Recurring payments follow a multi-stage lifecycle:
- Initial customer authorization or mandate creation
- Credential, token, or authorization registration
- Merchant-initiated recurring charge request
- Processing by SPG and financial network partners
- Transaction state progression (processing, authorized, declined, failed, expired, or completed)
- Final transaction confirmation through synchronous response, webhook notification, and/or Status Inquiry validation
Depending on the payment method, recurring charges may require periodic re-authentication.
For transaction lifecycle monitoring and recurring charge validation, refer to E.2 – Status Inquiry / Get Status.
For webhook delivery and asynchronous recurring transaction notifications, refer to E.1 – Webhooks (Notifications).
Practical implementation examples, Postman collections, recurring flow scenarios, and Merchant Initiated Transaction examples are documented in F. Technical Examples and Best Practices.
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
- Recurring payment implementations must correctly manage customer consent, mandate lifecycle, tokenization, and regulatory authentication requirements
Proper lifecycle handling is critical to ensure payment continuity.
For detailed token lifecycle examples and Merchant Initiated Transaction flows, refer to F.1 – End-to-End Integration Examples and F.2 – Annotated Requests and Responses.
Recurring vs Other Payment Models
To position recurring payments within the broader ecosystem:
| Model | Description |
|---|---|
| One-Off | Single, standalone payment |
| Recurring | Repeated merchant-initiated charges using stored authorization or payment credentials |
| Tokenized Payments | Payments executed using previously stored payment credentials, potentially supporting both One-Off and recurring transaction models |
| Pre-Authorization | Two-step operational variant where funds are authorized initially and captured later |
This section focuses exclusively on recurring payments. Other models are covered in dedicated sections.
For standalone transaction flows without credential reuse or merchant-initiated charging, refer to D.1 – One-Off Payments.
For authorization and delayed capture flows, refer to D.3 – Two-Step Payments.
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 payment implementations generally require backend processing capabilities to manage token storage, recurring charge execution, and transaction lifecycle handling.
Detailed implementation guidance for each recurring payment method and integration approach is provided in the corresponding D.2.x payment method sections and in B. Integration Models.
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.