What payment-security responsibilities belong to an event organizer?

Your ticketing provider handles the payment, so what does your team still need to protect? Quite a lot of the work around it. You choose who can access the account, what staff do when a buyer needs help, which devices sell tickets at the door and how the business responds when something looks wrong.

For most event operators, the sensible starting point is to keep card details inside the provider's supported payment tools. Then make the responsibilities around those tools clear. A secure checkout loses much of its value if someone asks buyers to email card photographs because the box office is busy.

Payment security also needs to fit the way your event runs. Temporary staff, hired venues and last-minute equipment changes are ordinary parts of the business. Your process should account for them before the queue forms. Otherwise, the person trying to keep sales moving ends up deciding what is safe on everyone else's behalf.

This guide explains where your responsibilities begin, what to ask your providers and how to build instructions your team can actually use. The operating examples are hypothetical. Your specific compliance requirements come from your payment arrangements and the organization responsible for accepting your compliance evidence.

Establish who is responsible under your actual agreement

Start with the business accepting the card payment. Your brand might appear throughout checkout, but branding doesn't establish which legal entity is responsible for the transaction. Find that answer in your agreements. Then identify the payment provider, any separate ticketing service and the person who manages the relationship inside your business.

Ask who tells you which security requirements apply. This may be your acquiring bank, the organization that provides your business with access to card acceptance, or another organization managing your compliance program. Get the correct contact through your provider. Don't assume a sales representative's general reassurance settles the requirements for every sales channel.

PCI DSS is the Payment Card Industry Data Security Standard. It sets requirements for protecting payment account data. The PCI Security Standards Council's outsourcing guidance says merchants retain responsibilities when they outsource payment processing, including checking provider compliance, documenting responsibilities and monitoring the provider's compliance status at least annually. Confirm your validation obligations with the organization managing your compliance program.

That doesn't mean you should recreate the provider's technical work. It means you need a clear agreement about the services it covers and the work your business retains. Ask for the relevant compliance documentation and responsibility statement. Have someone qualified to review them explain anything that doesn't match your actual setup.

An online ticket sale and a card payment taken at the venue may involve different services. A telephone sale can introduce another arrangement again. Describe all the ways your business accepts cards before asking which requirements apply. Leaving out the occasional manual sale can produce an answer that fits your normal checkout while missing what your team actually does.

Ask the provider to describe the boundaries using your event as the example. If you sell advance tickets online and accept cards at the door, have it explain both routes. Request confirmation of what changes when you add a new device, move venues or introduce a different checkout integration. Those changes can matter even when your commercial agreement stays with the same company.

Keep the response with the account records. Include the date, the service it describes and the person responsible for reviewing it when your setup changes. You want someone taking over next season to understand why the business chose this process. An old email saying "we handle security" doesn't explain whether the answer covered your current sales arrangements.

Map where card details can enter your business

Walk through a ticket purchase as a customer would, then follow what happens when the purchase goes wrong. Where do they enter their card details? Where does your support team look for the order? What happens if they cannot complete payment, want to upgrade or arrive without their confirmation?

The ordinary purchase is usually the easiest part to describe. The exceptions reveal the additional work. A buyer calls the office to reserve places. A promoter offers to collect payments for a group. A staff member volunteers to type the customer's details into a personal laptop. Each creates a question your normal checkout instructions may never have answered.

Make a short record of each supported sales route. Include the provider used, the equipment involved, who operates it and where the payment record appears. Add the support route for a failed payment. You don't need a complicated technical diagram to discover that a contractor has been using an unapproved form to collect deposits.

Keep this exercise focused on payment information. An attendee list containing names and email addresses still needs appropriate protection, but it isn't the same thing as a file containing full card numbers. Knowing which information your team actually sees helps you set useful restrictions without treating every ordinary event record as interchangeable.

Then remove the routes you cannot properly support. If your team has no approved telephone payment process, don't let a helpful employee invent one. Offer the customer's normal checkout link or ask the provider for an accessible supported alternative. A smaller set of well-understood options is easier to operate than several improvised ways to get paid.

Keep card handling out of ordinary customer support

Your support team needs enough information to find a purchase. It usually doesn't need the buyer's full card number or security code. Start with the order reference and the contact information associated with the booking. Follow your provider's identification process before changing an order or revealing information about it.

Write that instruction into support replies. A useful message says, "Please send your order reference and the email address used for the booking. Don't send your card number, security code or a photograph of your card." Adjust the requested details to the tools you actually use, and keep the reply short enough that buyers read it.

The PCI Council's guidance on messaging technologies explains that using email, text or chat to send or receive full card numbers brings those channels and related systems into PCI DSS scope. Ordinary messaging isn't a harmless extension of checkout. For an event team, keeping payment entry in the approved service avoids creating that additional card-handling process.

