How to handle duplicate ticket purchases without issuing the wrong refund

A buyer emails you two receipts and says, "I've paid twice. Can you refund one?" It sounds straightforward. Then you open the orders and realise one includes a workshop, the other has better seats, and both sets of tickets have already been forwarded to friends.

You want to fix the buyer's problem quickly. But refunding whichever transaction appears last can cancel the booking they actually need, leave the wrong tickets active or return money that is already being handled through a bank dispute.

Start by matching the payment records to the orders and the tickets. Confirm what the buyer intended to purchase, identify exactly which admission should remain valid, and use the supported refund process for the unwanted or erroneous payment. Afterwards, check the money and admission records separately. A refund confirmation doesn't tell you everything you need to know about who can still enter.

This guide walks through that investigation, the questions to ask the buyer, and the checks that make the final correction reliable. It also includes example replies and a worked booking so your support, finance and door teams can agree on the same outcome.

What looks like a duplicate ticket purchase?

The first thing you want to establish is what has actually happened. "I paid twice" describes the buyer's concern. It doesn't yet identify the correction.

A bank statement may show an authorisation alongside a completed payment. An authorisation reserves funds while the payment is being processed. It isn't the same as a second completed charge. Adyen's payment lifecycle documentation distinguishes authorisation, capture and settlement, which explains why the status behind an entry matters more than the number of lines the buyer can see.

There might instead be two successful payments against one intended purchase. That needs investigation by the platform or payment provider, particularly if your order screen only shows one of them. Don't create another order just to make the report look balanced. You could turn a money problem into an extra admission entitlement.

Another possibility is two completed orders. Someone thought checkout had failed and tried again, perhaps with a different email or card. Both attempts succeeded. There are now two purchases to compare, and you need to know whether the buyer wants both, one, or only particular tickets within them.

Sometimes the second purchase is intentional. A buyer books for themselves, then returns to buy for a colleague. A parent makes separate bookings for two children. A company uses the same accounts email for several employees. Matching names, prices and purchase times can flag a case for review, but they don't prove that either purchase should be cancelled.

Finally, the buyer may have received the same confirmation twice. If both messages identify the same order, they may simply be looking at repeated delivery. Check the underlying record before interpreting every email as a separate transaction. The same applies to a downloaded ticket and a wallet copy of that ticket.

Keep those possibilities open until you can connect the evidence. Staff should be able to say which payments succeeded, which orders exist and which tickets those orders created. If any connection is missing, record that uncertainty and escalate it. Don't fill it with an assumption because the buyer is understandably in a hurry.

Build one case around the exact records

Give the request one owner. That person doesn't need permission to perform every action, but they should coordinate the investigation and know who can approve a refund. Otherwise the buyer can receive an email from support, a separate payment from finance and a conflicting ticket instruction from the venue.

Begin with the event name and date, purchase email, order references and the buyer's description of the problem. Ask whether they intended to buy the same admissions twice or whether the orders were meant for different people. A useful first reply acknowledges the issue while making clear that you're checking which booking should stay active.

For example, "Thanks for flagging this. We'll check the two purchases before changing either booking. Please send the order references and tell us which date and tickets you want to keep. You don't need to send your card number or security code."

Use the contact details already associated with the order, or your provider's approved verification process, when authorising a change. An order number copied into an email isn't by itself a complete identity check. Someone may have forwarded a receipt to a guest, colleague or friend who isn't authorised to cancel the purchase.

You can usually start with references already in the systems. If you genuinely need a statement image to locate an unmatched transaction, ask the buyer to hide unrelated transactions, balances and account details. Explain which part you need and use an approved secure route. Don't request a full statement because it is easier for your team than explaining the question.

Record the payment reference, amount, currency and current status for each relevant transaction. Then record the order reference, event occurrence, ticket types, quantities and ticket identifiers. Include add-ons, reserved seats and any changes that have happened since purchase. These details matter when two totals happen to match but the actual products differ.

Look for previous support requests and money movements before preparing anything new. Has another colleague already approved the refund? Did the buyer use self-service? Is a payment pending, refunded, partially refunded or disputed? A case note that says "refund agreed" doesn't establish whether money was actually submitted for return.

