How to respond when a private ticket discount code leaks online

You gave a partner a private ticket discount. Now the code is on a deals page, people you never intended to reach are using it, and your sales report suddenly looks much healthier than your budget feels.

The first thing you want to do is stop further unintended use while protecting the offer you actually promised. Preserve the original terms and affected orders, check what your ticketing system can disable, and give eligible buyers a working way to claim their benefit. Decide what happens to completed purchases after you've established the facts. A code appearing online doesn't make everyone who used it a fraudster.

That distinction matters because a rushed response can cost more than the discount. Cancel good orders, surprise people at the door or accuse your partner without evidence, and you'll create another problem while you're still working through the first. Here's how to contain a leak, understand what it has cost and make a decision you can explain to customers.

First, check what has actually escaped

Find the public post and save a copy showing the code, surrounding wording, location and time. Record when your team discovered it. The first public post you find may not be the first place the code appeared, so keep discovery time separate from the earliest confirmed exposure.

Then look at the actual offer. Which event and ticket types does the code affect? Is it a fixed reduction, a percentage or a free ticket? Is there a total allowance? Does it work across several dates? A small partner offer on a quiet session is a different problem from a reusable free admission code that reaches your strongest date.

Compare what you approved with what checkout currently permits. Perhaps the code is doing exactly what you configured, but your team assumed a private email would keep it private. Perhaps a setting changed, or the offer reaches ticket types nobody intended to include. Those situations need different fixes, even if buyers are entering the same characters.

Check the original invitation too. "A thank you for our members" may describe the reason for an offer without clearly establishing who is eligible. "Current members only, one discounted ticket per member" is more specific. You need the words customers received, including partner messages, rather than what someone remembers agreeing on a call.

Keep an open mind about how the leak happened. A partner may have posted publicly, a recipient may have forwarded an email, or your own team may have included the code in public copy. Ask where it was shared before deciding who caused it. The useful answer is the distribution route you need to close.

Contain new use without abandoning eligible buyers

Assign one person to coordinate the response and another to verify what changed. Your ticketing lead can handle the code while the partner contact prepares a correction. If everyone starts changing ticket settings independently, you'll struggle to explain which orders arrived under which conditions.

Where the offer's existing restrictions and your applicable obligations allow it, deactivate the exposed code or restrict the affected purchase route. Preserve its configuration and redemption history first if you can do that promptly. Don't delay a necessary stop while someone builds a perfect spreadsheet. Record the change and capture the remaining evidence immediately afterwards.

On Loopyah, the discount code help guide confirms that you can activate or deactivate codes for a selected ticket type. It also describes fixed and percentage reductions, total quotas and per-user quotas. Deactivation gives you a practical way to stop a code being available for new use while you investigate.

The ability to switch off a code doesn't decide whether you may withdraw a promised offer. An eligible member who received a valid invitation still needs fair treatment. If you temporarily close the exposed route, arrange a replacement that preserves the benefit they're entitled to, with support for anyone already trying to buy. Check the original conditions before shortening a deadline or reducing an allocation.

For UK promotions, CAP's general promotional marketing guidance stresses fair administration and warns that changing terms to address abuse can disadvantage people who participated fairly. The commercial task is to stop unintended distribution while continuing to deliver the offer you made. Where the proposed action changes that promise, get advice on the specific terms and market before proceeding.

Tell the team exactly what remains available. Ordinary ticket sales may continue safely while one code is disabled. Closing the whole event can make sense if the affected route cannot be separated or a wider checkout problem is causing harm, but establish that need first. Losing unrelated full-price purchases won't help you recover the discount.

Test the stop, including purchases already underway

Don't treat a saved setting as proof that the incident has stopped. Try the exposed code through the normal public purchase route using your platform's authorized testing process. Check the relevant ticket type and another date if the offer reaches more than one event.

You also need to understand buyers who entered checkout before the change. An existing basket may behave differently from a fresh visit. Ask the platform what happens to a previously applied discount, a pending payment and a payment retry. Follow the supported process rather than repeatedly creating live orders your team then has to untangle.

Loopyah's public code guide doesn't document every pending-basket or payment-retry behaviour. Verify those details with support and a controlled test before telling colleagues that no further discounted orders can arrive. Ask support to confirm any unresolved behaviour before sharing the replacement with your partner. A completed payment after deactivation might have started earlier. Record its payment time and purchase history rather than immediately calling it a bypass.

Watch completed orders after the change and reconcile them with the last known affected purchases. If the code still works in a fresh purchase, escalate with the event, ticket type, exact time and test result. Avoid sending customer payment details in a general team chat. Support needs enough information to reproduce the problem through an approved route.

Check other codes created from the same setup. A copied partner code may share the same overly broad eligibility or allowance. That doesn't justify disabling every promotion you run. Identify which configurations repeat the actual problem, preserve valid commitments and handle those offers deliberately.