If someone sends details anyway, don't forward the message around to find out what to do. Stop using the information and follow your provider's procedure for information received through an unintended channel. Have your security contact coordinate containment, evidence and secure removal. Staff need a named contact for this situation before it happens.

There's a firm rule about the security code printed on a card. The PCI Council says it cannot be retained after authorization, even if encrypted or the customer agrees. Don't keep it in a booking note for a later balance payment. Ask the provider how future payments can be taken through its supported process.

Accessibility belongs in the supported payment process too. Some buyers will need assistance because they cannot use the standard checkout independently. Agree an appropriate alternative with your provider and train the relevant staff to help. Don't make the buyer choose between abandoning their purchase and sending sensitive details through a channel your business hasn't approved.

For example, a support agent might help explain the booking steps while the customer enters payment information privately. Another situation may require a different approved service. Ask what works for the particular need, rather than assuming a general instruction to "buy online" resolves it. The goal is a usable purchase with the same care for payment information.

Give people access for the job they actually do

A person checking tickets has a different job from someone approving refunds or changing the payout destination. Look at the permissions your ticketing and payment accounts actually provide. Assign access to match those jobs, and check each account separately when the services use different logins.

Where the service supports individual accounts, use them. A shared founder login makes it harder to remove one person's access or understand who changed a setting. It also means a temporary worker may receive authority far beyond the task they were hired to do. Convenience at setup can create difficult decisions during an incident.

If a service cannot separate a sensitive task, decide who performs it and how staff request it. For example, door staff can refer refund requests to a supervisor rather than receiving the supervisor's password. Explain the tradeoff before the event. An access restriction without a workable escalation route encourages people to bypass it when customers are waiting.

Protect the accounts that control recovery too. Your business email may receive password resets for ticketing, payment services and banking. CISA recommends requiring multifactor authentication wherever possible, with phishing-resistant methods preferred. Check what each service supports, especially for administrators and anyone handling sensitive information. Don't assume every connected service has identical protections.

Make recovery a business responsibility. Know who can restore access if the account owner's phone is lost during setup. Keep recovery information in an approved secure location, with access limited to the people responsible. Test the supported recovery procedure before a major on sale, rather than discovering the only recovery address belongs to a former contractor.

Treat payout changes and refunds as sensitive actions

Payment security includes what authorized accounts can do with your money. Someone who controls a payout setting may redirect revenue without ever seeing a buyer's full card number. Someone misusing refund access may cause losses through entirely genuine payment tools. Your operating rules need to cover both situations.

For changes to payout details, use the service's official account process and verify the instruction through an established business contact. Decide who can request the change and who checks it. If your business can support another approver, use one. The approval should come from someone able to assess the change, rather than someone who simply clicks whatever arrives.

Watch the timing. An urgent request during a ticket launch or while the finance lead is travelling deserves the same verification as a quiet weekday request. Plan how the backup decision maker works. Saying "only the owner can approve" isn't much protection if everyone shares the owner's login whenever the owner is unavailable.

Refunds need their own instructions. Use the provider's supported refund workflow and establish what happens when a customer asks for the money somewhere else. Don't improvise a bank transfer because a message says their card has changed. Escalate that request through the approved process and verify the customer's authority to request it.

Our guide to protecting an event business from phishing scams covers independent checks for sensitive requests in more detail. For payment operations, apply those checks to the actions that change where money goes. Familiar event details, a believable email signature and a hurried colleague don't replace verification.

Choose and control the equipment used at the door

Taking payments at a venue adds physical equipment and temporary working conditions. Agree with your provider which phones, tablets, terminals and software are supported for your arrangement. A device being capable of running an app doesn't establish that it is approved for the payment service you intend to use.

Keep a record of the equipment assigned to each sales position and the person responsible for it. Check it when issued and returned. For hired equipment, agree who supplies it, who maintains it and who can replace it. Your box office supervisor should be able to identify an unfamiliar replacement without having to recognize every contractor working on site.

Where you use payment terminals, the PCI Council's inspection advice recommends keeping an inventory, knowing how devices should look and watching for tampering or substitution. If a terminal looks altered, stop using it and contact the supplier or merchant bank. Don't ask an untrained staff member to investigate the hardware while buyers continue paying.

Phones and tablets need everyday controls too. Apply supported updates before the event, use screen locks and keep devices under the assigned person's control. Test the payment app after updating. A device left unlocked on an unattended counter can expose whatever that account allows, even when the underlying payment service remains secure.