Keep the case record small enough to read. The useful information is the original position, the buyer's confirmed request, the proposed correction, who approved it and the resulting references. Our guide to ticket management explains the wider relationship between order records, payments and admissions. Here, you need that relationship for the particular booking in front of you.

Confirm which booking the buyer wants to keep

Don't default to keeping the first order. That may be your normal starting point, but the buyer might have corrected an email address, chosen the right event date or selected accessible seating in the second purchase. Cancelling the newer order could undo the correction that made the booking usable.

Compare what each order provides. Event names can repeat across a series, so include the date and session. For reserved seating, include section and seat numbers. For general admission, check ticket category, quantity and age conditions. Then check workshops, meals, equipment hire or other extras that may exist in only one order.

Suppose order A contains two standard admissions and order B contains two admissions plus a workshop place. The buyer may want the workshop but only two admissions overall. That doesn't automatically make a full refund of A the right answer. You still need to establish whether B provides the same event access, whether the workshop can remain attached and which total should be returned.

Ask a concrete question. "Would you like to keep order B, which includes two Saturday admissions and one workshop place, and cancel the two admissions in order A?" is easier to answer than "Please confirm the duplicate." It also creates a record of the actual decision rather than a vague agreement that staff interpret differently.

If the buyer only wants to cancel part of a group booking, identify the individual tickets. Ask whether any have been transferred or shared and whether anyone has already entered. Don't remove every ticket associated with an email address. One person may be coordinating several legitimate purchases for a company or household.

A disagreement between buyer and guest needs careful handling. The purchaser may ask to cancel something a guest is already planning to use. Follow your authorised change process and applicable rights, then communicate the resulting ticket status through the correct channels. Avoid disclosing another person's details just to speed up the conversation.

When an order includes accessibility arrangements, preserve what the buyer needs in the retained booking. Don't make them explain sensitive circumstances again simply because the payment correction is happening in another team. Confirm the operational arrangement with authorised staff while limiting the information shared.

The aim is a sentence everyone can act on. "Keep order A and its two admissions; refund and cancel order B and its two admissions" may be enough for a simple case. A mixed booking needs a more precise sentence that names the individual tickets, extras and retained arrangements.

Before you submit the agreed change, read the decision back to the buyer using the actual references. A useful confirmation asks them to check the event, date, retained tickets and proposed cancellation together. If they reply only to the amount, clarify the admission decision before acting. A correct dollar figure can still describe the wrong booking.

Suppose the buyer replies, "Yes, refund the two tickets," after you asked about a booking containing three. That answer needs another question. Don't choose the first two admissions in the list or assume that a guest ticket has no value because it was discounted. Confirm which people or ticket identifiers are affected using the information you are authorised to disclose.

Keep any private evidence restricted to the people investigating the request. The UK's ICO explains in its data minimisation guidance that personal information should be relevant and limited to the purpose. That guidance concerns UK data protection and is currently under review following legislative changes. For this process, a sensible practical question is whether each person needs the document itself or only the confirmed result.

Decide whether money, tickets or both need correcting

Once the records and intention are clear, decide the action for that particular case. A repeated email needs a delivery explanation. An uncaptured authorisation needs the provider's supported cancellation or release process where available. A completed erroneous payment needs the relevant correction. Two valid purchases followed by a cancellation request need a policy decision as well as an operational one.

Keep accidental second bookings distinct from a processing error. Your voluntary cancellation terms may matter when a buyer completed two genuine orders. Applicable consumer rights can also matter, so avoid telling staff that "all sales final" settles every request. Our event refund policy guide develops those policy choices. This investigation establishes the facts needed to apply them.

You can choose to be more helpful than your minimum voluntary terms where permitted. For example, an organiser might allow a clearly accidental second booking to be cancelled promptly before either set of tickets has been used. Write that discretion into staff guidance so the outcome doesn't depend on who answers the email or how forcefully the buyer complains.

Don't quietly classify an actual overcharge as a goodwill refund. That confuses the reason for returning money and makes later reporting less useful. Record whether the cause was a provider error, an accidental second order, an intentional purchase later cancelled or something still unresolved. The classification should follow the evidence.