Keep a short timeline while the incident is running. Record when the code was found, when settings changed, when you verified the result and when customers were contacted. Use a consistent time zone. This lets you distinguish a purchase that completed during an expected delay from one that needs another technical review.

If your team hands the incident to another shift, include the next action and the person responsible. "Monitor sales" is too vague. Say which code and ticket types to watch, which pending orders are expected, and where to escalate a fresh successful use. The handover should let someone continue without reconstructing your afternoon from chat messages.

Once new unintended use has stopped, write down how you verified it. Include any unresolved behaviour, such as pending orders that may still complete. That small qualification is useful. It tells the next person monitoring sales what to expect and when a new order genuinely needs investigation.

Build an order list that separates evidence from suspicion

Pull affected purchases from your ticketing records through the reporting or support options available to you. Start with the code itself and the confirmed exposure period, then widen the period if earlier activity suggests the code circulated before you found it. Keep an untouched copy for reference.

For each order, record the order identifier, purchase time, ticket types and quantities, discount applied, payment status and current ticket status. Add the invitation or membership evidence already available where it is relevant. Restrict access to the people making the decision. You don't need to circulate an attendee export to everyone who has an opinion.

Separate clearly eligible purchases, purchases needing clarification and purchases with evidence of an actual breach of the published conditions. Keep unresolved cases unresolved. A buyer using a personal email address may still be a member whose invitation went to a work address. Someone buying several tickets may be making an allowed group purchase.

A shared internet connection proves very little on its own. Family members, colleagues and people using a venue's Wi-Fi can have a common connection. Likewise, several purchases close together can reflect a partner sending an email. Use patterns to decide what to review, then look for evidence that bears on the rule you intend to enforce.

If you suspect automated code guessing, ask the platform to investigate the relevant technical records. OWASP describes token cracking as automated attempts to identify valid coupon, voucher or discount values. A published working code and repeated guesses are different routes to the same offer, so don't assume that replacing the public post will resolve both.

Give each reviewed order a reason and an owner. "Outside the invited membership, eligibility confirmed with buyer" is more useful than "suspicious". Another colleague should be able to understand the decision without repeating the investigation or making their own judgment at check-in.

Read the terms before deciding what happens to existing tickets

The question you need to answer is whether the purchase breached a condition that actually applied when it was made. An internal intention to reward a private audience doesn't automatically become a restriction the buyer could see. Nor does a broad sentence saying that you reserve every possible right settle every dispute.

CAP's guidance on promotional abuse warns UK promoters against disqualifying people who complied with the stated conditions or introducing restrictions retrospectively. It also stresses evidence when claiming someone breached a promotion's rules. Apply the relevant local requirements to your event, particularly before reversing completed purchases. The guidance is a reason to investigate carefully, rather than a universal answer to every ticket contract.

If the offer had no meaningful eligibility restriction, honouring completed purchases will often be the cleaner commercial response. You can correct future distribution and configuration without pretending buyers agreed to a rule you hadn't written. Whether you can change a running offer still depends on its terms and the obligations applying to it.

Where a clear restriction exists, consider whether you can confirm eligibility without creating an unreasonable burden. Ask for the minimum information needed through a secure support route. Give people a sensible chance to respond. Don't demand identity documents in a public comment thread because somebody found a members' code on a website.

Cancellation needs a defined process, authority and customer remedy. Review whether it is allowed, what refund is due, and how the ticket record will change. If you invite a buyer to purchase a replacement, explain the choice and price. Don't charge a saved payment method for the difference without proper authorization.

Our event refund policy guide is useful when reviewing how you communicate that process. Keep the leak decision consistent with your existing policy and applicable rights. An incident is a poor time to invent a different cancellation practice for every person who contacts support.

Work out the financial exposure without inventing lost sales

Start with what you can observe. Add up discounts applied to completed affected orders, then separate intended eligible purchases from the rest. Show refunds, failed payments and cancelled tickets separately so you don't count an unpaid reservation as money already given away.

That total is the face value of discounts granted. It isn't automatically the profit you lost. Some buyers might have paid the ordinary price; others might never have bought without the offer. A redemption report cannot tell you which alternative would have happened. Label that uncertainty instead of presenting a dramatic number as established damage.

For the immediate decision, look at what each completed sale leaves after the actual selling costs, taxes where relevant and the additional cost of serving that attendee. Check partner commissions and included benefits too. A deeply discounted ticket can still leave a positive amount towards fixed costs, while a free package with costly inclusions may create an additional bill.

Capacity changes the decision. If the affected tickets displaced buyers likely to pay the normal price for a nearly full session, the potential cost is greater than at a date with ample unsold space. You still need a credible expectation of those purchases. "We could have sold them at full price" is an assumption to assess, not a fact established by the leak.

