Overview

The official SIBS Postman collections are structured to reflect the organization of SPG API operations, providing a clear and consistent way to navigate and understand requests.

These collections group requests according to payment methods, operation types, and predefined scenarios, ensuring a structured representation of the available API capabilities.

Collection Organization

The SPG Payment Gateway Collection is organized into logical groups primarily based on payment methods and operation types, including:

• MB WAY
• Multibanco Reference
• Card
• Backoffice Operations

Within each group, requests represent individual API operations.

These operations are structurally related through the SPG transaction lifecycle, where outputs generated by one operation may become required inputs for subsequent requests.

For example:

• SPG Payment Gateway Collection → Card → Checkout Card
• SPG Payment Gateway Collection → Card → Purchase – Server to Server

For complete execution flows using these requests, refer to F.1 – End-to-End Integration Examples.

This organization provides a clear executable structural representation of the SIBS SPG API and its operational lifecycle flows.

In addition to method-specific groupings, certain operations such as status inquiry appear across multiple groups, reflecting their use across different payment methods.

This reflects the role of Status Inquiry as a cross-cutting transaction-state validation and reconciliation mechanism across multiple payment methods.

See E.2 – Status Inquiry / Get Status for detailed guidance regarding transaction-state validation and reconciliation semantics.

Operation-Level Structure

Each request in the collection corresponds to a specific SPG API operation and includes the necessary method, endpoint, headers, and payload required for execution.

This ensures that each request directly maps to a specific API capability exposed by SPG.

Many requests also participate in chained execution flows through transaction identifiers such as transactionID, which maintain continuity across the integration lifecycle.

See F.9.3 – Variable Management and Request Chaining for detailed guidance regarding lifecycle continuity and transaction-context propagation across requests.

For detailed information on request payloads, headers, and field semantics, refer to F.2 – Requests and Responses (Annotated).

Sandbox Collection Structure

The SPG Sandbox Collection is organized by:

• Payment method (e.g., MB WAY, Card, Multibanco)
• Predefined scenarios within each method

Examples include:

• SPG Sandbox Collection → MB WAY → MB WAY – Success
• SPG Sandbox Collection → MB WAY → MB WAY – Declined
• SPG Sandbox Collection → CARD → Card – Success
• SPG Sandbox Collection → MULTIBANCO → Multibanco – PAID

Each scenario contains a set of requests representing API operations organized according to the available interactions within that scenario.

These interactions may include both synchronous execution steps and asynchronous webhook notification propagation depending on the payment method and operational scenario.

The collection also includes additional grouped scenarios covering specific operational cases and API behaviors.

For guidance on reproducible testing using these scenarios, refer to F.8 – Sandbox Reproducible Examples.

Final Consideration

The Postman collections provide a structured executable representation of the SIBS SPG API, grouping requests by payment method, operation type, and predefined scenarios.

A correct understanding of this structure enables integrators to:

• Navigate executable transaction flows effectively
• Identify the appropriate requests for each operation
• Understand how API interactions are organized and related within the collections

By following the structure provided in the collections, integrators ensure that API interactions are consistent with the defined SPG interfaces and available scenarios, enabling reliable and structured validation of integration behavior.