Check what the platform's refund action does to tickets. Does it cancel the selected admissions, the whole order, or no admission at all? Can you return part of a payment while retaining an add-on? If the documentation doesn't answer your case, ask the provider before clicking through. A button labelled "refund" doesn't explain every resulting change.

Loopyah's ticketing tools include a configurable period when buyers can request refunds themselves. Use that supported route for eligible requests rather than creating a parallel manual process. Still check the current order before acting on a support message, because the buyer may already have completed a self-service refund while waiting for your reply.

For a reported payment error, don't direct the buyer to buy again to demonstrate the problem. Investigate the existing attempts and ask the provider to trace missing records. If the event is approaching, separate the urgent question of their verified admission from the unresolved payment investigation, with an authorised person responsible for each.

Write down the desired final state before submitting the correction. Name the payment to refund, the amount and currency, the tickets to cancel, the tickets to retain and whether any stock should return to sale. That small pause is often where someone notices that the proposed payment and booking don't actually match.

Work through a duplicate booking without cancelling the right tickets

Here is a fictional example in USD. It is a training exercise, not a customer case or a recommended refund policy. We will assume the organiser has approved a full refund of an accidental second booking, including its stated charges, and the selected platform supports the required ticket cancellation.

A buyer intended to purchase two admissions. Each admission is $60, and each two-ticket order has a $4 order charge. Order A therefore totals $124. After an unclear confirmation screen, the buyer repeats the purchase and completes order B for another $124. Both payments succeed, so the buyer has paid $248 and four admissions have been issued.

The buyer confirms that order A should stay active. Your investigation finds no transfers, no previous refunds, no dispute and no entry scans on either order. You record the two ticket identifiers in A as retained, the two in B as cancelled, and B's payment reference as the one to refund.

After the supported action completes, the buyer has paid a net $124 and holds two valid admissions. Order B shows the $124 refund and its two admissions no longer permit entry. Order A and its tickets remain unchanged. Check those statements in the actual records rather than inferring them from a success message.

Now change one fact. Imagine both completed payments were collected against order A, but only its two admissions ever existed. The intended final position is still $124 retained and two valid admissions. However, cancelling order A would destroy the booking you are trying to preserve. The extra payment needs tracing and correction without cancelling the legitimate tickets.

Change another fact. If the second bank entry is only an authorisation and no second successful order exists, a completed-payment refund is not the starting action. Find the provider's status and supported next step. Explain that distinction without telling the buyer that their reduced available balance is imaginary or unimportant.

Finally, suppose B includes different seats that the buyer wants to keep. The retained order changes, even though both totals remain $124. The arithmetic cannot tell you which seats the buyer needs. Confirm the decision, then change the exact references in the case before anyone acts.

The useful habit is to rehearse several versions of the same case. If your team only practices two identical orders before either ticket is used, they will have little guidance when the real request includes an add-on, a transfer or an entry scan.

Keep a pending refund from becoming a second refund

Submitting a refund and completing a refund are different events. Record the provider's refund reference and current status, then follow the supported process until it reaches a final outcome. Don't mark the case resolved merely because someone clicked the button.

Stripe's refund documentation distinguishes pending and failed refunds and says refunds return through the original payment method. It also explains that some refunds appear as reversals, where the original charge disappears rather than a separate credit appearing. Those are Stripe-specific details. Check the actual payment route used for your event before explaining what the buyer should expect.

Your acknowledgement should state the amount submitted, the affected order and what remains valid. Give a bank timeframe only when you have checked the provider's current guidance for that payment method. You can promise when your team will next review the case because you control that work. You cannot guarantee when every bank will display a credit.

If the buyer asks again while the refund is pending, reopen the existing case. Look up the recorded reference and tell them what you can verify now. Don't create a new refund because a fresh email looks like a fresh request. Link conversations from the same booking so colleagues can see that an action is already underway.

A failed refund needs diagnosis. Check the provider's reason and approved recovery process before arranging an alternative payment. Otherwise the first refund might later complete after you have also paid by bank transfer. Keep any exceptional alternative under named approval and preserve the records that establish why it was necessary.

