Overview

The Postman collections provided for the SIBS Payment Gateway (SPG) rely on runtime variable management and request chaining to enable the correct execution of dependent API operations.

This mechanism ensures that data produced during one step of a transaction flow is captured, stored, and reused in subsequent requests, allowing the execution model described in F.9.2 Execution Model Using Postman Collections to function correctly.

Rather than requiring manual input between requests, the collections implement automated data propagation, ensuring consistency, accuracy, and repeatability across transaction flows.

Types of Variables Used

The collections make use of standard Postman variable scopes, including:

• Environment variables
  Used for configuration values required to execute requests, such as:
  • {{host}}
  • {{ClientID}}
  • Authentication credentials
• Global variables
  Used to store values extracted from API responses during execution, such as:
  • transactionID
  • transactionSignature

These variables allow requests to be parameterized and reused without modifying individual request definitions.

Variable Extraction from Responses

During execution, the collections use Postman test scripts to extract specific fields from API responses and store them in variables.

For example, after executing:

• SPG Payment Gateway Collection → Card → Checkout Card

The response contains identifiers required for subsequent operations. These are extracted and stored using scripts such as:

var jsonData = pm.response.json();
pm.globals.set("transactionID", jsonData.transactionID);
pm.globals.set("transactionSignature", jsonData.transactionSignature);

This ensures that:

• Required identifiers are captured immediately after generation
• Subsequent requests can reference these values dynamically
• Manual copying of values is not required

Variable Injection into Requests

Once variables are stored, they are referenced dynamically in subsequent requests, typically in:

• URL paths
• Headers
• Request bodies

For example:

• Endpoint usage:
  {{host}}/payments/{{transactionID}}/card/purchase
• Header usage (where applicable):
  Authorization: Digest {{transactionSignature}}

These references ensure that each request is executed using the correct transaction context generated during the flow.

Request Chaining Mechanism

Request chaining is achieved through the combination of variable extraction and variable reuse, forming a continuous execution flow.

For example:

1. Checkout request
   • Generates transactionID and transactionSignature
   • Stores them in variables
2. Subsequent operation (e.g., purchase or reference generation)
   • Uses transactionID in the endpoint
   • Uses transactionSignature where required
3. Status request
   • Uses transactionID to retrieve the transaction state

This dependency model ensures that:

• Each request is executed using the identifiers generated in previous steps
• The same transaction context is reused across operations
• Execution aligns with the expected sequence of SPG operations as defined in the collections

Variable Scope and Lifecycle

Variables follow a runtime lifecycle within Postman:

• Values are assigned during request execution
• They persist until overwritten or the session is reset
• They are reused across subsequent requests within the same execution flow

It is important to ensure that:

• Variables are correctly initialized before use
• Values from previous executions do not interfere with new runs
• The appropriate scope (environment vs global) is used depending on the variable type

Handling of Multiple Executions

When executing multiple flows:

• Variables may be overwritten with new values
• Each execution should be treated as a separate transaction flow with newly generated identifiers

To avoid inconsistencies:

• Ensure that checkout is executed before dependent operations
• Avoid reusing outdated identifiers from previous runs
• Reset or validate variables if necessary before starting a new flow

Consistency Across Collections

The same variable management and chaining principles apply across:

• SPG Payment Gateway Collection
• SPG Sandbox Collection

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 all cases, variables generated in the checkout step are reused in subsequent requests within the same scenario.

Execution Considerations

To ensure correct variable handling and chaining:

• Execute requests in the defined order within the collection
• Verify that variables are correctly populated after each step
• Avoid manual modification of runtime variables during execution
• Ensure that required environment variables are configured before starting

These considerations ensure that request chaining operates correctly and that execution remains consistent with the expected SPG behavior.

Final Consideration

Variable management and request chaining are fundamental to the correct execution of SPG Postman collections.

A correct integration requires:

• Capturing and reusing identifiers and required fields produced by API responses
• Ensuring that all dependent requests reference the correct identifiers
• Ensuring that variables consistently reference the correct transaction identifiers throughout the execution flow

By following these principles, integrators ensure that transaction flows are executed in a consistent, accurate, and reproducible manner, aligned with the operational model of the SPG platform.