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 appropriate API environment URL (<ROOT_URL>) for the target environment.

Please refer to A.3 – API Requests for the complete list of environment-specific URLs.

Prerequisites (Recurring Model Requirements)

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

• transactionID from the original CIT transaction
• transactionTimestamp 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 Cardholder 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 preparation
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 Cardholder 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 is optional.

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 through webhook notification or, where needed, using the Status API

The recurring collection is considered completed after the capture is successful and the final result is received through webhook notification or, where needed, confirmed through the Status API.

This page only covers the recurring collection phase.

The initial recurring customer authorization flow is documented in:

• D.2.2.1 – Recurring Payments – Credit Card Authorization [Form Integration]
• D.2.2.2 – 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 Cardholder Initiated Transaction (CIT).

This request creates the Merchant Initiated Transaction (MIT) used for the recurring collection lifecycle.

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 -v -X POST '<ROOT_URL>/payments/{transactionID}/mit' \
--header "X-IBM-Client-Id: dd43****" \
--header "Authorization: Bearer 0276****" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data '
{
    "merchant": {
        "terminalId": "58019",
        "channel": "web",
        "merchantTransactionId": "unique-order-id"
    },
    "transaction": {
        "transactionTimestamp": "2028-12-31T00:00:00.000Z",
        "description": "Credit Card Mit operation",
        "moto": false,
        "type": "RCRR",
        "amount": {
            "value": 5.10,
            "currency": "EUR"
        },
        "originalTransaction": {
            "id": "{{originaltransactionID}}",
            "datetime": "{{originalDateTime}}"
        }
    }
}'

Where:

• {transactionID} must reference the original successful CIT transaction.
• For recurring collections, transaction.type must be “RCRR".
• The original CIT transaction must be referenced using:
  • originalTransaction.id : Identifier of the original CIT transaction
  • originalTransaction.datetime : Timestamp of the original CIT transaction (ISO 8601)

Important: originalTransaction.id is mandatory for MIT. originalTransaction.datetime is optional.

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 '<ROOT_URL>/payments/{mitTransactionID}/capture' \
--header "X-IBM-Client-Id: dd43****" \
--header "Authorization: Bearer 0276****" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
--data '
{
    "merchant": {
        "terminalId": "58019",
        "merchantTransactionId": "unique-order-id",
        "channel": "web"
    },
    "transaction": {
        "transactionTimestamp": "2028-12-31T00:00:00.000Z",
        "description": "Credit Card Collection operation",
        "amount": {
            "value": 5.10,
            "currency": "EUR"
        },
        "originalTransaction": {
            "id": "{{originaltransactionID}}",
            "datetime": "{{originalDateTime}}"
        }
    }
}'

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

If no webhook notification is received, confirm the capture transaction status through Status Inquiry. A final status received in the webhook is final.

3.2 Status endpoints you can use

Use the following Status API endpoint for transaction status confirmation:

• GET <ROOT_URL>/payments/{transactionID}/status (where {transactionID} is the transactionID returned by the Capture operation)

curl -v -X GET "<ROOT_URL>/payments/{transactionID}/status" \
--header "X-IBM-Client-Id: dd43****" \
--header "Authorization: Bearer 0276****" \
--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
• 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.
• 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, poll again using a controlled retry strategy.
• All retries should be implemented idempotently to avoid duplicate processing.

3.5 Polling Strategy

• Poll GET <ROOT_URL>/payments/{transactionID}/status every few seconds
• Recommended interval: 3–5 seconds
• Continue until:
  • Final status is reached, or
  • Timeout is exceeded

All retry operations should remain idempotent.

3.6 Persistence Requirements

The merchant should persist:

• merchantTransactionId
• MIT transactionID
• Capture transactionID
• paymentStatus
• amount
• currency
• original CIT reference

The SPG transactionID should be treated as the primary and authoritative identifier for MIT execution, capture operations, webhook correlation, reconciliation, and status inquiry operations.

For webhook delivery behavior, asynchronous notifications, retry semantics, and notification security considerations, refer to E.1 – Webhooks (Notifications).

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

Recurring MIT request examples, capture flows, recurring lifecycle examples, and operational testing scenarios are documented in F. Technical Examples and Best Practices.