# 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) {% hint style="info" %} * 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 {% endhint %} ## 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. {% hint style="info" %} * 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 {% endhint %} ## 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 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://doc.ecomm.api.tietoevry.com/features/payment-rollback-and-refunds.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.