Keep already paid costs separate from costs you can still avoid. Staff time spent investigating has happened regardless of which remedy you choose next. It belongs in the incident total, but adding it again to only one option would distort your decision. Likewise, a fixed venue bill doesn't disappear because you cancel several discounted bookings.

Ask finance to distinguish cash movement from the event's final result. A refund reduces cash now; a replacement purchase might restore some of it later. Until that replacement is completed, don't count it as recovered revenue. Report confirmed receipts and any forecast recovery separately so the event budget reflects what you actually know.

Compare the realistic options. Honouring purchases means accepting their receipts and delivery costs. Cancelling may mean refunds, non-refundable selling costs, support work and seats you then have to sell again. A replacement offer may add administrative cost while preserving a relationship. Include the timing, because tickets for tomorrow are harder to resell than tickets for next season.

If you were already running a controlled offer test, record the leak as contamination of that test. The ticket-sales email offer testing guide explains why assigned groups matter. Once an intended private offer spreads into another group, you can't confidently attribute the difference to the message you originally tested.

Decide on a consistent remedy, then brief support

I'd favour honouring genuine completed purchases when the restriction was unclear and the event can deliver them. The discount may be irritating, but a cancellation campaign can turn an avoidable configuration mistake into a prolonged argument with people who believed they had bought valid tickets. Check the actual circumstances before making that decision.

Where clear conditions were breached, choose a proportionate response with the people responsible for customer obligations and payment operations. You might need clarification before deciding, or cancellation with an appropriate refund where permitted. Treat materially similar orders alike. The loudest complaint shouldn't receive a different interpretation of the same conditions simply because it reached the founder.

Write a short internal decision record. State which purchases will be honoured, which need review, what evidence changes the decision, who may approve a cancellation and how support can escalate an uncertain case. Include the version of the conditions you're applying. This gives your team something firmer than an instruction to use their judgment.

Also decide what to say to full-price buyers who ask about fairness. They may reasonably be frustrated when an apparently public offer appears after they purchased. Explain the actual situation and your policy honestly. Don't invent a promise that nobody ever receives a lower price. If you offer goodwill, approve its cost and apply a consistent basis.

Protect genuine members who haven't bought yet. Their allocation may have been consumed by public use, and a replacement code with no available inventory doesn't restore the benefit. Establish what you can provide, including equivalent eligible inventory where appropriate, and communicate with the partner before making promises you cannot fulfil.

Support should know the final decision before customers receive it. A calm email followed by a contradictory reply is worse than a slightly later message that your team can carry through. Prepare answers to the actual questions buyers will ask about admission, refunds, replacement access and when they'll hear back.

Tell affected buyers what changes for them

Keep the message specific to the order. If a completed purchase remains valid, say so directly. You can explain that a discount intended for a limited audience was shared more widely and that the booking will be honoured. Confirm whether the buyer needs to do anything. Most people care about attending, rather than the details of your internal review.

For an eligibility check, explain the condition that applies, what information you need and how to send it securely. Give a response deadline and a contact route. Make clear whether the ticket remains valid during review and when you will confirm the outcome. Only state a ticket status that matches the actual record.

If a purchase must be cancelled under the applicable conditions, identify the affected order, explain the reason plainly and state the refund process. Tell the buyer how to ask for a review and whether another purchase option exists. Avoid cheerful marketing language in a message about a booking someone expected to keep.

Don't send an incident announcement to every attendee by default. Communicate with the groups affected by the decision. A broad message can expose the code to more people, confuse buyers whose tickets are valid and generate support work unrelated to the problem. If public clarification is needed, explain the offer's current position without repeating usable discount details.

Keep customer communications attached to the relevant order or support case. If a buyer opens a payment dispute, route it through your payment provider's process. Stripe's dispute response guidance stresses responding to the actual claim, preserving communication and meeting the response deadline. A general account of the leak won't answer a buyer's specific complaint about an order.

Before processing a refund, check whether that payment is already disputed and follow the provider's instructions. A refund workflow and a bank dispute can interact, and your support agent needs the current payment status before promising an outcome. Keep the customer informed through the same case so another colleague doesn't initiate a second remedy without knowing what has already happened.

Watch replies after the first messages go out. Repeated confusion can show that your explanation is incomplete or that the operational decision hasn't reached everyone. Fix the shared explanation and tell the team what changed. Don't make each support agent improvise their own version.

Make sure the decision reaches the door

Your response isn't finished when the refund or confirmation email goes out. The person checking tickets needs the same final answer, especially if the event is close. A customer who has received a valid booking confirmation shouldn't discover an unresolved internal discussion while a queue forms behind them.

