Skip to content
Menu

PAYMENT GATEWAY

[THK] F.2 Requests and Responses (Annotated)

Overview

This section provides a detailed, field-level view of API requests and responses, with annotations designed to support accurate, consistent, and production-ready integration with the SIBS Payment Gateway (SPG).

While previous chapters describe transaction flows, states, and behaviors, this section focuses on the exact structure and semantics of the exchanged payloads as they are used in real execution scenarios.

The annotated examples reflect how requests and responses behave in practice, including:

  • Validation constraints
  • Field dependencies
  • Data consistency requirements
  • Flow-specific requirements
  • Method-specific nuances observed during real integration and runtime processing

This section enables the transition from conceptual understanding to implementation-ready payload construction and interpretation, reducing ambiguity and minimizing integration errors.

Scope and Positioning

This section complements other chapters as follows:

In contrast, this section focuses on the payload layer, detailing how data must be structured, validated, and interpreted at each interaction with the API.

Annotated Example Approach

All examples in this section follow a consistent and structured approach:

  • Full request and response payloads are provided
  • Relevant fields are annotated with:
    • Purpose and business meaning
    • Validation constraints and dependencies
    • Flow-specific considerations
  • Only fields with operational relevance are annotated, ensuring clarity and usability

The examples are based on real execution patterns and reflect actual runtime behavior observed during integration and production processing.

How to Use This Section

This section is designed to be used in conjunction with F.1 End-to-End Examples.

For each integration step:

  • Use F.1 End-to-End Integration Examples to understand the sequence and operational flow of each transaction
  • Use this section to understand how to construct and interpret the corresponding requests and responses at each step.

The recommended approach is:

This combined approach ensures both functional correctness and payload-level accuracy, which are required for production-grade integrations.

Alignment with Postman Collections

All annotated examples in this section are aligned with the Postman collections provided with this documentation.

These collections include:

  • Pre-configured requests for supported payment flows
  • Environment variables for sandbox and production usage
  • End-to-end execution scenarios and alternative paths

The collections should be used as the execution layer, while this section provides the interpretation and implementation guidance required to correctly use them.

Relationship with End-to-End Examples

This section focuses on individual request and response structures.

For complete transaction journeys, including sequencing and orchestration, refer to:

Both sections are complementary:

Together, they provide a complete view of both process and implementation.

Key Principles

  • Requests must strictly follow field-level semantics and flow-specific requirements
  • Responses must be interpreted based on:
    • returnStatus
    • paymentStatus
    • Method-specific data structures
  • Payload correctness directly impacts:
    • Transaction lifecycle management
    • Error handling and recovery
    • Reconciliation and audit processes

This section provides the technical foundation required to ensure consistent payload construction, accurate response interpretation, and reliable behavior across all transaction scenarios in production-grade integrations.

Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

Strictly Necessary Cookies

Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.