> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/features/refunds.md). # Refunds Return money to your customers correctly – full or partial, one transaction or in bulk, from the Merchant Portal or the API. The SEB Ecommerce Payment Gateway supports the initiation and management of refunds for completed transactions across payment methods. Refunds are always issued to the original payer – the money goes back the way it came. {% hint style="info" %} Before refunding, know which of two operations you actually need: a refund returns money the customer has already paid, while a reversal releases a pre-authorization before any money moved. Choosing the right one matters – a reversal is faster for the customer and cheaper for you. {% endhint %} *** ### Refund or Reversal?

	Reversal (Void)	Refund
When it applies	The payment is Authorized (pre-authorization) and not yet captured	The payment is Captured or Settled – the customer has paid
What it does	Releases the reserved amount on the customer’s card – no money ever moved	Returns money to the original payer
Full / partial	Full and partial reversals may be supported, subject to transaction status, acquiring configuration, and scheme rules	Full and partial refunds, including multiple partial refunds per transaction
Resulting payment status	Cancelled	Refunded
Applies to	Card payments	Card payments, wallets, Pay by Bank, PayPal (per method rules below)

{% hint style="info" %} Rule of thumb: if you cancel an order before capture – reverse; after the customer has paid – refund. See Supported Operations for the card operation details. {% endhint %} *** ### How to Initiate a Refund * [Merchant Portal](/guides/merchant-portal.md). Initiate refunds for individual transactions directly from the transaction details – no integration needed. Suitable for day-to-day customer service. * [Merchant API](/integration/merchant-api.md). Initiate refunds programmatically – including bulk refund initiation for card payments, for scenarios like mass cancellations or recalls. Both channels use the same refund service and follow the same business rules, validation, and eligibility requirements. Customer authentication is not required for refunds. *** ### Rules by Payment Method

Payment Method	What Applies	Details
Cards (Visa, Mastercard)	Full, partial, and multiple refunds – up to the original transaction value. Portal and API initiation; bulk via API. Processing goes through the acquiring systems and remains subject to card scheme rules.	Supported Operations
Apple Pay/Google Pay/Click to Pay	Processed as card payments – the same refund rules and channels apply.	Wallet pages
Pay by Bank (A2A)	Automated refunds for eligible transactions: settled to your SEB settlement account, within the supported refund period, to the original payer, up to the remaining refundable amount.	Pay by Bank › Refunds
PayPal	Executed by PayPal under its own framework; refunds can be issued from your PayPal business account. Availability of initiation through the gateway depends on your configuration.	PayPal › Refunds and Disputes

*** ### Refund Lifecycle and Statuses Refund processing follows its own lifecycle with dedicated statuses – for example, Processing, Completed, and Reverted: * Every refund request is validated before processing – the original payment must exist and be eligible, the amount must not exceed the remaining refundable balance, and no conflicting refund request may be in progress. * When a refund reaches Completed, the payment status changes to Refunded – for both full and partial refunds – and a callback notification is sent. * Multiple partial refunds are supported until the original amount is fully refunded; the payment keeps a remaining refundable balance in between. * If a refund is reverted, the payment status may return to Settled, provided no other completed refunds remain. * Each refund is linked to its original transaction with a unique reference, supporting traceability and reconciliation – refund status retrieval is available alongside payment status. See Cards [Payment Statuses](/payment-methods/cards/payment-statuses.md) and Pay by Bank [Payment Statuses](/payment-methods/pay-by-bank/payment-statuses.md) for how refund-driven changes fit the overall payment lifecycle. *** ### What the Customer Sees The refund returns to the payment method the customer originally used – their card, bank account, or PayPal balance. Refunds cannot be redirected to a different card or account. How quickly the money appears for the customer depends on their card issuer or bank; communicate realistic timelines in your refund policy rather than promising instant returns. *** ### Merchant Best Practices * Choose the right operation: reverse uncaptured authorizations instead of waiting for capture and refunding. * Verify eligibility before initiating – especially the remaining refundable balance and, for Pay by Bank, the settlement account and refund period conditions. * Process refund-driven callback notifications idempotently – a duplicate notification must not create a duplicate refund record or customer email. * Restrict refund initiation rights in the Merchant Portal and protect the API credentials used for refunds – refunds move money out. * Store the original payment reference with every refund, and reconcile refunds against your account statements. * Publish a clear refund policy – what qualifies, how to request, and how long it takes. *** ### Frequently Asked Questions

Can I refund more than the original payment amount?

No. The total refunded amount across all refunds can never exceed the original transaction value. The gateway validates every request against the remaining refundable balance.

Can I refund to a different card or account?

No. Refunds are always issued to the original payer through the original payment method. If that is impossible – for example, a closed account – handle the return outside the gateway according to your own procedures.

How many partial refunds can I make?

Multiple partial refunds are supported until the original amount has been refunded in full.

Can I process refunds in bulk?

Yes – bulk refund initiation is supported via the Merchant API for card payments. Portal-based initiation covers individual transactions.

Does the customer need to authenticate a refund?

No. Customer authentication is not required when a refund is initiated.

The refund was accepted – why doesn’t the customer see the money yet?

Once processed, the time for funds to appear depends on the customer’s card issuer or bank. Point customers to their bank for posting timelines, and keep the refund reference at hand for support cases.

Why was my refund request rejected?

Common reasons: the original payment cannot be identified or is not eligible, the requested amount exceeds the remaining refundable balance, another refund for the payment is currently being processed, or – for Pay by Bank – the settlement or refund period conditions are not met. See the method-specific pages for details.

*** ### Related Documentation * [Supported Operations](/payment-methods/cards/supported-operations.md) * [Payment Statuses](/payment-methods/cards/payment-statuses.md) * Pay by Bank › [Payment Statuses](/payment-methods/pay-by-bank/payment-statuses.md) * Pay by Bank › [Refunds](/payment-methods/pay-by-bank/refunds.md) * PayPal › [Refunds and Disputes](/payment-methods/wallets/paypal.md) * [Callback Notifications](/integration/merchant-api/webhooks.md) * [Merchant Portal](/guides/merchant-portal.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/features/refunds.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.