Overview

This section provides annotated request and response examples for Recurring Payments and Merchant Initiated Transactions (MIT), focusing on payload structures and interpretation rules.

Recurring and MIT scenarios introduce additional complexity compared to one-off payments because they involve:

• Initial customer authorization (CIT – Customer Initiated Transaction)
• Subsequent merchant-initiated executions (MIT)
• Tokenization and transaction linkage
• Depending on the integration model and acquirer configuration, MIT operations may rely on tokenized payment credentials, original transaction linkage, or a combination of both mechanisms.
• Optional scheduling and amount qualification

The objective of this section is to provide a clear, implementation-level understanding of how these transactions must be constructed and interpreted, strictly at payload level.

Scope and Context

This section focuses strictly on payload construction and response interpretation.

For:

• End-to-end flow sequencing → see F.1 – End-to-End Integration Examples
• Payment flow definitions → see D. Payment Methods
• Status and error semantics → see C. Meta Information, Codes and Transaction States
• Webhook structures → see E.1 – Webhooks (Notifications)
• Recurring payment definitions and lifecycle behavior → see D.2 – Recurring Payments

1. Initial Authorization (CIT – Token Generation)

Request

POST <ROOT_URL>/payments

{
    "merchant": {
        "terminalId": "11111",
        "channel": "web",
        "merchantTransactionId": "CARD-CIT-0001"
    },
    "transaction": {
        "transactionTimestamp": "2026-04-16T10:15:30.000Z",
        "description": "Initial recurring authorization",
        "paymentType": "AUTH",
        "paymentMethod": [
            "CARD"
        ],
        "amount": {
            "value": 0.00,
            "currency": "EUR"
        }
    }
}

This operation uses Bearer authentication.

Key Annotations

• paymentType = "AUTH"
→ Defines an authorization request
• amount.value = 0.00
  → Zero-amount authorization used for token generation
• paymentMethod = ["CARD"]
  → Required for card-based recurring flows

Response (Annotated)

{
    "returnStatus": {
        "statusCode": "000",
        "statusMsg": "Success"
    },
    "paymentStatus": "Success",
    "transactionID": "txCIT123456789",
    "token": {
        "tokenType": "Card",
        "value": "TKN123456789"
    }
}

Interpretation

• paymentStatus = "Success"
  → Authorization completed successfully
• token.value
  → Must be securely stored for use in subsequent Merchant Initiated Transactions (MIT).
• transactionID
  → Must be persisted and used as the primary SPG identifier for all subsequent operations, status inquiries, and webhook correlation. Merchant-defined identifiers must not be used as substitutes.

2. Merchant Initiated Transaction (MIT)

Request

POST <ROOT_URL>/payments

{
    "merchant": {
        "terminalId": "11111",
        "channel": "web",
        "merchantTransactionId": "CARD-MIT-0001"
    },
    "transaction": {
        "transactionTimestamp": "2026-04-17T10:15:30.000Z",
        "paymentType": "MIT",
        "paymentMethod": [
            "CARD"
        ],
        "amount": {
            "value": 29.90,
            "currency": "EUR"
        }
    },
    "originalTransaction": {
        "id": "txCIT123456789",
        "datetime": "2026-04-16T10:15:30.000Z"
    }
}

This operation uses Bearer authentication.

Key Annotations

• paymentType = "MIT"
→ Indicates a merchant-initiated transaction
• originalTransaction.id
  → Links the MIT to the original CIT
• originalTransaction.datetime
  → Must match the original transaction timestamp

The timestamp must use the original ISO 8601 UTC datetime value including milliseconds.

Response

{
    "returnStatus": {
        "statusCode": "000",
        "statusMsg": "Success"
    },
    "paymentStatus": "Success",
    "transactionID": "txMIT123456789",
    "amount": {
        "value": 29.90,
        "currency": "EUR"
    }
}

Interpretation

• paymentStatus = "Success"
→ Payment executed successfully without customer interaction

MIT transactions are typically:

• Fully server-to-server
• May not require 3DS depending on regulatory requirements, issuer behavior, acquirer configuration, and applicable authentication exemptions

Final transaction state may be determined from Webhooks or checked using Status Inquiry when required.

3. Advanced MIT Attributes

Request Example (with MIT details)

POST <ROOT_URL>/payments

{
    "merchant": {
        "terminalId": "11111",
        "channel": "web",
        "merchantTransactionId": "CARD-MIT-0002"
    },
    "transaction": {
        "transactionTimestamp": "2026-04-18T10:15:30.000Z",
        "paymentType": "MIT",
        "paymentMethod": [
            "CARD"
        ],
        "amount": {
            "value": 15.00,
            "currency": "EUR"
        }
    },
    "originalTransaction": {
        "id": "txCIT123456789",
        "datetime": "2026-04-16T10:15:30.000Z"
    },
    "merchantInitiatedTransaction": {
        "type": "RCRR",
        "amountQualifier": "ACTUAL",
        "validityDate": "2027-04-16T23:59:59.000Z"
    }
}

Key Annotations

• merchantInitiatedTransaction.type
→ Defines the MIT category (e.g., RCRR, UCOF)
• amountQualifier
  → Indicates whether the amount is fixed or estimated
• validityDate
  → Defines the validity of the agreement

4. Optional Scheduling

Request Example (with schedule)

{
    "merchantInitiatedTransaction": {
        "type": "RCRR",
        "amountQualifier": "ESTIMATED",
        "schedule": {
            "initialDate": "2026-05-01T00:00:00.000Z",
            "finalDate": "2027-05-01T00:00:00.000Z",
            "interval": "MONTHLY"
        }
    }
}

Interpretation

• Scheduling defines recurring execution parameters
• Scheduling metadata defines the intended recurring execution model but does not itself guarantee automatic transaction execution.
• Not all acquirers require or support scheduling

Common Pitfalls

1. Missing originalTransaction linkage

MIT requests must always reference the original CIT

2. Incorrect datetime value

Must match the original transaction timestamp exactly

3. Not storing token securely

Token is required for all subsequent MIT operations

4. Using incorrect paymentType

• AUTH → initial authorization
• MIT → subsequent merchant-initiated payments

5. Misinterpreting response as final

Confirm when required via:

• Webhooks
• Status Inquiry

When discrepancies exist between intermediate responses, webhook notifications, or delayed operational updates, the latest transaction state should be checked using Status Inquiry.

For detailed guidance on status retrieval and interpretation, see E.2 – Status Inquiry / Get Status.

6. Improper handling of retries and duplicates

MIT operations must be protected against duplicate execution through proper idempotency and retry handling.

Because MIT flows normally execute without direct customer interaction, improper retry handling may lead to unintended duplicate charges.

See also F.7.5 – Improper Handling of Retries and Duplicates.

Key Takeaways

Recurring and MIT flows rely on a two-phase model:

1. Customer authorization (CIT)
2. Merchant-initiated execution (MIT)

Key requirements:

• Tokenization or transaction linkage
• Correct use of originalTransaction
• Proper classification of MIT type

These flows enable:

• Subscription payments
• Installments
• Usage-based billing

This section provides the reference foundation for implementing and troubleshooting recurring and MIT request and response handling in SPG.

The Inquiry Details API may expose Merchant Initiated Transaction (MIT) attributes, including type and amount qualifiers, providing additional context for recurring and subsequent transactions.

This information complements, but does not replace, the transaction state returned by webhook notifications or Status Inquiry when required.

Inquiry Details responses should be used for extended operational analysis and contextual interpretation rather than for transaction-state validation.