Check funding before promising immediate submission. The event's money may already have been paid out, while the platform's refund route requires funds elsewhere. Our guide to a ticket refund reserve explains how to plan for that cash need. A payout doesn't remove the need to correct a confirmed error.

Don't deduct a processing cost automatically because your provider retains it. What you owe the buyer and what the provider charges your business are separate questions. Determine the correct buyer remedy first, including relevant terms and rights. Then record any unrecovered expense honestly in the event's accounts.

For the fictional $124 refund, suppose the provider retains a $3 processing expense and support spends 20 minutes at a fully loaded $30 hourly cost. The labour is $10, so the extra expense is $13. Those are invented inputs, not market rates. Neither expense changes the approved $124 buyer refund in this example.

Check for a bank dispute before returning money

A buyer may contact you and their bank about the same transaction. That doesn't make the request suspicious. It does mean you need to check whether the bank's process has already changed how the payment can be handled.

Look for a dispute or inquiry on the exact payment reference. Ask the finance owner or provider to confirm when your order screen doesn't expose that information. Don't assume that an open dispute on order B affects order A, or that every transaction from the same card is being challenged.

Stripe's dispute lifecycle guidance says an open dispute prevents a refund outside that process. Follow the rules of your own provider and payment method, including the response deadline shown for the case. Sending the buyer a separate payment can create another loss without resolving the bank's claim.

If a refund was already submitted before the dispute arrived, gather its reference, amount, date and status. Send the relevant evidence through the required dispute process. Don't assume the bank will automatically connect your customer-service emails, the refund and the challenged charge.

The buyer's statement that they have withdrawn a dispute is useful information, but it isn't a substitute for the provider's status. Ask the responsible person to confirm what action is still required. A friendly exchange with the buyer can end while a formal deadline continues to run.

Keep the tone calm. "We've found the bank case attached to this payment and are checking the correct route so you don't receive conflicting instructions" explains the next step. Asking someone to abandon rights or close a claim as a condition of receiving any help is a very different conversation. Don't improvise that position in a support reply.

For a detailed evidence process, use our guide to responding to a ticket purchase chargeback. The duplicate-purchase case should contribute accurate references and communication to that process, while the named dispute owner handles the formal response.

Maintain separate progress notes for money and admission. A disputed payment doesn't automatically tell door staff whether an admission should be accepted. That decision needs your agreed event terms, applicable rights and an authorised instruction about the exact ticket. Avoid leaving a receptionist to interpret an unresolved financial case at the entrance.

Cancelled tickets must stop admitting people before stock returns

A returned payment can affect availability, seat assignments and the entry list. Plan those consequences before you make an admission available to someone else. If the old ticket remains usable, reselling its place creates competing claims on the same capacity.

Start with the exact admissions being removed. A whole-order refund may be appropriate for an entirely unwanted booking. A partial correction needs ticket-level clarity. A payment-only correction against one legitimate booking should leave those legitimate admissions intact. Those outcomes cannot all be produced by indiscriminately cancelling an order.

For reserved seating, check whether the original seat is released, held for investigation or assigned to a replacement ticket. For a workshop, check its session limit. For an event pass, check every included occurrence. A cancelled general admission doesn't necessarily free the separate meal or activity that someone has already committed to provide.

Don't release stock merely because a refund has been requested. Use your system's actual supported cancellation and stock rules, then verify the result. If automatic handling already keeps these records aligned, test that behaviour rather than asking staff to maintain a second manual inventory that will soon disagree with the platform.

Here is another fictional example. An event has an agreed allocation of 200 attendee places, with staff and other occupancy handled separately in the venue plan. Before correcting the duplicate, 190 admissions are valid and 10 places remain available. Two of the 190 belong to the unwanted order.

Once those two admissions are definitively cancelled and their capacity is released, 188 admissions remain valid and 12 places are available. The correction has freed two places, not four. The retained order's two admissions still count. If cancellation hasn't taken effect, keep the existing stock position while an authorised person resolves it.

At the door, staff need a current record. An old exported list may still include the unwanted booking, and a screenshot can outlive the ticket it depicts. Tell the entrance lead how to find the retained booking and who can resolve a disputed scan. Don't broadcast bank details or the entire support conversation to the check-in team.

