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)

  • Chargebacks are not applicable — Open Banking A2A payments do not support disputes via scheme rules as in card systems

  • Refunds are a goodwill or contractual obligation, not a technical reversal

  • AML/KYC compliance checks on the refund recipient (payer) are the responsibility of the bank hosting EGW

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:

  1. Refund Initiation - The merchant initiates a refund request via EGW’s portal or API, referencing the original Open Banking payment.

  2. New A2A Transfer - EGW triggers a new outbound credit transfer (payout) from the merchant’s account to the original payer’s account.

  3. 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

  4. Status and Tracking - EGW links the refund to the original payment for reporting and reconciliation but technically treats it as a new transaction.

  • Chargebacks are not applicable — Open Banking A2A payments do not support disputes via scheme rules as in card systems

  • Refunds are a goodwill or contractual obligation, not a technical reversal

  • AML/KYC compliance checks on the refund recipient (payer) are the responsibility of the bank hosting EGW

Merchant Portal Capabilities for Refunds

Feature
Description

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?