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
• 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)

1. Initial Authorization (CIT – Token Generation)

Request

POST <ROOT_URL>/api/v2/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"
        }
    }
}

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 future transactions

2. Merchant Initiated Transaction (MIT)

Request

POST <ROOT_URL>/api/v2/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"
    }
}

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

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
• Not requiring 3DS (depending on configuration and exemptions)

3. Advanced MIT Attributes

Request Example (with MIT details)

POST <ROOT_URL>/api/v2/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
• 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

Always confirm via:

• Webhooks
• Status endpoint

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.