Tell staff who is allowed to service equipment. An unexpected visitor saying they're replacing a faulty reader should be verified through the contact already agreed with your supplier. A high-visibility vest and knowledge of the venue aren't sufficient. Make it easy for staff to pause the exchange and get a supervisor without being blamed for slowing things down.

Agree the venue network and the fallback before opening

Ask which connection the payment equipment needs and who provides it. Your venue contact should understand that a working connection for attendees doesn't answer the box office question. Test the actual payment setup in the actual sales location, with the equipment and account your team will use.

Have the venue or technical supplier explain the appropriate network setup for the payment service. Don't guess that a network is suitable because its name includes "staff" or because it requires a password. Keep attendee access and payment operations separated as the supplier and payment arrangement require, and document who resolves connection problems.

Then choose the supported fallback. That might be another approved connection, another approved device or directing customers to the normal online checkout. Check how the alternative affects order confirmation and admission. If it cannot reliably establish a valid purchase, your team needs a clear rule about whether sales pause.

Offline payments require particular care. Only use an offline mode your provider expressly supports for your account and equipment, with its stated limits and risks understood. A staff member collecting card numbers to process later is creating a different card-handling method. Don't describe that as offline functionality or allow it as an informal substitute.

Consider a hypothetical workshop selling the remaining places at the venue. The connection fails while people are arriving. The supervisor uses the agreed backup connection, checks that payment and ticket confirmation work, then restarts sales. If the backup also fails, the team follows the agreed pause procedure. Nobody has to decide whether writing down cards is acceptable.

Protect your event website and payment links

Even when a provider hosts payment entry, your own website and communications can influence where customers go. Control who can edit ticket links, publish event pages or change website settings. A customer following your official page should reach the payment destination you intended. Include printed codes and partner listings in that check.

Test the complete route before opening sales. Follow the link from your event page on a phone, check the destination and complete the supported purchase test. Repeat the check when someone changes the page or replaces a checkout integration. Your team should know which changes require a technical review before they are published.

Embedded payment forms deserve a question to the provider. The PCI Council's explanation of script protection for Self-Assessment Questionnaire A distinguishes embedded forms from redirects for that eligibility criterion. Ask how your implementation meets the applicable conditions. Don't infer eligibility from the word "embedded," or assume that a redirect removes every other obligation.

The practical issue is what your website loads and who can change it. Marketing tags, plugins and other additions should go through the person responsible for the site. Don't add unfamiliar code to a payment-related page because a freelancer says it will improve measurement. Have them explain the change and obtain the appropriate technical approval.

For printed payment codes at the venue, check that the displayed code leads to the correct official page. Inspect the signs after installation and when staff take over a sales position. If a sign appears replaced or covered, remove it from use while you verify it. The provider cannot protect a buyer who has been redirected to somebody else's payment page.

Train temporary staff around the situations they'll face

A policy is useful only if the person covering the desk knows how to apply it. Give temporary staff a briefing built around their work: finding an order, helping a buyer complete checkout, reporting a suspicious device and calling the right supervisor. Keep wider compliance documentation available to the people who manage it.

Practice a difficult support conversation. A buyer says their phone has died and offers to dictate a card number. The staff member should know which approved payment option is available, how to explain it politely and who can help if it doesn't meet the buyer's needs. They shouldn't have to invent a payment procedure to appear helpful.

Practice an account request too. Someone calling themselves payment support asks for a login approval so they can fix a fault. Staff should stop, contact the supervisor and verify the request through the provider's established support route. The briefing needs to say that reporting the request is part of the job, even when the person sounds knowledgeable.

Make reporting a mistake easy. If someone has shared a code or opened an unexpected link, you want them to tell you immediately. A team that expects public criticism may wait until the shift ends or hope nothing happens. Explain the first action and the contact to use, then handle reports without turning the desk into an interrogation.

Keep the instructions accessible during the shift. A supervisor contact, approved payment methods and the rule for stopping a suspicious transaction can fit into a short briefing sheet. Your detailed risk assessment may remain elsewhere. The person at the counter needs the answer while a customer is standing there.

Respond to a suspected problem without destroying evidence

Name the person who coordinates a payment-security incident before you need them. Include provider support, your technical contact and whoever advises the business on legal obligations. Make their contact routes available without relying entirely on the account that might be compromised. Keep the record current when providers or staff change.

If a device looks tampered with or an account behaves unexpectedly, stop the affected activity and contact the responsible people. Tell them what you observed, which device or account was involved and when it happened. Record facts without adding unsupported conclusions. A failed payment alone doesn't prove a breach, but it can still justify investigation.

The FTC's data breach response guidance advises containing further loss while preserving evidence and involving appropriate technical and legal support. Don't wipe a device, delete records or make improvised repairs to get back to selling. Follow specialist instructions about disconnecting equipment, preserving information and restoring service.

