Overview

The Postman collections provided with the SIBS Payment Gateway (SPG) documentation define a structured execution model for interacting with the platform APIs. This model reflects how SPG operations are executed and validated in practice, based on the logical dependencies between requests.

Rather than representing isolated API calls, the collections organize requests in a way that highlights the required execution sequence, where each step depends on data produced by previous operations. This ensures that integrators can execute and validate flows in alignment with the expected behavior of the SPG platform.

Execution Sequence Model

SPG transaction flows follow a multi-step execution sequence, where operations are intended to be executed in order due to their dependencies.

A typical flow includes:

1. Checkout Request
   Creation of the transaction context via:
   • SPG Payment Gateway Collection → MB WAY → Checkout MB WAY
   • SPG Payment Gateway Collection → Card → Checkout Card
   • SPG Payment Gateway Collection → Multibanco → Checkout REFERENCE
2. Payment Execution (Method-Specific)
   Execution of the selected payment method, for example:
   • SPG Payment Gateway Collection → MB WAY → Purchase MB WAY
   • SPG Payment Gateway Collection → Card → Purchase – Server to Server
   • SPG Payment Gateway Collection → Multibanco → Generate Reference
3. Status Validation
   Retrieval of the transaction state via:
   • SPG Payment Gateway Collection → MB WAY → getStatus
   • SPG Payment Gateway Collection → Card → getStatus
   • SPG Payment Gateway Collection → Multibanco → getStatus

This sequence reflects the dependency model of SPG operations:

• A transaction must first be created before any subsequent operation
• Later requests depend on identifiers generated in previous steps
• The final transaction outcome is determined through status validation

Requests are intended to be executed in sequence within the collection, as later operations depend on data produced by earlier steps and on identifiers generated during the flow.

Request Chaining and Dependency Handling

The Postman collections support request chaining, where:

• Data produced by one request is required by subsequent requests
• Requests are executed in a logically dependent order

For example:

• The checkout request generates a transactionID and transactionSignature
• These values are reused in subsequent operations such as purchase or reference generation

This dependency model ensures that:

• Each request is executed within a valid transaction context
• API interactions remain consistent across the flow
• Execution aligns with the expected transaction lifecycle of SPG

Runtime Variable Management

Runtime variables are handled using Postman scripts, which extract data from API responses and store it for reuse in subsequent requests.

For example:

• transactionID and transactionSignature are extracted from the checkout response
• These values are stored in global or environment variables
• Subsequent requests reference these variables dynamically

This mechanism ensures that:

• Data produced by one request is reused in subsequent requests
• Manual intervention is minimized
• Execution remains consistent across repeated runs

The correct configuration of environment variables (such as {{host}}, {{ClientID}}, and credentials) is required prior to execution.

Handling of Different Response Patterns

Different payment methods exhibit different response patterns:

• Some operations return immediate outcomes (e.g., success or decline)
• Others may initially return a pending state, requiring further validation

In all cases, the status endpoint remains the authoritative mechanism to determine the final transaction state.

For detailed interpretation of transaction outcomes, refer to F.3 Success and Error Scenarios.

Integration with Sandbox Testing

The same execution model applies when using the SPG Sandbox Collection, where flows are organized into predefined scenarios.

For example:

• SPG Sandbox Collection → MB WAY → MB WAY – Success → Checkout MB WAY
• SPG Sandbox Collection → MB WAY → MB WAY – Success → Purchase
• SPG Sandbox Collection → MB WAY → MB WAY – Success → Status

In the Sandbox collection, specific transaction outcomes are triggered through predefined values in the merchantTransactionId field of the checkout request, allowing controlled simulation of different scenarios.

This enables integrators to:

• Execute consistent test scenarios
• Validate different transaction outcomes
• Reproduce specific behaviors in a controlled environment

For detailed guidance on reproducible testing, refer to F.8 Sandbox Reproducible Examples.

Backoffice Operations within the Execution Model

In addition to payment execution flows, the collections include backoffice operations that follow the same dependency model.

Examples include:

• SPG Payment Gateway Collection → Backoffice Operations → Capture
• SPG Payment Gateway Collection → Backoffice Operations → Refund
• SPG Payment Gateway Collection → Backoffice Operations → Cancellation

These operations:

• Depend on an existing transactionID
• Require proper sequencing relative to previous operations
• Follow the same principles of context reuse and status validation

Execution Best Practices

To ensure correct usage of the execution model:

• Execute requests in sequence according to their dependencies
• Do not skip intermediate steps within a flow
• Always perform status validation after executing operations
• Ensure required variables are correctly populated before execution
• Avoid treating requests as fully independent operations

These practices ensure that integration testing reflects the actual operational behavior of the SPG platform.

Final Consideration

The Postman collections define not only the structure of API requests, but also the correct execution model for SPG transaction flows.

A correct integration requires:

• Respecting the dependencies between requests
• Reusing data produced across operations
• Validating outcomes using authoritative mechanisms such as the status endpoint

By following this execution model, integrators ensure that their implementation aligns with the expected behavior of the SPG platform, enabling accurate validation, reliable testing, and reduced integration risk.