Prerequisites (once per merchant/environment)

You need the following credentials and configuration elements before calling the SIBS SPG APIs:

• AuthToken : used as Authorization: Bearer <AuthToken> for REST calls
• TerminalId : the terminal ID assigned to the merchant, by the SIBS OnBoarding team
• X-IBM-Client-Id : merchant application identifier assigned by the SIBS OnBoarding team

Choose the correct environment root URL for the target environment.

Please refer to the API Requests documentation page for more.

Prerequisites (Recurring Model Requirements)

The merchant must have a successful Customer Initiated Transaction (CIT), including:

• transactionID from the original CIT Transaction
• transactionDateTime from the original CIT Transaction
• Customer consent for recurring payments

Important: MIT transactions are only valid if derived from a compliant CIT (with SCA when required).

Dependency on CIT

Recurring collections (MIT) can only be performed after a successful Customer Initiated Transaction (CIT).

If the original CIT is not valid or not compliant (e.g., missing SCA when required), the MIT transaction will be rejected.

Recurring Payment Model

Recurring payments are performed using Merchant Initiated Transactions (MIT), executed server-to-server by the merchant.

The recurring payment flow follows:

1. CIT (Authorization) → customer-present
2. MIT → recurring transaction creation
3. CAPTURE → funds transfer

Each step must be executed and validated independently.

A MIT transaction is initiated by the merchant using a previously authorized card from a Customer Initiated Transaction (CIT).

A MIT is not a customer-present authorization and does not perform Strong Customer Authentication (SCA).

Requirements:

• A successful initial CIT transaction must exist
• The original transaction must provide:
  • originalTransaction.id
  • originalTransaction.datetime

Important:

• The customer is not involved in MIT transactions
• Strong Customer Authentication (SCA) is not triggered during MIT

API Request Flow

In a Recurring Credit Card Collection flow, the process is divided into:

1. Create the recurring MIT transaction (server-to-server)
2. Process the MIT response
3. Capture the MIT transaction (server-to-server)
4. Confirm the final transaction result using the Status API

The recurring collection is only considered completed after the capture is successful and the final result is confirmed through the Status API

This page only covers the recurring collection phase.

The initial recurring customer authorization flow is documented in:

• Recurring Payments – Credit Card Authorization [Form Integration]
• Recurring Payments – Credit Card Authorization [Server-to-Server Integration]

depending on the type of integration you choose

1) Create MIT transaction (server-to-server)

Goal: Create a Merchant Initiated Transaction (MIT) using a previously authorized Customer Initiated Transaction (CIT).

This request creates the recurring collection transaction that will later be captured.

The MIT request prepares the transaction but does not reserve or transfer funds. Funds are only transferred after a successful CAPTURE operation.

What you do

1.1 POST MIT Payment to:

curl -X POST "https://api.qly.sibspayments.com/sibs/spg/v2/payments/<transactionID>/mit" \
  --header "Authorization: Bearer <AuthToken>" \
  --header "X-IBM-Client-Id: <ClientId>" \
  --header "Content-Type: application/json" \
  --header "Accept: application/json" \
  --data '{
    "merchant": {
        "terminalId": "{{terminalId}}",
        "merchantTransactionId": "71e1316fc799477c8aa9a27269d11190",
        "channel": "web"
    },
    "transaction": {
        "transactionTimestamp": "{{currentDateTime}}",
        "description": "{{transaction short description}}",
        "type": "RCRR",
        "amount": {
            "value": {{amount}},
            "currency": "EUR"
        },
        "originalTransaction": {
            "id": "{{originaltransactionID}}",
            "datetime": "{{originalDateTime}}"
        }
    }
}'

Where:

• <transactionID> must reference the original successful CIT transaction.
• for recurring collections, transaction.type must be “RCRR".
• must reference the original successful CIT transaction using:
  • originalTransaction.id : Identifier of the original CIT transaction
  • originalTransaction.datetime : Timestamp of the original CIT transaction (ISO 8601)

Important: Both originalTransaction.id and originalTransaction.datetime are mandatory for MIT.

Headers

• Authorization: Bearer <AuthToken>
• X-IBM-Client-Id: <ClientId>
• Content-Type: application/json
• Accept: application/json

What you do in this step

• Create a new Merchant Initiated Transaction (MIT) based on the original successful CIT transaction.
• Send the amount and currency to be collected in this recurring payment.

1.2. Store from the successful response:

From the MIT response, you must store the returned transactionID. In this page, that value is referred to as {mitTransactionID} and is used in the capture step.