Loopyah documents phone-based QR scanning and a check-in role for door staff on its ticketing page. Keep that role focused on entry. Have authorised support staff investigate the order and finance question, then communicate the confirmed admission outcome through the process you tested. Don't assume a refund feature proves every offline or multi-device behaviour you might need.

When someone has already used or shared the tickets

An entry scan changes the facts of the case. You can still investigate a reported payment error, but you need to know which admissions were used and by whom before treating a whole booking as an unused duplicate.

Check each relevant ticket's history. An order containing two admissions might have one entered and one unused. A shared confirmation could have reached several people. If both bookings have been used, record that clearly and ask what the buyer believes was duplicated. Don't silently edit the scan history to make the preferred refund story fit.

An erroneous extra payment for one legitimate used admission can still need correcting. The fact that the event was delivered doesn't automatically justify retaining a duplicate collection. Conversely, two deliberately purchased and used bookings aren't made duplicates solely because the same person paid for them.

If someone is standing at the entrance, move the investigation to the designated help point where possible. Establish the booking they are entitled to use without making the whole queue wait for a payment trace. Follow the event's entry and capacity plan, and have one authorised person record any exception before another entrance can make a conflicting decision.

When tickets have been transferred, use the provider's supported records to establish their current status. The buyer may no longer hold the credential they originally received. Cancelling or replacing it without checking can affect somebody who has no idea a refund conversation is underway.

If a guest has already received a cancelled ticket, tell the authorised contact which ticket remains valid and what they need to forward instead. Avoid sending a message that simply says "your tickets are cancelled" when the buyer still owns another valid booking. Be specific enough that nobody arrives with the wrong receipt open.

For an event series, check the remaining dates as well. A booking may have delivered one session while retaining future entitlements. Don't erase the entire pass history to correct one unwanted session or an extra collection. Where the platform can't make the needed partial change, escalate before promising a particular outcome.

There will be cases your first-line team can't settle immediately. That is a reason to give the buyer an owner and next update time, with a clear statement about admission. It isn't a reason to invent a generic answer such as "the latest ticket always wins." The event needs a decision supported by its actual records.

Write the reply around what the buyer can now do

The buyer doesn't need your full investigation log. They need to know what happened, what money is coming back, which tickets to use and when they will hear from you again if the work is unfinished. Write the message after checking those facts.

For the fictional two-order case, a reply after submission could read, "We've submitted a refund of $124 from order B and cancelled its two admissions. Order A remains valid for two admissions to Saturday's event. Please use the tickets from order A and disregard order B. Your refund reference is R104. The payment provider currently shows the refund as pending; we'll check it again tomorrow and update you if it hasn't progressed."

Change that wording to match the real status. If you have only approved the refund, say approved. If you submitted it, say submitted. If the provider confirms completion, report that without pretending to know what is visible in the buyer's banking app. Accurate verbs reduce the chance that a reassuring sentence becomes a broken promise.

For an unresolved authorisation, explain what you have found. "We can confirm one completed order for two admissions. We're tracing the second bank entry with the payment provider before changing the booking. Your two tickets remain valid, and we'll update you by tomorrow afternoon." Only include that validity statement once you have verified it.

If the buyer intentionally purchased both bookings, confirm what each contains and ask whether they now want to make a cancellation request. Apply the relevant terms fairly, including any mandatory rights. Don't reply with a lecture about how they clicked twice or suggest that the existence of two receipts proves they deserve no help.

If information is missing, name the missing fact. "We found two Saturday orders but need to confirm which seats you want to retain" is actionable. "Please provide more information" makes the buyer repeat their whole story and often produces another statement screenshot that doesn't answer your actual question.

Keep refund updates separate from marketing. A resolved support problem doesn't need a discount pitch in its closing paragraph. First leave the buyer confident about the purchase they still hold. If they have no remaining booking, say that clearly and don't send arrival instructions that imply otherwise.

Prevent repeat purchases without blocking legitimate buyers