Check that each cancelled admission has the right status in the ticketing system and that honoured purchases remain usable. Where your team uses downloaded lists or another check-in arrangement, follow the supported process to refresh them. Don't assume an email to the customer changes the admission record, or that a payment refund automatically performs every ticketing action you need.

Give the door supervisor a private escalation route for disputed orders. Staff should see the decision they need to admit someone or refer the case, without receiving the entire investigation. A label accusing the buyer of fraud can influence how staff treat them before anyone has checked the evidence. Record the relevant order status and contact instead.

If a review remains open near the event, assign someone to resolve it before doors. Contact the buyer with the confirmed position and enough time to act where possible. A cancellation after someone has travelled creates a different practical problem from a correction made while they are still deciding whether to attend. Include that timing in the remedy you consider.

Group bookings need particular care. The purchaser may have received your email while the other attendees only have their individual tickets. Ask the purchaser to share the confirmed information where appropriate, and check how replacement tickets will reach the people using them. Avoid leaving some members of the group with old ticket documents and others with the current version.

After the event, reconcile attendance and final refunds against the reviewed order list. An unused honoured ticket remains different from a cancelled ticket, and neither proves the buyer's original intention. The purpose is to settle the records and costs, so finance and customer support don't keep working from different accounts of what happened.

Ask for removal without spreading the code further

Contact the person or site that published the offer through its normal reporting or contact route. Explain that the promotion was intended for a restricted audience, identify the listing and ask for removal or correction. Preserve the evidence before requesting a change, because the post may disappear.

Ask your partner to correct the places they control and tell you where else they distributed it. A screenshot in a closed group, an email and a public post create different cleanup tasks. Give the partner current wording and a route for eligible buyers. They're more likely to help when they can tell members what to do next.

Removal reduces further discovery. It doesn't restore secrecy. Someone may have saved the characters or copied the post somewhere else, so don't reactivate an exposed reusable code on the assumption that the original listing was the whole problem. Your replacement needs controls that remain useful after someone forwards it.

Avoid public arguments about who leaked it. You can investigate accountability with a partner separately, including whether the distribution breached your agreement. Publicly accusing a customer or partner before you've established the facts gives the incident another audience and makes a practical correction harder.

Check scheduled emails, public event descriptions and other messages your team controls for the same code. A takedown request achieves little if tomorrow's campaign republishes it. Assign the cleanup rather than assuming the person who deactivated the code has also checked every distribution channel.

Check whether personal information leaked too

A reusable discount code becoming public doesn't by itself establish that anyone accessed personal data. But a forwarded invitation might contain names, membership details, order information or a private link that reveals customer records. Review what was actually exposed, including the content around the code.

If personal information was involved, bring in the person responsible for data protection and follow your incident procedure alongside the commercial response. The ICO's personal data breach guidance explains the UK assessment, documentation and notification duties. A reportable UK breach has a notification deadline, so don't wait for your discount investigation to finish before assessing that separate issue.

Keep the working files secure too. Investigating a leak shouldn't create a second disclosure through an openly shared attendee spreadsheet. Collect only what the review requires, control access and follow your retention arrangements once the case closes. Share order references with colleagues who don't need the underlying personal details.

Restore the offer with controls that match the promise

Before sending a replacement, decide how eligibility will actually be established. A new reusable word sent to the same audience can escape the same way. Where the platform supports it, individually assigned redemption or verified eligibility may suit the offer. Confirm the implementation rather than promising that a private link automatically checks identity.

For Loopyah codes, use the documented ticket-type selection and quotas to limit the offer you approve. Confirm what the quota counts and test the intended purchase. The public guide doesn't establish automatic leak detection, identity-based membership checks or every combination of offers, so verify anything else your plan depends on.

Keep the replacement within the total remaining commitment. Don't recreate the original allowance for each partner without subtracting valid purchases already made. If you've promised an eligible audience a benefit, account for it explicitly rather than letting several independent codes consume the same remaining tickets.

Test the replacement with someone who wasn't involved in configuring it. Give them the invitation an eligible buyer will receive and ask them to complete the supported test journey. See whether they can identify the right ticket, understand the conditions and obtain the correct price. Then check an ineligible purchase. You want evidence that the new arrangement delivers the promise and respects its restrictions, including what happens when the buyer makes an understandable mistake before payment. Save the result with your offer record.

Update the partner agreement and your own process based on the actual cause. If the wording was unclear, improve it. If public sharing was permitted accidentally, agree distribution boundaries. If the configuration was broader than the approved offer, require a purchase check before release. Each change should address something you found.

Close the incident when the exposed route is controlled, affected orders have a recorded outcome and eligible buyers can access the promised benefit. Leave the next campaign owner the original terms, verified cause and tested correction. That's what prevents the same private discount becoming next month's public offer.