Overview

Omnichannel Refund allows merchants to initiate refund operations for transactions that were originally processed outside standard SIBS Payment Gateway checkout flows.

This capability enables merchants to centralize refund operations across multiple payment channels while maintaining operational consistency through the SIBS Payment Gateway.

Unlike traditional refund flows that operate on transactions originally created through SPG checkout integrations, Omnichannel Refund is specifically designed for transactions originating from channels such as:

• Traditional POS
• xPOS
• SmartPOS
• softPOS

This allows merchants to manage refunds through a unified operational model across both physical and digital payment environments.

What Is an Omnichannel Refund

An Omnichannel Refund is a post-payment operation that allows a merchant to return funds to the customer after the original transaction has already been completed through another payment channel.

This model allows merchants to:

• Refund transactions initiated outside SPG checkout
• Centralize refund processing logic
• Maintain unified operational controls
• Reduce fragmentation between payment channels

From a technical perspective, the original transaction is created externally, while the refund operation is initiated through SIBS Payment Gateway APIs.

When to Use Omnichannel Refund

Omnichannel Refund is appropriate when merchants need to reverse previously completed transactions that originated through non-standard SPG channels.

Typical scenarios include:

• Product returns in physical stores
• Order cancellations after in-store payment
• Operational refund requests initiated by customer support teams
• Unified commerce refund workflows
• Partial order reversals
• Cross-channel refund management

This model is particularly valuable for merchants operating both online and physical payment channels.

Refund Eligibility

Before initiating a refund, merchants should validate whether the original transaction is eligible for refund processing.

Eligibility may depend on:

• Original transaction status
• Settlement status
• Payment method rules
• Refund time limitations
• Merchant configuration rules
• Channel-specific restrictions

Some transactions may not be eligible for refund if the original payment has not reached a refundable state.

Execution Model

The Omnichannel Refund flow typically follows this sequence:

1. Original transaction is completed through an external payment channel
2. Merchant identifies the original transaction
3. Merchant initiates refund request through SPG
4. SPG validates refund eligibility
5. Refund is processed through the appropriate payment infrastructure
6. Refund result is returned or made available through subsequent status verification

Depending on the originating channel, refund processing timelines may vary.

Full vs Partial Refunds

Depending on merchant configuration and payment channel capabilities, refund operations may support:

Full Refunds

The merchant refunds the entire original transaction amount.

Typical scenarios include:

• Order cancellation
• Full product return
• Service cancellation

Partial Refunds

The merchant refunds only part of the original transaction amount.

Typical scenarios include:

• Partial returns
• Order adjustments
• Service modifications

Partial refund support may depend on the originating payment channel configuration.

Refund Lifecycle

Omnichannel refunds typically follow this lifecycle:

1. Refund request initiated
2. Refund validation
3. Refund processing
4. Refund accepted or rejected
5. Final refund confirmation

Some refunds may require additional operational verification depending on the originating channel.

Particularities in the SIBS Context

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

• Original transaction identifiers are mandatory
• Refund limits may apply
• Partial refund rules may vary
• Refund eligibility depends on original transaction state
• Cross-channel reconciliation must be maintained
• Some channels may introduce operational restrictions

Proper transaction traceability is essential to avoid duplicate refunds or reconciliation issues.

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

For transaction visibility after refund initiation, refer to D.4.2 – Omnichannel Transaction Status.

For transaction lifecycle monitoring and refund status validation, refer to E.2 – Status Inquiry / Get Status.

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

Operational Risks

Merchants should avoid:

• Attempting refunds on invalid transactions
• Losing original transaction references
• Performing duplicate refund attempts
• Ignoring asynchronous refund confirmations
• Failing to reconcile refund activity across channels

Proper operational controls should be implemented before moving to production.

For duplicate protection strategies, refer to F.6.2 – Idempotency and Duplicate Protection.

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

Integration Context

In the SIBS Payment Gateway, Omnichannel Refund typically requires:

• Original transaction identifiers and cross-channel transaction references
• Refund amount information
• Server-to-server API integration
• Internal reconciliation logic

These operations are 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 Refund extends SIBS Payment Gateway operational capabilities by allowing merchants to refund transactions originally created outside standard SPG checkout environments.

This enables centralized refund management across multiple payment channels while preserving operational consistency, traceability, and financial control.

Understanding refund eligibility, transaction traceability, and reconciliation requirements is essential before implementing Omnichannel refund operations.