Crypto ticket refunds, cancellations and postponements

How crypto ticket refunds work when an attendee paid in stablecoins or crypto, and what to decide before your next on-sale.

Card payments come with a refund path the merchant did not design. The attendee disputes the charge, the issuer opens a case, and the money moves whether or not the organiser agreed. Crypto pay-ins do not work that way. There is no chargeback, no issuer, and no third party who can reverse the payment on the attendee's behalf.

That property is usually described as a benefit, and for fraud it is. It also means crypto ticket refunds are an operation you run rather than a rail you inherit. Every organiser eventually cancels a show, moves a date, or has to give somebody their money back, and the time to decide how that works is before the on-sale rather than the morning the announcement goes out.

"Refund" covers two different jobs, and conflating them is what makes refund policies unworkable. Here's the picking heuristic in one table.

A postponement is where the distinction earns its keep. Attendees who can make the new date keep the ticket they already hold and no payment moves at all, so the refund run is only as large as the group who cannot. Say that plainly in the announcement and the payout list shrinks to the people who genuinely need one.

A refund is not a reversal of the original payment. It is a new, outbound payment you send.

In EukaPay, that outbound payment is a crypto payout. You create it from the merchant dashboard or through the Payout API, which creates payouts programmatically at one payout per request. The payout balance is funded by transferring from your account's main balance, so a refund run needs the balance topped up before it starts rather than during it.

Each payout carries its own reference that can be looked up. Pair that reference with your original order number and the refund is traceable end to end, which is what your finance team will ask for when the event's accounts are closed out.

Payouts are sent in USDC, USDT, ETH and BTC, across the Ethereum, Tron and Bitcoin networks. The asset and network are set per payout, so attendees on different networks can each be refunded appropriately in the same run.

Note that the pay-in side accepts a wider set than the payout side. An attendee who bought a ticket with LTC or SOL cannot be refunded in that same asset. Decide in advance which asset you will refund in, say so in your policy, and keep the choice consistent, so an attendee is never surprised by what arrives.

EukaPay enforces per-asset minimum payout amounts. That rarely matters for a full ticket refund and often matters for a small partial one, such as returning a booking fee. Where a partial refund would fall below the minimum for your chosen asset, consolidating it with the attendee's other tickets into a single refund is the cleaner resolution than a payment that cannot be sent.

A refund needs a destination address, and the attendee is the only reliable source of it. Build the collection of that address into your refund request flow rather than chasing it over email once the run is already assembled.

Two practical rules. Ask for the address and the network together, because an address alone does not tell you which network the attendee expects to receive on, and hold those fields on your own order record so your refund file is complete before you start. Second, confirm the address back to the attendee before you send, since an outbound crypto payment cannot be recalled once it has gone.

A ticket sold at a locked exchange rate has a known fiat value. That is the number your accounts carry, and it is the cleanest basis for a refund: the attendee paid the equivalent of a $90 ticket, so the attendee is refunded the equivalent of $90, in whatever asset you refund in, at the rate on the day you send it.

The alternative is refunding the original quantity of crypto. Avoid it. An attendee who paid in an asset that has since risen would be refunded more value than the ticket was worth, and one whose asset fell would be refunded less and would rightly complain. Refunding the fiat value treats every attendee the same regardless of what the market did between purchase and cancellation. State which basis you use in the policy so nobody has to ask.

A cancellation is not a series of refunds, it is one operation with a deadline and an audience already reading your social channels.

Upload the recipient list as a CSV file in the merchant dashboard and release the run in one operation rather than initiating hundreds of individual transfers. The file is built from your own order records, which is why collecting addresses at the point of the refund request matters so much: the quality of the run is decided by the quality of the list.

Payouts are not tied to banking hours or the banking calendar, so a Sunday-night cancellation does not have to wait for a Monday to start moving. Announce the refund window and the asset in the same message as the cancellation, and the support volume drops substantially.

Everything above is operational. What makes it work is that attendees agreed to it before they bought.

Four things belong in the policy, in plain language, on the ticket page: which asset refunds are paid in, whether the basis is the fiat value or the original crypto amount, how long a refund takes to process, and what happens on a postponement rather than a cancellation. Publish it before tickets go on sale. A refund policy written after a cancellation reads as an excuse; the same policy written before it reads as competence.

Automate the parts that are mechanical, which is the list build, the payout run and the reference matching. Keep the judgment calls manual, which is the goodwill case, the partial that falls below a minimum, and the attendee who has lost access to the wallet they paid from.

Ticket sales and refunds run on the same infrastructure: instant crypto-to-fiat conversion at a locked exchange rate to remove all crypto volatility, protection against chargebacks, and settlement in USD, EUR, GBP, CAD to your bank account. Pay-ins and payouts run through one merchant account, which is what makes a refund traceable back to the ticket that generated it.

No chargeback means no involuntary reversals, and it also means the refund process is yours to design. Designed before the on-sale, it is a selling point on the ticket page. Designed during a cancellation, it is a support queue. Our

crypto payment gateway for event ticketing platforms

guide covers the collection side of the same setup.

If you sell tickets and want the refund path settled before your next on-sale,

book a call with our team

. We'll go through your refund policy, the payout setup behind it, and how cancellations would run against your current ticketing system. Every merchant goes through onboarding and a business review, and a staging environment is available for your developer (or coding agent) to build against. The

API documentation

covers crypto payouts and webhooks.

Are crypto payments refundable?

Yes. A refund is sent as a new outbound payment rather than a reversal of the original one, so you keep control of when it goes and on what basis.

Can an attendee file a chargeback on a crypto ticket purchase?

No. Crypto pay-ins are not reversible and there is no issuer to open a dispute with, which is why the refund policy you publish before the on-sale does the work a chargeback process would otherwise do.

Which assets can we refund in?

Payouts are sent in USDC, USDT, ETH and BTC across the Ethereum, Tron and Bitcoin networks, with the asset and network set per payout.

Can we refund in the same asset the attendee paid with?

Only if it is one of the four payout assets. The pay-in side accepts a wider range, so name your refund asset in your policy rather than promising to match the original payment.

How do we refund hundreds of attendees at once?

Upload the recipient list as a CSV file in the merchant dashboard and release the run in one operation. Payouts are not tied to banking hours or the banking calendar.

Should we refund the fiat value or the original crypto amount?

The fiat value is the cleaner basis, because it treats every attendee the same regardless of market movement since purchase. Whichever you choose, state it in the policy.

What if a partial refund is too small to send?

EukaPay enforces per-asset minimum payout amounts. Where a partial refund falls below one, consolidating it with the attendee's other tickets into a single refund is the better resolution.

What happens to tickets when an event is postponed?

If the ticket carries over to the new date, no payment moves and there is nothing to process. Full refunds are then only needed for the attendees who cannot make the new date.