Payment rollback and refunds
The E-Commerce Payment Gateway supports both refunds (business-initiated returns of funds) and payment rollbacks (technical or operational reversals), with mechanisms tailored for card transactions and A2A payments, based on industry best practices and payment scheme rules.
Card Payment Refunds
Use Cases
Customer-initiated returns (full or partial)
Failed service/product delivery
Subscription cancellation
Functionality in EGW
Refunds can be initiated via API or the Merchant Portal
Supports full and partial refunds
Refunds are linked to the original transaction reference
Multiple partial refunds are supported until the full amount is exhausted
Merchants can configure refund limits and role-based access
Processing Logic
EGW sends refund requests to the card acquirer
The acquirer processes the refund through the card scheme (Visa, Mastercard)
Refunds typically settle within 3–5 banking days depending on issuer and scheme rules
Reconciliation
EGW tracks and logs all refund statuses
Refund entries are included in merchant reports and reconciliation files
Refund settlement may appear in separate clearing batches from original sales
A2A (Account-to-Account) Rollbacks and Refunds
Use Cases
Technical errors (e.g. timeouts or duplicates)
Customer refund request
Merchant-initiated return of funds
Regulatory/consumer protection obligations
Limitations by Nature
Instant A2A payments are irrevocable by design (e.g. SEPA Instant, TIPS, Faster Payments)
Refunds must be initiated as a new credit transfer
No native “reversal” exists at the scheme level
Functionality in EGW
Refunds initiated through EGW are treated as new outbound A2A payouts
EGW links the refund to the original transaction for traceability
Merchant can use APIs or the Portal to process refunds with:
Original reference
Refund reason
Audit trail linkage
Optional Risk Controls
EGW can enforce refund limits, daily thresholds, and user role permissions
Approval workflows for high-value A2A refunds
Event triggers for refund review (e.g. by fraud or dispute team)
Open Banking Refunds
Open Banking payments, initiated via PISPs (Payment Initiation Service Providers), are processed over A2A rails and are typically instant and irrevocable. Once funds are transferred from the payer’s bank to the merchant’s account, there is no native refund or reversal mechanism built into the Open Banking frameworks (e.g., Berlin Group, UK OBIE).
However, refunds are supported at the application level and must be treated as new credit transfers initiated by the merchant or the bank holding the funds.
How Refunds Work in EGW
When EGW handles Open Banking payments, the refund process follows this logic:
Refund Initiation - The merchant initiates a refund request via EGW’s portal or API, referencing the original Open Banking payment.
New A2A Transfer - EGW triggers a new outbound credit transfer (payout) from the merchant’s account to the original payer’s account.
Bank System Integration - Since EGW does not hold funds, it integrates with the bank’s internal systems (ledger/core) to:
Validate and authorize the refund
Book the refund transaction
Execute the transfer via SEPA or local A2A rails
Status and Tracking - EGW links the refund to the original payment for reporting and reconciliation but technically treats it as a new transaction.
Merchant Portal Capabilities for Refunds
Initiate Refund
Select transaction and enter refund amount and reason
Refund History
Track refund status and link to original transaction
Partial Refund
Define specific refund amounts; supports multiple partials
User Controls
Role-based access and dual-approval (optional)
Export Logs
Download refund activity reports for reconciliation
Security & Controls
Refunds are only allowed for completed incoming payments
Configurable limits and approval workflows can be enforced in the portal
Role-based permissions determine who can view and initiate refunds
Full audit trail and logs available for compliance and dispute handling
Last updated
Was this helpful?