Overview

Omnichannel Transaction Status allows merchants to retrieve operational visibility for transactions that were originally initiated outside standard SIBS Payment Gateway checkout flows.

This capability enables merchants to monitor the state of transactions processed through external SIBS channels while maintaining centralized visibility through the SIBS Payment Gateway.

Unlike traditional transaction status flows that operate on transactions originally created through SPG checkout integrations, Omnichannel Transaction Status is designed for transactions originating from channels such as:

• Traditional POS
• xPOS
• SmartPOS
• softPOS

This allows merchants to maintain operational consistency across multiple payment channels through a unified transaction visibility model.

What Is Omnichannel Transaction Status

Omnichannel Transaction Status is an operational capability that allows merchants to retrieve the current state of transactions originally processed through external payment channels.

This model enables merchants to:

• Retrieve transaction state information
• Verify operational outcomes
• Monitor refund outcomes
• Support customer service operations
• Maintain centralized transaction visibility across channels

From a technical perspective, the original transaction is created outside standard SPG checkout flows, while status retrieval is performed through SIBS Payment Gateway APIs.

When to Use Omnichannel Transaction Status

Omnichannel Transaction Status is appropriate when merchants need operational visibility over externally initiated transactions.

Typical scenarios include:

• Verifying transaction completion
• Confirming refund execution
• Customer support investigations
• Operational reconciliation
• Investigating failed operational actions
• Cross-channel transaction monitoring

This model is particularly useful for merchants operating unified commerce environments.

Supported Status Scenarios

Within the current SIBS ecosystem, Omnichannel Transaction Status may be used to verify:

• Original transaction completion
• Refund processing status
• Final operational outcomes
• Transaction history visibility

Available information may vary depending on the originating channel.

Execution Model

The Omnichannel Transaction Status flow typically follows this sequence:

1. Original transaction is created through an external payment channel
2. Merchant stores the relevant transaction reference
3. Merchant performs a Status Inquiry request through SPG
4. SPG retrieves available transaction information
5. Current transaction status is returned

This model provides centralized visibility without requiring merchants to interact directly with multiple operational systems.

Transaction Visibility Model

Unlike standard checkout transactions, where merchants typically control the entire payment lifecycle directly, Omnichannel transactions may involve visibility dependencies on external channels.

This means:

• Available transaction data may vary
• Some operational events may be delayed
• Status granularity may differ across channels
• Refund visibility may depend on refund lifecycle progression

Merchants should design operational workflows with these visibility differences in mind.

Common Status Use Cases

Merchants frequently use Omnichannel Transaction Status for:

Refund Validation

Confirm whether an Omnichannel refund has been completed successfully.

For refund-specific operations, refer to D.4.1 Omnichannel Refund.

Customer Support Operations

Verify transaction outcomes during customer service interactions.

Operational Reconciliation

Validate transaction states during internal reconciliation processes.

Exception Handling

Investigate operational anomalies across multiple payment channels.

Particularities in the SIBS Context

When working with Omnichannel Transaction Status in SIBS SPG, merchants should consider:

• Original transaction references are mandatory
• Status visibility depends on originating channel data
• Operational timing may vary across channels
• Some transactions may require follow-up verification
• Cross-channel reconciliation remains critical

Proper transaction traceability is essential to avoid operational inconsistencies.

The SPG transactionID should be treated as the primary and authoritative identifier for transaction monitoring, operational correlation, status validation, reconciliation, and lifecycle visibility activities.

For standard SPG transaction lifecycle handling, refer to E. Notifications and Transaction Status.

For complete Status Inquiry endpoint specifications and response interpretation, refer to E.2 – Status Inquiry / Get Status.

Operational Risks

Merchants should avoid:

• Assuming immediate status finality
• Losing transaction references
• Ignoring asynchronous operational updates
• Building channel-specific assumptions into core workflows
• Failing to reconcile operational outcomes

Operational monitoring should remain resilient to timing differences between payment channels.

For webhook delivery behaviour and asynchronous operational notifications, refer to E.1 – Webhooks (Notifications).

Practical Omnichannel transaction monitoring examples, Postman collections, and operational testing scenarios are documented in F. Technical Examples and Best Practices.

Integration Context

In the SIBS Payment Gateway, Omnichannel Transaction Status typically requires:

• Original transaction identifiers and cross-channel transaction references
• Server-to-server API integration
• Internal operational monitoring logic
• Reconciliation workflows

These operations are typically executed through backend systems and are not customer-facing checkout flows.

Detailed request and response specifications are available in the API reference documentation.

Summary

Omnichannel Transaction Status extends SIBS Payment Gateway operational visibility by allowing merchants to monitor transactions originally created outside standard SPG checkout environments.

This enables centralized transaction monitoring across multiple payment channels while improving operational consistency, customer support capabilities, and reconciliation efficiency.

Understanding transaction visibility limitations and cross-channel operational dependencies is essential before implementing Omnichannel transaction monitoring workflows.