---
title: "Refunds and payouts"
description: "Be ready for an increase in (omnichannel) refunds and desired changes in payout schedules."
url: "https://docs.adyen.com/industries/peak-season/refunds"
source_url: "https://docs.adyen.com/industries/peak-season/refunds.md"
canonical: "https://docs.adyen.com/industries/peak-season/refunds"
last_modified: "2026-06-01T15:33:16+02:00"
language: "en"
---

# Refunds and payouts

Be ready for an increase in (omnichannel) refunds and desired changes in payout schedules.

[View source](/industries/peak-season/refunds.md)

A large increase in transactions means an increase in shoppers returning their purchases. Because many of the purchases during peak season are presents, you can also expect an increase in people returning unwanted gifts. A complicating factor can be that people want to return an item that was bought online at a physical store.

To be able to deal with a spike in refunds, we recommend the following:

* Set up a [refund reserve](#refund-reserve).
* Determine a [strategy for refunds per channel](#refunds-per-channel): ecommerce, point of sale, and omnichannel.

Also, a large increase in transactions often sparks a desire to receive more frequent [payouts](#payouts). Check how this works, and be sure to make any changes to the payout frequency or payout accounts before peak season.

## Refund reserve

Usually, the payable balance on your Adyen merchant account is enough to cover the costs of refunds and chargebacks. But during peak season that may not be the case due to a spike in refunds and chargebacks, and refunds can fail. To ensure there is sufficient cash when customers ask for a refund and to reduce operational stress during peak season, you should [set up a reserve](/account/balances/reserve).

You do this by setting a threshold: the amount that you want to be available in the reserve. If you have already set up a reserve, you can temporarily increase the threshold for peak season.

To fill the reserve up to the threshold, you have various options. You can:

* Set up [auto-funding](/account/balances/reserve#auto-funding). When a certain percentage of the reserve is used, the reserve is filled to 100 percent through an automatic direct debit from the bank account where you receive the payouts for your merchant account.
* [Top-up](/account/balances/reserve#top-up) the reserve through a payment link for a manual bank transfer. Do this in time, because a bank transfer can take a day or two.
* [Transfer funds](/account/balances/reserve#transfer-balance) from one merchant account to the other.

## Refunds per channel

There are differences in how to handle refunds per channel. For example, for in-store payments, Adyen offers referenced and unreferenced refunds. Familiarize yourself with refunds for the following channels:

* [Ecommerce](#ecommerce-refunds)
* [Point of sale](#point-of-sale-refunds)
* [Omnichannel](#omnichannel-refunds)

### Ecommerce refunds

Refunds using the Checkout API [/payments/{paymentPspReference}/refunds](https://docs.adyen.com/api-explorer/Checkout/latest/post/payments/\(paymentPspReference\)/refunds) endpoint are referenced refunds, where the **PSP reference** identifies the original payment that is being returned. Many [payment methods support partial refunds](/payment-methods) for an amount that is less than the captured amount.

You get the outcome of the refund request asynchronously, in a webhook message with the `eventCode` **REFUND**. [If a refund does not pass validation](/online-payments/refund#failed-refund-request), we inform you using the `reason` field of the webhook message. Use this information to decide if you should make a new, amended refund request or contact the shopper.

In rare cases, a refund that was successfully validated, is still declined. You then get a webhook message with the `eventCode` **REFUND\_FAILED**. You should [test failed refunds](/online-payments/refund), to ensure your integration can handle that scenario.

### Point-of-sale refunds

In-store refunds are processed asynchronously, just like ecommerce refunds. There are two types of in-store refunds. You can implement one or both refund types:

* [Referenced refunds](/point-of-sale/basic-tapi-integration/refund-payment/referenced) are connected to the original payment using the unique identifier of that payment. This identifier consists of the **tender reference** generated by the payment terminal and the **PSP reference** generated by the Adyen payments platform. You are informed of the outcome in a webhook message with the `eventCode` **REFUND**.

* [Unreferenced refunds](/point-of-sale/basic-tapi-integration/refund-payment/unreferenced) let you return any amount to any card presented to the payment terminal. This carries a risk of return fraud (a payment being refunded multiple times) and human error (store staff enter the wrong refund amount). If you happen to know the tender reference of the original payment, you should provide that. Otherwise, you need to provide a **reference of your own**, for reconciliation purposes. You are informed of the outcome in a webhook message with the `eventCode` **REFUND\_WITH\_DATA**.

  To make unreferenced refunds safer, consider setting up a [refund delay](/point-of-sale/basic-tapi-integration/refund-payment/unreferenced#enable-unreferenced-refunds) so you have time to [cancel an unreferenced refund](/point-of-sale/basic-tapi-integration/refund-payment/cancel-unreferenced) if a mistake was made. Also, consider checking beforehand if the card that the shopper presents to the terminal is the [same card that was used for the original payment](/point-of-sale/shopper-recognition/before-refund).

#### Point-of-sale refunds and offline payments

As described under [in-person payments](/industries/peak-season/in-person-payments#offline-payments), you can set up offline payments, to be able to continue accepting payments when internet access is temporarily unavailable. If you also want to be able to issue refunds in that situation, you should set a [maximum transaction amount for offline refunds](/point-of-sale/basic-tapi-integration/refund-payment/unreferenced#enable-unreferenced-refunds).

Note that while offline, referenced refunds are not supported. [You can only make unreferenced refunds](/point-of-sale/offline-payment#making-refunds-while-offline/).

When the internet connection is restored and you want to make a referenced refund for a payment that was made while offline, you need to [accommodate the fact that the PSP reference is missing from the offline payment response](/point-of-sale/basic-tapi-integration/refund-payment/referenced#refund-offline-payment).

### Omnichannel refunds

Customers appreciate the possibility of omnichannel returns, allowing them to return an ecommerce purchase to a physical store, or return their in-store purchase by sending it to your distribution center. Such refunds are deducted from the [in-process funds](https://help.adyen.com/en_US/knowledge/payments/refunds/what-funds-do-i-have-available-for-refunds) of the merchant account that processed the original payment.

Omnichannel refunds are always referenced refunds, and you need to [rely on webhook messages](/unified-commerce/referenced-refunds#refund-webhook) to know what **PSP reference** to use in your Checkout API or Terminal API refund request.

An ecommerce payment does have a PSP reference, but the tender reference is missing because that is generated by the terminal. This means that to [refund an ecommerce payment at the point of sale](/point-of-sale/basic-tapi-integration/refund-payment/referenced#refund-ecommerce-payment), you need to know the PSP reference, the date, and the currency of the original payment.

## Payouts

With more funds coming in, you may want to get paid out by Adyen more frequently. Or if you are a platform or a marketplace, you may want pay out your users more frequently. Our general advice is to not change the **payout frequency** during peak season, to avoid friction and mistakes during this critical period. If you expect a need for more frequent payouts, make that change *before* peak season.

It is also not advisable to change **payout accounts** during peak season. If there is a need to change a payout account, try to do that *before* peak season, to get the change approved by us in time.

### Direct merchants

If you are what we call a "direct merchant", which means not a platform or a marketplace, be aware that [changes to the payout frequency](/account/getting-paid#payout-frequency) are not effective immediately. Instead, those changes work similarly to a subscription: A change in the schedule takes effect at the start of the next period of the original schedule. For example, if in September you initiate a switch from monthly payouts to weekly payouts, you get a monthly payout for September and the weekly payouts start in October.

### Adyen for Platforms

If you are a platform or a marketplace and want to pay out your users more frequently, any changes to the [push sweeps](/platforms/custom-payouts) are effective immediately. However, as mentioned before, our recommendation is to not change the sweeps during peak season.

## See also

* [Reserve](/account/balances/reserve/)
* [Omnichannel returns](/unified-commerce/referenced-refunds/)
* [Refunding in-person payments](/point-of-sale/basic-tapi-integration/refund-payment/)
* [Offline POS payments and refunding](/point-of-sale/offline-payment/#making-refunds-while-offline/)
* [Refunding online payments](/online-payments/refund/)