Customer communication needs the same care. Decide who speaks for the business, confirm what is known and get advice on any required notifications. Different laws and agreements may apply depending on the incident and the people affected. Avoid promising that no information was exposed before the investigation establishes that, or announcing a breach on the strength of an unexplained error.

Keep commercial decisions explicit while the investigation continues. Can an unaffected approved sales route remain open? Who authorizes its use? What should staff tell customers waiting to buy? A documented incident response helps the event continue safely where possible without asking door staff to make technical judgments beyond their role.

Work through a busy-door example before you need it

Imagine you're running a paid conference in a hired venue. Advance sales use the approved online checkout. At the door, a small team sells remaining places through the payment setup confirmed by your provider. The event manager holds administrative access, while the supervisor manages the sales equipment and customer escalations.

During the rush, a buyer says their payment failed and offers a screenshot containing card information. Your staff member asks them to keep the card information private and checks the order through the approved account tools. They establish the payment status before asking the buyer to try again. The customer's urgency doesn't change the information needed to investigate.

Next, a sales device stops connecting. The supervisor checks the agreed backup and confirms it can complete the purchase and provide the correct ticket. If it works, sales continue through that route. If it doesn't, staff pause that sales position and direct buyers according to the event plan. They don't collect card details for someone to enter later.

Then someone arrives claiming to be the terminal supplier and asks to exchange a device. The supervisor keeps the existing equipment under control and verifies the visit with the supplier through the established contact. If it wasn't authorized, the exchange doesn't happen. That decision is easier because staff already know who can approve repairs and replacements.

None of these situations requires the door team to interpret PCI requirements. The business has already agreed the supported methods, assigned the decisions and made the contacts available. Staff can stay helpful because they have somewhere appropriate to take the problem. Rehearse the example with your real names and equipment before the briefing ends.

Review records and remove access after the event

The event finishing doesn't finish the payment work. Customers may still need refunds, and your team may need to investigate disputed or incomplete purchases. Keep appropriate order references and transaction records in the approved systems. Avoid downloading sensitive information simply because somebody might want it later.

Set a retention approach for the records your business actually needs, taking account of legal, contractual and operational obligations. Someone should own the decision and the deletion process. Retaining every export indefinitely makes it harder to know where customer information exists and who can still access it.

Remove temporary access when the work ends. That may happen at different times for door staff, customer support and finance. Check both the ticketing service and any separate payment account. Recover devices, revoke access through the supported tools and confirm that the person receiving future customer enquiries can still do their job.

Review exceptions with the people who handled them. Did customers repeatedly need an alternative checkout route? Did staff borrow access because a supervisor was unavailable? Did a venue connection fail despite the test? These observations tell you which process needs changing before the next event. Asking staff to be more careful won't fix a procedure that left them stuck.

Our guide to selling tickets at the door covers the wider connection between payments, ticket validity and available capacity. Use the payment-security review to improve that operating plan. The approved route should be practical enough that staff can complete a sale without creating a second unofficial process.

For a recurring event series, review the plan when something meaningful changes. A new venue might supply different connectivity. A new ticket offer might introduce later balance payments. A new contractor might need access to customer support. Ask whether the existing arrangement still covers the work before copying last season's instructions into the next production folder.

Give finance and customer support a chance to review those changes together. Finance may see exactly who can move money, while support sees the awkward requests arriving from buyers. Comparing those experiences often reveals the missing instruction: who handles an unexpected payment status, who approves an exception or how a customer gets help outside office hours. Agree the answer, update the relevant instructions and tell the people affected. A review only improves the next event when the staff using the process hear what changed and understand why.

Put the responsibilities into a usable event plan

Bring the decisions together in the same place your event leads use for operating instructions. Name the person responsible for payment-provider requirements, account access, equipment, venue connectivity and incident coordination. One person can hold several responsibilities in a smaller business. What matters is that each job has an owner and an available backup.

Keep provider duties separate from your own actions in that document. Your provider may protect payment processing, while your team issues devices and checks who can use the account. State what each party has agreed to do. If a responsibility is unclear, ask the provider to resolve it before the next launch.

When evaluating Loopyah's ticket-selling tools, include your actual operating questions in the conversation: how your team handles checkout support, in-person sales and account access for your event. Confirm the current setup and your responsibilities directly. Keep the provider's confirmation with your current agreement, and name the person who will check it when your payment setup changes.

Before opening sales, ask a staff member to explain what they would do if a buyer sent card details, the sales device failed or someone requested a payout change. If the answer requires borrowing a password or inventing a payment method, fix that part of the plan. Your team needs a supported next step they can use when the event gets busy.