Overview

The SIBS Payment Gateway (SPG) Sandbox environment enables the execution of deterministic and reproducible transaction scenarios, allowing integrators to validate integration behavior prior to production deployment.

In addition to the official Postman collections, the Sandbox Payment Simulator may be used to execute predefined payment scenarios through a browser-based interface, allowing integrators to validate payment-method-specific behaviours, transaction lifecycle progression, and operational request/response flows without implementing a complete integration.

Example sandbox simulator entry point

All Sandbox testing must be performed using the official Postman collections, which provide:

• Pre-configured request sequences for all supported payment methods
• End-to-end execution flows aligned with SPG v2
• Scenario-driven simulations (success, declined, error, and edge cases)
• Environment variables and authentication setup

These collections must be used as the execution layer for all Sandbox validation activities, as introduced in F.1 – End-to-End Integration Examples.

Sandbox reproducibility complements, but does not replace, the broader production-readiness validation activities described in F.6 – Production Readiness Guidelines.

Download Postman Collections:

• SPG Payment Gateway Collection
• SPG Sandbox Collection

Execution Model Using Postman Collections

Sandbox scenarios must be executed following the request sequences defined in the Postman collections.

A standard execution flow consists of:

1. Checkout Request
   • POST <ROOT_URL>/payments
   • Retrieves:
     • transactionID
     • transactionSignature
2. Payment Execution
   • Method-specific endpoint:
     • POST <ROOT_URL>/payments/{transactionID}/mbway-id/purchase
     • POST <ROOT_URL>/payments/{transactionID}/card/purchase
     • POST <ROOT_URL>/payments/{transactionID}/service-reference/generate
3. Status Validation
   • GET <ROOT_URL>/payments/{transactionID}/status
4. Webhook Validation (when configured)
   • Validate asynchronous notification delivery, transaction correlation, and state propagation behavior

The Postman collections automatically:

• Extract the transactionID from the Checkout response
• Store it as a variable
• Reuse it in all subsequent requests

Requests must be executed sequentially within the collection to ensure correct variable propagation and scenario consistency.

Sequential execution guarantees that transaction-scoped identifiers and lifecycle state remain consistent across all requests participating in the same Sandbox scenario.

This enforces the correct execution pattern and ensures consistency across all test scenarios.

Primary Transaction Identifier

The transaction lifecycle is anchored on the transactionID, which is the primary SPG identifier for all transaction-scoped operations.

This identifier:

• Is generated by SPG during Checkout
• Is required for all subsequent operations
• Must be used for correlation across:
  • API calls
  • Webhook notifications
  • Internal system processing

The Postman collections explicitly reflect this model by:

• Capturing transactionID after Checkout
• Using it in all downstream requests (purchase, status, operations)

While merchant.merchantTransactionId is included in requests:

• It is not the primary SPG identifier of the transaction lifecycle
• It must not be used to drive transaction state, reconciliation, or lifecycle decisions

Observability and Execution Traceability

The Postman collections provide built-in mechanisms to support reproducibility:

• Automatic variable propagation (transactionID, transactionSignature)
• Structured request grouping by deterministic scenario
• Environment configuration for Sandbox execution

For each execution, integrators must capture:

• Request payloads
• Response payloads
• Status responses
• Transaction identifiers

This ensures consistent validation and reproducibility across all test scenarios.

Limitations of Sandbox

Sandbox is a controlled simulation environment and does not fully replicate production operational behavior.

Key limitations include:

• No real issuer or acquirer interaction
• No real customer-driven authorization
• No fraud or risk evaluation
• Simplified timing and execution behavior

Scenario outcomes are predefined and intentionally deterministic, and external dependencies are not represented.

Final Consideration

The official Postman collections provide the reference execution framework for Sandbox reproducible examples, enabling deterministic validation of all supported flows.

A correct integration must demonstrate:

• Consistent use of transactionID
• Proper lifecycle handling
• Reliable transaction-state confirmation through Status Inquiry / Get Status when required
• Robust handling of asynchronous flows

Sandbox validates implementation correctness under controlled conditions, while production correctness depends on consistent and resilient behavior under real-world execution.

Operational resilience under real-world concurrency, infrastructure variability, network instability, issuer behavior, and distributed timing conditions must be validated separately during production-readiness activities.

See E.1 – Webhooks (Notifications) and E.2 – Status Inquiry / Get Status for detailed guidance regarding asynchronous notification handling and transaction-state confirmation and reconciliation.

When extended operational diagnostics are required during Sandbox validation, additional lifecycle visibility may leverage Inquiry Details as described in E.2.10 – Inquiry Details API.