When the case is resolved, look at why the buyer tried again. Did the page stall after payment? Did the confirmation go to an unexpected email address? Did a message say "try again" before the provider had established whether the first payment succeeded? Those causes need different fixes.

Our US attendee study, fielded through Pollfish on November 11, 2025, asked 500 respondents why they had abandoned a ticket checkout in the previous year. The chart shows selected raw respondent shares for three relevant answers. Respondents could choose up to three options, and the study did not measure duplicate orders or prove that these issues caused repeat payments.

Source: Loopyah Event Attendee Insights Report, Q13, Pollfish survey 395372896, November 11, 2025. These are three selected responses, not the full ranking. The sample included respondents who reported no recent live-event attendance. The figures give context for checking the buying experience; they don't estimate your event's duplicate-purchase rate.

Test what happens after the buyer submits payment. Can they tell that processing is underway? If confirmation takes time, do the instructions explain how to check the order? Is there a useful help route without starting another purchase? Ask your platform provider to demonstrate those situations using its supported test process.

W3C's guidance on preventing errors in financial transactions describes reversible, checked or confirmed submissions. Use it when reviewing whether buyers can catch mistakes before committing. A clear review step and understandable error messages help people make a deliberate choice, including people using assistive technology.

Avoid blocking every repeated email address or equal transaction amount. Legitimate buyers return for additional tickets, purchase across dates and use shared company contacts. A review flag can help your team investigate, but the action should follow the evidence. Ask the provider how its safeguards distinguish a retry of one payment from a genuinely new purchase.

After a pattern emerges, send the provider a concise incident record with the affected order and payment references, times and observed steps. Remove unrelated personal information. Ask for the confirmed cause and correction, then retest the original failure. A generic instruction to clear browser history doesn't close an incident involving completed extra charges.

Measure the problem using confirmed cases

Review confirmed duplicate cases after a busy launch, with failed attempts and pending authorisations counted separately. If you put every "paid twice" email into one total, you won't know whether the problem is extra collections, repeat orders or unclear bank entries. Those are different jobs for the provider and your team.

Use a consistent denominator when comparing launches. Ten confirmed accidental second orders among 1,000 completed orders is 1% of orders under that definition. It is not 1% of buyers unless you have counted unique buyers separately. This is a fictional calculation to show the distinction, not an expected rate for ticket sales.

Record the time needed to resolve each category and whether a second correction was required. An investigation that refunded the wrong booking should remain visible as a process failure even if a colleague repaired it before the event. Otherwise a report can show fast response times while hiding the extra work and confusion those responses caused.

Look for a repeated trigger you can test. Several buyers retrying after the same mobile confirmation screen need a targeted demonstration and fix. A few intentional purchases sharing one company email need better review rules. Choose the next change from the confirmed pattern, then compare the same definitions after the next launch.

Rehearse the correction before the next busy on-sale

Make the duplicate-purchase test part of your event setup. Use the provider's approved test method and involve the people who will answer buyers, approve money movements and supervise admission. Ask them to show the resulting records, not just describe which button they would press.

Include two successful orders where the buyer wants to keep the second, one order with a reported extra collection, and one completed payment with another pending attempt. Add a partially refunded order and a case already handled through self-service. These exercises reveal whether staff can find existing actions before creating new ones.

Then include an order with an add-on, a used ticket and a transferred ticket. Confirm what happens to admission, stock and the buyer's message in each case. If your platform cannot reproduce a situation safely in testing, ask the provider to demonstrate it or explain the documented process before you advertise a promise about it.

Review the financial result as well. A refund amount, unrecovered provider charge, staff expense and later resale answer different questions. Don't treat returned buyer money as new profit when a released place sells again. You are correcting an earlier transaction and recording a new sale, with the costs of each still accounted for.

Give unresolved cases a handover that another colleague can use. Record the known facts, action already taken, exact references, next decision and update deadline. Include the confirmed admission position so the next shift doesn't cancel tickets just because the finance investigation remains open.

Your final check is practical. Open the retained order, identify the tickets the buyer should use, and trace the unwanted payment to its current outcome. Then compare that with the reply you're about to send. When all three agree, close the case with the buyer and carry any recurring checkout problem into the next on-sale test.