A Crypto Refund Now Takes About an Hour. The Days Come Before It

A customer wants their money back and asks how long it will take. What do you tell them?

Most of the answer sits outside the transfer. Since the middle of June 2026, the median merchant refund is sent about an hour after it is created, and the median shopper refund request in 23 minutes. The days your customer counts mostly come before anyone presses the button.

Here is how both halves measure across every refund created on CoinGate between September 2025 and August 2026, what changed in June, and what to tell a customer who is waiting.

---

Setting expectations for your support team? Open a CoinGate account.

---

Two refunds, two starting points

Before any numbers, one distinction that changes the answer. There are two kinds of refund, and they start in different places.

A refund request comes from the shopper. When a payment arrives for the wrong amount, or after the order has expired, the checkout page offers the shopper a refund form. They enter a wallet address and the network, and the request goes in. You do not have to do anything. The form appears on the checkout page as soon as the payment is approved, and shoppers who overpaid file it a median of about four and a half minutes after paying, six in ten within ten minutes.

A merchant refund comes from you. The customer asks, you agree, and you create the refund in your dashboard or through the API, entering the address and network they gave you. Unless you choose to skip it, the shopper then gets an email asking them to confirm that address before anything is sent.

Either way, a crypto refund is a new payment going out rather than the original one being reversed. How crypto refunds work covers that side in full. This post is only about the clock.

Once a refund exists, it moves in minutes to hours

Refunds created between 17 June and 31 August 2026, timed from the moment the refund was created to the moment the money was sent.

Refund	Refunds	Median	Inside an hour	Inside 24 hours
Refund request, from the shopper	3,618	23 minutes	87.9%	98.4%
Merchant refund, all	753	64 minutes	48.5%	87.6%
Merchant refund, confirmation skipped	204	21 minutes	81.9%	97.5%
Merchant refund, shopper confirms by email	503	4.3 hours	32.4%	82.5%

Look at the last two rows. They are the same kind of refund, and the process differs in one step: whether the shopper has to open an email and confirm the address first. Without that step the median is 21 minutes. With it, a little over four hours.

Very little takes much longer than a day. Of the 4,371 refunds in that table, eight took more than a week.

It was not this fast a year ago

If you timed a refund last autumn, you got a very different number.

	Before 17 June 2026	Since 17 June 2026
Refund request, median	10.3 hours	23 minutes
Refund request, inside an hour	7.7%	87.9%
Merchant refund, median	15.4 hours	64 minutes
Merchant refund, inside an hour	6.2%	48.5%

The drop is a step rather than a slope. It lands in the second half of June 2026, when we took the manual sign-off out of the standard refund flow, and both kinds of refund have held the new speed since.

That is also why a twelve-month average would mislead you here. Across the whole year, the median merchant refund took 13 hours, a figure that describes neither the old process nor the new one. If your support team has been quoting “a day or so” from experience, that experience is out of date.

The days come before the refund exists

So the transfer is now the short part. The long part is everything between a customer paying and a merchant refund being created.

Across the year, the median gap between the payment and the merchant creating the refund was 3.7 days. Fewer than one in five (18.2%) were created within a day of the payment, and more than a third (35.5%) came more than a week after it. That gap did not move when the transfer got faster.

A lot of different things live inside that window. A customer who takes a week to decide they want their money back. A return that has to arrive first. A ticket waiting in a queue, an approval, a weekend. We cannot see when your customer first got in touch, so read 3.7 days as the outer edge of the wait, and not as 3.7 days of somebody sitting on a request.

What it does show is where the time goes. Once you create the refund, what is left is measured in minutes to hours. Whatever happens before that is the part your customer will remember.

When a refund does not go through

A completed refund is not the only outcome, and the other two are worth knowing before you promise anything.

13.8% of merchant refunds were rejected. The most common reason shows up in the data itself. In 63% of rejections the shopper never confirmed the address, and the seven-day confirmation window ran out. A refund with an unconfirmed address does not get sent, which our refund status reference lists as one of the two reasons a refund is rejected.

Some refund requests are canceled rather than sent. The clearest case, about one request in thirteen (7.6%), is an order that was accepted as paid after the shopper asked for the money back. The payment went through instead, which cancels the refund. For other cancellations the status gives us the outcome and not the reason, and we are not going to guess.

And some small amounts never become a refund at all. A refund request is only issued if the refundable amount is above 2 EUR, which leaves 91% of overpayments below the line, as we found when we looked at what goes wrong with crypto payments.

What to tell your customer

• For a refund request, “usually within the hour.” Since June, 87.9% have been sent inside an hour and 98.4% inside a day.
• For a refund you are issuing, quote your own decision time first. Then add “and usually within a day after that”, because 87.6% of merchant refunds are sent within 24 hours of being created.
• Tell them to watch for the confirmation email. It is the biggest wait left in a merchant refund, and an unconfirmed address is the most common reason one gets rejected.
• Skip confirmation only when you are sure of the address. Skipping it means you confirm the refund address is correct, and a crypto refund sent to the wrong address cannot be pulled back.
• Do not promise small overpayments back. Below the 2 EUR floor a refund request is not issued, and telling a customer one is coming is worse than telling them it is not.

Method, and what this does and does not measure

Every figure comes from CoinGate’s own refund data, covering 28,934 refunds created between 1 September 2025 and 31 August 2026, 23,266 refund requests and 5,668 merchant refunds, with statuses as they stood on 29 September 2026.

The transfer clock runs from the refund being created to the refund transaction being sent, on the 17,929 completed refunds that carry an on-chain send time, 13,840 refund requests and 4,089 merchant refunds. It stops when the money leaves, not when the shopper’s wallet shows it confirmed. Refunds on Binance Pay orders go back through Binance Pay and carry no send time in our data, so they are left out of the timing. “Before” means refunds created up to 16 June 2026, and “since” means from 17 June onwards.

The decision clock runs from the order being paid to the merchant refund being created, on the same 4,089 completed merchant refunds. It contains everything in between, including the customer taking days to ask, which is why we describe it as the outer edge of the wait.

The payment side of the clock has its own numbers, in how long a crypto payment takes.

So once a refund exists, it is now a matter of minutes to hours. The days a customer waits mostly sit before that, in a decision and sometimes an email, and those happen to be the two parts you can shorten.

Thinking it’s time your refunds kept pace with your payments? Start with us.