Skip to content
Menu

PAYMENT GATEWAY

[THK] F.9.4 Sandbox Scenarios and Deterministic Testing

Overview

The SPG Sandbox Collection provides a structured set of predefined scenarios that allow integrators to execute and validate transaction flows against predefined and consistent outcomes.

These scenarios are designed to support deterministic testing, where executing a specific scenario produces a consistent and repeatable response pattern, as defined within the collection.

The use of these scenarios complements the execution model described in F.9.2 Execution Model Using Postman Collections and the reproducibility principles outlined in F.8 Sandbox Reproducible Examples.

Structure of Sandbox Scenarios

Sandbox scenarios are organized within the SPG Sandbox Collection by:

  • Payment method (e.g., MB WAY, Card, Multibanco)
  • Scenario grouping (e.g., Success, Declined, or other predefined cases)

Each scenario contains a sequence of requests representing a complete transaction flow.

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

This structure allows integrators to execute and validate a full transaction lifecycle within a defined scenario.

Deterministic Behavior in Sandbox

The Sandbox collection defines scenarios that produce consistent and repeatable outcomes when executed.

Each scenario:

  • Represents a predefined behavior
  • Produces a predictable response pattern across its requests
  • Can be executed multiple times with consistent results

This enables integrators to:

  • Validate expected transaction outcomes
  • Confirm system behavior under specific conditions
  • Reproduce test results across executions

The specific inputs required to execute each scenario are defined within the corresponding requests in the collection and must be used as provided.

Scenario execution in the Sandbox collection may rely on specific input values defined within the requests, including the merchantTransactionId field, as documented in the collection itself.

Each predefined scenario is associated with a specific request configuration defined within the collection, and the corresponding input values must be used as provided. For the complete list of supported scenarios and their required inputs, refer to the Postman collections.

Execution Model within Scenarios

Each sandbox scenario follows the same execution model described in F.9.2 Execution Model Using Postman Collections, including:

  1. Checkout request
  2. Method-specific operation
  3. Status validation

For example:

  • SPG Sandbox Collection → CARD → Card – Success → Checkout Card
  • SPG Sandbox Collection → CARD → Card – Success → Purchase
  • SPG Sandbox Collection → CARD → Card – Success → Status

Execution within a scenario requires:

  • Running requests in the defined order
  • Capturing and reusing identifiers generated during the flow
  • Validating the final state using the status request

Scenario Coverage

The Sandbox collection includes scenarios representing different types of behavior, such as:

  • Successful transactions
  • Declined transactions
  • Validation and error responses
  • Other predefined operational cases

These scenarios allow integrators to validate:

  • Normal execution paths
  • Error handling behavior
  • Response interpretation logic

The exact set of available scenarios depends on the payment method and is defined within the collection.

Consistency Across Executions

To ensure reliable deterministic testing:

  • Each scenario should be executed independently
  • Identifiers generated during execution must be used consistently across requests
  • Data from previous executions should not be reused

To maintain consistency:

  • Always begin with the checkout request within the scenario
  • Avoid reusing identifiers from previous runs
  • Validate outcomes using the status endpoint

These practices ensure that each execution reflects the expected behavior defined by the scenario.

Relationship with Production Behavior

The Sandbox environment provides controlled and predefined scenarios intended for validation and testing.

It is important to note that:

  • Sandbox scenarios are designed to produce consistent outcomes
  • Production environments may involve additional variability and external factors

As a result:

  • Sandbox testing should be used to validate implementation logic and handling
  • Production validation should consider real execution conditions

For further details, refer to F.8.4 Sandbox vs Production Behavioral Gap.

Execution Considerations

When executing Sandbox scenarios:

  • Select the appropriate scenario for the behavior being tested
  • Use the requests defined within that scenario
  • Execute all steps in sequence
  • Verify responses at each step
  • Confirm final outcomes using the status request

These considerations ensure that testing remains aligned with the defined scenario behavior.

Final Consideration

The SPG Sandbox Collection enables integrators to perform deterministic and reproducible testing using predefined scenarios.

A correct use of these scenarios requires:

  • Executing flows as defined within each scenario
  • Reusing identifiers generated during execution across dependent requests
  • Validating outcomes through the status endpoint

By following these principles, integrators ensure that their implementation is consistent, testable, and aligned with the expected behavior defined within the SPG Sandbox environment.

Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.

Strictly Necessary Cookies

Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.