Overview
This chapter defines the role of Postman collections and cURL requests in the context of SIBS Payment Gateway (SPG) integrations, focusing on how API interactions are executed and validated in practice.
In SPG, integration correctness is not achieved solely through understanding API specifications or payload structures, but through the ability to execute transaction flows consistently and accurately across their full lifecycle. As demonstrated in F.1 – End-to-End Integration Examples, each payment interaction involves a sequence of dependent operations, including checkout creation, payment execution, asynchronous processing, and final state validation.
The Postman collections provided with this documentation represent the reference executable orchestration layer for these flows.
Download and use the following official Postman collections:
Official Postman Collections
For quick functional validation and payment-method-specific testing scenarios, the Sandbox Payment Simulator may also be used as a complementary tool alongside the Postman collections.
Example sandbox simulator entry point
These collections must be used as the baseline execution and validation mechanism for all integration testing activities.
They encapsulate:
- Pre-configured requests aligned with SPG APIs
- Correct lifecycle sequencing of operations
- Automatic propagation of transaction context (e.g.,
transactionID) - Support for both synchronous and asynchronous scenarios
This includes validation of asynchronous webhook notification propagation and consistency with Status Inquiry / Get Status results when confirmation is required.
As further reinforced in F.8 – Sandbox Reproducible Examples, all testing – particularly in Sandbox – must be performed using these collections, which enable deterministic and reproducible validation of integration behavior.
Execution Model Using Postman Collections
The Postman collections must be used as the baseline execution model for all SPG integrations.
They enforce a structured execution pattern consistent with the SPG lifecycle:
- Checkout request
- Payment execution (method-specific)
- Status validation
This sequence reflects the actual dependency model of SPG, where:
- Each step depends on the output of the previous one
- The
transactionIDis generated during checkout and required for all subsequent operations - Transaction state evolves across multiple steps and must be validated accordingly
This dependency model guarantees consistent transaction-state progression across the full integration lifecycle.
The collections provide built-in mechanisms that ensure correct execution:
- Support for handling transaction identifiers across requests
- Support for propagating transaction context across requests
- Pre-configured request structures aligned with the API
Transaction-state confirmation and reconciliation should use Status Inquiry / Get Status when required.
Role of cURL
cURL may be used in SPG integrations as a complementary tool, particularly for:
- Backend-level testing
- Automation scenarios (e.g., CI/CD pipelines)
- Debugging specific API interactions
However, cURL does not provide:
- Execution sequencing
- Variable management
- End-to-end flow orchestration
As a result, it does not reflect the full integration lifecycle when used in isolation.
For this reason:
- cURL should not be used as the primary mechanism for integration validation
- Postman collections must remain the reference execution tool
cURL usage should be limited to controlled scenarios where individual request validation is required.
See E.1 – Webhooks (Notifications) and E.2 – Status Inquiry / Get Status for detailed guidance regarding asynchronous notification handling, transaction-state reconciliation, and transaction-state confirmation and reconciliation semantics.
When extended operational diagnostics are required during execution analysis or troubleshooting, additional visibility may leverage Inquiry Details as described in E.2.10 – Inquiry Details API.
Final Consideration
Postman collections are not auxiliary tooling – they are a core component of the SPG integration model.
They provide a validated and executable representation of how the platform operates, ensuring that integrations are tested under conditions that reflect real execution behavior.
A correct integration requires not only successful API calls and valid request payloads, but also the ability to:
- Execute transaction flows end-to-end
- Respect the dependency between operations
- Correctly handle asynchronous processing and delayed outcomes
- Validate final transaction state using validated final
paymentStatusdata, or Status Inquiry / Get Status when confirmation, recovery, or reconciliation is required
By using the Postman collections as the execution baseline, integrators ensure:
- Consistency across testing and implementation
- Alignment with SPG operational expectations
- Reduced risk of integration errors in production environments
This approach establishes a reliable foundation for both development and production readiness.