2) Capture the MIT transaction (server-to-server)

Goal: Finalize the recurring collection by capturing the MIT transaction created in the previous step.

In the MIT flow, the previous step prepares the recurring transaction but does not reserve or transfer funds.

The CAPTURE operation is required to transfer funds and complete the recurring payment.

What you do

2.1 POST Capture request

curl -v -X POST "https://api.qly.sibspayments.com/sibs/spg/v2/payments/<mitTransactionID>/capture" \
--header "X-IBM-Client-Id: <ClientId>" \
--header "Authorization: Bearer <AuthToken>" \
--header "Accept: application/json" \
--header "Content-Type: application/json"
--data '{
    "merchant": {
        "terminalId": "{{terminalId}}",
        "merchantTransactionId": "9f36de3e8dfd4d1cb6fb1f06c14d99a2",
        "channel": "web"
    },
    "transaction": {
        "transactionTimestamp": "{{currentDateTime}}",
        "description": "71e1316fc799477c8aa9a27269d11190",
        "amount": {
            "value": {{amount}},
            "currency": "EUR"
        },
        "originalTransaction": {
            "id": "{{mitTransactionID}}",
            "datetime": "{{mitTransactionDateTime}}"
        }
    }
}'

Where:

• {mitTransactionID} is the original transaction identifier (from the MIT flow) to be captured.

The recurring collection should only be considered successful when:

• paymentStatus = "Success“
• returnStatus.statusCode = "000“

What happens

SPG validates that the MIT transaction is in a valid state for capture.
If valid, SPG captures the requested amount (full or partial, if supported and configured).
The transaction progresses toward its final state.

Capture is mandatory after MIT.

Capture Behavior

In the MIT flow, the initial request does not transfer funds.

Funds are only settled after a successful CAPTURE operation.

Important:

• If CAPTURE is not performed, no funds are transferred
• CAPTURE finalizes the transaction

What to store from the response

Store at least:

• Capture the paymentStatus with the result status (success/failure)
• The transactionID returned in the capture response (this becomes the final transaction reference).
• Captured amount and currency

Important Notes

• The capture amount must not exceed the amount authorized in the MIT transaction.
• Partial capture depends on merchant configuration and scheme rules.
• Capture operations should be implemented idempotently to prevent duplicate processing in retry or network-failure scenarios.
• If the MIT transaction expires before capture, the capture operation will fail.
• MIT and Capture retries should be implemented idempotently to avoid duplicate processing.
• If the operation result is uncertain, confirm the final state through the Status API before retrying business actions.

3) Validate Transaction Status (Server-to-Server)

Goal: Confirm the final capture outcome after the capture operation.

3.1 When to check status

You must verify the capture transaction status after the capture operation. The transaction must only be considered finalized after confirming the status via the Status API.

3.2 Status endpoints you can use

SIBS SPG documents the following Status API endpoint for transaction status confirmation:

• GET /api/v2/payments/{transactionID}/status (where {transactionID} is the value returned by the Capture operation)

curl -v -X GET "https://api.qly.sibspayments.com/sibs/spg/v2/payments/{transactionID}/status" \
--header "X-IBM-Client-Id: <ClientId>" \
--header "Authorization: Bearer <AuthToken>" \
--header "Accept: application/json" \
--header "Content-Type: application/json"

Where {transactionID} is the value returned by the Capture operation (Step 2).

3.3 Required headers (status call)

• Authorization: Bearer <AuthToken>
• X-IBM-Client-Id: <clientid>
• Content-Type: application/json
• Accept: application/json

3.4 What statuses to expect (high level)

The response includes paymentStatus, typically with values such as:

• Success
• Declined
• Error
• Pending
• InProcessing
• Timeout

Typical status interpretation

• Success: the capture operation was successfully processed and funds have been transferred.
• Declined: the transaction was refused.
• Error: a technical or processing error occurred.
• Pending: the transaction is still being processed.
• InProcessing: the transaction is in processing.
• Timeout: the operation timed out before a final result was obtained.

The recurring collection should only be considered successful when:

• paymentStatus = "Success“
• returnStatus.statusCode = "000“

Only then should the recurring collection be considered successfully completed and funds transferred.

Error handling and retry strategy

• If the MIT request fails, do not proceed to capture.
• If the capture result is uncertain, confirm the final state using the Status API before retrying.
• If the status is Pending or InProcessing, poll again using a controlled retry strategy.
• All retries should be implemented idempotently to avoid duplicate processing.