Overview

A reproducible Sandbox flow is a structured sequence of steps that consistently produces a deterministic and verifiable transaction outcome.

Each flow must be defined so that it:

• can be executed repeatedly
• produces consistent results
• supports controlled validation of the full transaction lifecycle

In practice, reproducible flows are executed through the official Postman collections, but correctness depends on the integrity of the full transaction sequence rather than on individual requests.

SIBS Postman collections are available in:

• SIBS PAYMENT GATEWAY Postman collection
• SPG Sandbox Postman collection

This structure is used to execute the deterministic scenarios defined in F.8.1 – Deterministic Scenario Modeling in Sandbox and must comply with the requirements defined in F.8.3 – Reproducibility Requirements.

Core Structure of a Reproducible Flow

A reproducible Sandbox flow must follow a strict and complete structure, composed of three main phases:

1. Initialization (Checkout)
2. Execution (Payment or Operation)
3. Validation (Status Confirmation)

These phases must be treated as a single logical unit.

For standard execution patterns, this sequence is reflected in the SIBS PAYMENT GATEWAY Postman collection through method-specific flows such as:

• MB WAY → Checkout MB WAY → Purchase MB WAY → getStatus
• Multibanco → Checkout REFERENCE → Generate Reference → getStatus
• Card → Checkout Card → getStatus

For deterministic Sandbox scenarios, the same structural sequence is represented in the SPG Sandbox Postman collection through scenario folders such as:

• MB WAY → MB WAY – Success / MB WAY – Declined / MB WAY – Without ALIAS
• CARD → Card – Success / Card – Declined / Card – Invalid Card Data
• MULTIBANCO → Multibanco – UNPAID / Multibanco – PAID

Each phase must be completed before proceeding to the next, and partial execution does not constitute a valid flow.

Phase 1 – Initialization (Checkout)

The flow begins with the creation of the transaction context.

This step:

• initializes the transaction in SPG
• generates the transactionID
• defines the transaction context for the subsequent execution phase

The output of this phase is:

• a valid transactionID
• a transaction initialized and ready for execution

This phase must be executed once per flow and must not be reused across different test executions.

In Postman, this phase corresponds to the method-specific Checkout request, for example:

• SIBS PAYMENT GATEWAY → MB WAY → Checkout MB WAY
• SIBS PAYMENT GATEWAY → Multibanco → Checkout REFERENCE
• SIBS PAYMENT GATEWAY → Card → Checkout Card

In scenario-driven Sandbox validation, the same phase is represented by the Checkout request inside the selected scenario folder in SPG Sandbox Postman collection.

Phase 2 – Execution (Payment or Operation)

The execution phase applies the intended payment or operation to the initialized transaction.

This step:

• triggers the payment or operation
• produces a transaction outcome that may represent either an intermediate lifecycle state or a final transaction result

Depending on the scenario:

• the outcome may be immediately final
• the outcome may remain intermediate and require later confirmation

This phase must:

• use the transactionID generated in the Initialization phase
• follow the exact request configuration defined for the flow

Typical Postman examples include:

• SIBS PAYMENT GATEWAY → MB WAY → Purchase MB WAY
• SIBS PAYMENT GATEWAY → Multibanco → Generate Reference
• SPG Sandbox → CARD → Card – Success → Purchase – Server to Server
• SPG Sandbox → MULTIBANCO → Multibanco – PAID → Generate Reference

Phase 3 – Validation (Status Confirmation)

The validation phase confirms the observed transaction outcome.

This step:

• retrieves the current transaction state
• confirms the final paymentStatus
• validates consistency between the observed result and the expected outcome

When webhook notifications are configured, validation should also confirm correct asynchronous notification propagation and consistency with Status Inquiry / Get Status results.

Validation must:

• be performed using Status Inquiry / Get Status
• be executed after the execution phase
• be treated as confirmation of the transaction result

Status Inquiry / Get Status provides transaction-state confirmation for reproducible Sandbox flow verification.

A flow is only complete when the final state has been confirmed through this phase.

In Postman, this phase corresponds to the status request, for example:

• SIBS PAYMENT GATEWAY → MB WAY → getStatus
• SIBS PAYMENT GATEWAY → Multibanco → getStatus
• SIBS PAYMENT GATEWAY → Card → getStatus
• scenario-specific Status requests in SPG Sandbox folders

The validation criteria applied in this phase must align with the requirements defined in F.8.3 – Reproducibility Requirements.

Expected Inputs and Outputs

Each reproducible flow must clearly define:

Inputs

• scenario-specific request configuration
• structured payload values
• execution sequence

Outputs

• transactionID from the Initialization phase
• paymentStatus
• returnStatus.statusCode
• any method-specific response elements required for validation

The expected outputs must be known in advance and used as the basis for validation.

Sequence Integrity

The correctness of a reproducible flow depends on maintaining strict sequence integrity.

This means:

• Initialization must always precede Execution
• Execution must always precede Validation
• no phase may be skipped or reordered

Breaking this sequence results in:

• invalid test conditions
• inconsistent outcomes
• unreliable validation conclusions

This is also reflected in the collections themselves, where the relevant requests are organized to support the logical order Checkout → Execution → Status.

Sequence integrity guarantees that transaction-state evolution remains consistent across the full lifecycle and prevents invalid correlation between unrelated transaction contexts.

Validation Criteria

A reproducible flow must include explicit validation criteria.

At minimum, validation must confirm:

• that the final paymentStatus matches the expected scenario
• that the returnStatus.statusCode is consistent with the observed outcome
• that the transaction lifecycle is consistent with the expected behavior across the full flow

Additional validation may include:

• correct handling of intermediate states
• correct execution of operational flows
• consistency across repeated executions

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

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

Reproducibility Conditions

For a flow to be considered reproducible, it must satisfy the following conditions:

• Deterministic inputs
  The same request configuration must be used for each execution.
• Consistent execution sequence
  The same phases must be executed in the same order.
• Isolated execution context
  Each flow must use a new transaction context.
• Stable expected outcomes
  The expected result must remain consistent across repeated executions.

If any of these conditions is not satisfied, the flow cannot be considered reproducible.

Error and Edge Case Handling

A reproducible flow must also support validation of:

• error scenarios
• declined outcomes
• duplicate or idempotency-related scenarios
• other controlled edge cases

In these situations, the structure of the flow remains the same:

• Initialization
• Execution
• Validation

What changes is the expected lifecycle outcome, not the structural model of the flow.

This is particularly evident in the SPG Sandbox collection, where multiple scenario folders preserve the same structural pattern while changing the expected result.

Final Consideration

A reproducible Sandbox flow is not defined by isolated requests, but by the consistency of the full sequence and its validated final outcome.

By structuring flows around:

• Initialization
• Execution
• Validation

and by enforcing strict sequencing and validation criteria, integrators can ensure that:

• test scenarios are reliable
• outcomes are predictable
• integration behavior is correctly validated under controlled conditions

The Postman collections provide the executable form of these flows, but reproducibility depends on preserving the integrity of the full lifecycle from Checkout to final Status confirmation.

This structured approach ensures correct execution in Sandbox but must be interpreted in light of the behavioral differences between Sandbox and Production described in F.8.4 – Sandbox vs Production Behavioral Gap.