Credit Card recurring payments allow merchants to charge a customer’s card multiple times after an initial authorization and credential registration.

In a recurring payment scenario, the first transaction establishes customer consent and securely registers the card credentials (tokenization). Subsequent transactions are initiated by the merchant without requiring the customer to re-enter card details for each charge.

This model is commonly used for subscriptions, memberships, installment plans, and other ongoing billing relationships.

How It Works

In a typical Credit Card recurring payment flow:

1. The merchant initiates an initial setup payment through the SIBS Payment Gateway.
2. The customer provides card details through a secure payment form or hosted page.
3. The transaction is sent to the acquiring network for authorization.
4. Strong Customer Authentication (e.g., 3D Secure) is applied when required.
5. Upon successful authorization, a payment token or recurring reference is generated.
6. The merchant stores the recurring reference securely.
7. Future charges are initiated by the merchant using the stored reference.
8. Each recurring charge is processed through the acquiring network.
9. The final transaction result is returned to the merchant system.

The initial customer interaction is mandatory. Subsequent recurring transactions are merchant-initiated.

Workflow Characteristics

The Credit Card recurring flow has the following characteristics:

• Initial customer authentication (when required)
• Secure tokenization of card credentials
• Merchant-initiated subsequent charges
• Possible soft declines requiring re-authentication
• Real-time authorization response for each charge
• No need for card re-entry after initial setup
• Subsequent recurring collections are processed as Merchant Initiated Transactions (MITs), using the original Cardholder Initiated Transaction reference
• Merchants should implement retry and customer re-authentication handling strategies for recurring transactions that are declined due to issuer authentication requirements.

Recurring charges may require additional authentication depending on regulatory or issuer requirements.

Transaction Lifecycle

The lifecycle of a Credit Card recurring payment typically includes:

• Initial payment creation (setup phase)
• Authentication and authorization (if required)
• Token or recurring reference generation
• Merchant-initiated recurring charge
• Authorized and captured (successful)
• Declined or failed (per charge attempt)

If a recurring charge is declined, retry logic or customer re-authentication may be required.

Use Cases

Credit Card recurring payments are commonly used in:

• Subscription-based services (SaaS, streaming, memberships)
• Installment payment plans
• Utility and telecom billing
• Insurance premium payments
• Donation programs

This payment model is particularly suited for environments where:

• Automated billing cycles are required
• Customers expect frictionless recurring payments
• Revenue predictability is important
• Ongoing service delivery depends on periodic payment

Particularities in the SIBS Context

When working with Credit Card recurring payments in SIBS SPG, merchants should consider:

• Initial customer authentication may require Strong Customer Authentication (3D Secure).
• Recurring collections are merchant-initiated and may still be subject to issuer validation rules.
• Soft declines may require customer re-authentication before collection can proceed.
• Each recurring collection is processed as an independent transaction with its own authorization result and transaction lifecycle.
• Operational reconciliation should correlate recurring collections with the originating Cardholder Initiated Transaction reference.
• Proper retry handling and monitoring of failed recurring collections is essential to maintain service continuity.

Integration Context

Within the SIBS Payment Gateway, Credit Card recurring payments are implemented using:

• An initial customer-authorized transaction
• Cardholder Initiated Transaction reference registration and optional tokenization
• Server-to-server merchant-initiated recurring transactions

Each recurring charge is processed independently and returns its own authorization response.

Merchants remain responsible for the secure storage, lifecycle handling, and controlled usage of recurring references or tokens obtained during the authorization process.

The following sections describe the technical integration flow, credential handling, recurring charge initiation, and decline management for Credit Card recurring payments.

The SPG transactionID should be treated as the primary identifier for transaction monitoring, recurring charge monitoring, webhook correlation, reconciliation, and Status Inquiry operations throughout the lifecycle of Credit Card recurring payments.

For webhook delivery behavior and asynchronous transaction notifications, refer to E.1 – Webhooks (Notifications).

For complete Status Inquiry endpoint specifications and response interpretation, refer to E.2 – Status Inquiry / Get Status.

Practical Credit Card recurring payment examples, tokenization workflows, recurring collection scenarios, Postman collections, and operational testing examples are documented in F. Technical Examples and Best Practices.