Overview

Reproducibility in Sandbox testing requires that each transaction flow can be executed multiple times with consistent inputs, controlled execution, and predictable outcomes.

A flow is only considered reproducible if it produces the same observable results when executed under the same conditions.

These requirements apply to flows executed through the official Postman collections, which provide the standard mechanism for Sandbox scenario execution (see Postman collections available in Chapter F.1 – End-to-End Integration Examples).

This chapter defines the mandatory requirements that must be satisfied to ensure that Sandbox executions are reliable, verifiable, and suitable for integration validation.

These requirements apply to flows structured according to F.8.2 – Structure of a Reproducible Sandbox Flow and executed using the deterministic scenarios defined in F.8.1 – Deterministic Scenario Modeling in Sandbox.

Deterministic Input Definition

All reproducible flows must be based on deterministic inputs.

This means:

• The same request payload structure must be used across executions
• Scenario-specific values must remain consistent
• Required fields must be explicitly defined and not inferred

In Sandbox scenario execution, these inputs may include specific values defined in the merchant.merchantTransactionId field of the Checkout request, as documented in the Postman collections. These values are part of the predefined request configuration and must be used as provided to ensure reproducible outcomes.

Any variation in input configuration may result in:

• Different transaction behavior
• Inconsistent outcomes
• Invalid validation results

Deterministic input definition is a foundational prerequisite for reproducible Sandbox validation.

Controlled Execution Sequence

Reproducibility requires that the execution sequence is strictly controlled and consistently applied.

Each flow must:

• Follow the defined structure (Initialization → Execution → Validation)
• Execute all required steps in the correct order
• Avoid skipping or reordering phases

Execution must always be treated as a complete lifecycle, not as isolated API calls.

Any deviation from the defined sequence invalidates reproducibility.

The required execution structure is defined in F.8.2 – Structure of a Reproducible Sandbox Flow.

Transaction Isolation

Each execution must operate on a fully isolated transaction context.

This implies:

• A new transaction must be created for each test execution
• No reuse of previous transactionID values
• No dependency on the lifecycle state of prior executions

Isolation ensures that:

• Results are not influenced by previous tests
• State transitions remain predictable
• Validation remains accurate

Consistent Use of transactionID

All phases of the flow must consistently use the same:

• transactionID

This identifier:

• Is generated during the Initialization phase
• Must be propagated to all subsequent steps
• Must be used for all validation operations

Failure to maintain consistent usage of transactionID leads to:

• Loss of traceability
• Invalid state validation
• Incorrect test conclusions

Stable Expected Outcomes

Each reproducible scenario must have a clearly defined and stable expected outcome.

This includes:

• Expected paymentStatus
• Expected returnStatus.statusCode
• Expected transaction lifecycle behavior

Expected outcomes must:

• Be known before execution
• Remain consistent across repeated runs
• Be used as the baseline for validation

If expected outcomes vary, the scenario is not reproducible.

Explicit Validation Criteria

Reproducibility requires explicit and verifiable validation criteria.

Each flow must define:

• What constitutes a successful outcome
• What constitutes a failure
• What conditions must be checked after execution

Validation must be based on:

• Confirmed final transaction state via Status Inquiry / Get Status
• Consistency between observed and expected results

Implicit or assumed validation is not acceptable.

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

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

Idempotency and Duplicate Handling Awareness

Reproducible flows must account for:

• Idempotency behavior
• Duplicate request handling

This implies:

• Avoiding unintended reuse of request identifiers
• Ensuring that repeated executions do not interfere with each other
• Understanding how duplicate operations are handled by the system

Failure to control these aspects may result in:

• Unexpected responses
• False validation outcomes

Environment Consistency

All reproducible flows must be executed under consistent environment conditions.

This includes:

• Using the same Sandbox environment
• Maintaining consistent configuration (credentials, endpoints, headers)
• Avoiding cross-environment execution within the same flow

Environmental inconsistencies may lead to:

• Divergent behavior
• Invalid comparisons between executions

Error and Edge Case Reproducibility

Reproducibility applies equally to:

• Successful scenarios
• Error scenarios
• Edge cases

For these scenarios:

• The same structure (Initialization → Execution → Validation) must be preserved
• The expected outcome must be clearly defined
• Validation must confirm the specific error or edge condition

Error scenarios are considered reproducible only if they produce consistent and verifiable outcomes.

Observability and Traceability

Reproducibility requires sufficient observability and traceability of each execution.

This implies:

• Logging of all request and response data
• Clear association between requests and the corresponding transactionID
• Ability to trace the full lifecycle of each transaction

In practice, Postman collections provide built-in mechanisms for capturing request and response data, which support traceability and validation of reproducible flows.

Observability guarantees that transaction-state evolution can be verified consistently across the full lifecycle and supports reliable validation, debugging, and operational analysis.

Without proper observability:

• Reproducibility cannot be verified
• Debugging becomes unreliable

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.

Final Requirement

A Sandbox flow is considered reproducible only if all of the following conditions are satisfied:

• Inputs are deterministic
• Execution sequence is controlled and complete
• Transactions are isolated
• transactionID is used consistently
• Expected outcomes are stable and predefined
• Validation criteria are explicit and verifiable

If any of these conditions is not met, the flow cannot be considered reproducible and must not be used for integration validation.

These requirements ensure reproducibility within the Sandbox environment and must be interpreted in the context of the behavioral differences between Sandbox and Production described in F.8.4 – Sandbox vs Production Behavioral Gap.