Secure Event Ticket Payments: PCI DSS and Refunds

From an attendee's perspective, buying a ticket is simple: they select an attendance option, enter their details, pay, and wait for confirmation. For the organiser, the process is more complex. Prices, discounts, payer details, transaction status, sales documents, tickets, and any refunds all need to be handled correctly.

Online payment should therefore not operate as a separate component added to the registration form. It should form part of the entire sales and attendee service process.

How does online ticket payment work?

A typical process is as follows:

1. The attendee selects a ticket, package, or additional offer components.
2. They provide the details required for registration and, where necessary, the payer's details.
3. The system calculates the final amount, taking into account prices, discounts, and selected services.
4. The attendee proceeds to online payment or chooses another available payment method.
5. The payment provider confirms or declines the transaction.
6. The system updates the payment status.
7. A confirmed payment triggers the actions that the organiser has made conditional on receiving payment, such as sending a ticket or an appropriate message.

It is important that the transaction status does not depend solely on whether the attendee returns to the event website after payment. They may close the browser or lose their internet connection even though the payment was completed correctly. The system should receive confirmation directly from the payment provider and update the status on that basis.

Payment status should determine the next steps

Before ticket sales begin, define what should happen for every possible payment status.

Consistency is essential. An attendee should not receive confirmation of paid participation if the payment was unsuccessful. After a full refund, their ticket should not remain active if the event rules treat the refund as withdrawal from participation.

How to choose a payment gateway for an event

The price of the service matters, but it should not be the only criterion when selecting a provider. In particular, check:

• which payment methods are available;
• which currencies are supported;
• whether card payments and payments on mobile devices are supported;
• how full and partial refunds are processed;
• when funds are transferred to the seller's account;
• which reports the provider makes available;
• what support is available if a transaction problem occurs;
• how payment disputes are handled.

The choice of payment methods should reflect the event audience. For sales conducted primarily in Poland, it is worth checking the availability of BLIK, instant bank transfers, and cards. For an international event, cards, support for multiple currencies, and payment methods popular in attendees' home countries may be more important.

If you also allow traditional bank transfers alongside online payments, define the payment deadline and the rules for reserving a place until the funds have been credited.

PCI DSS 4.0.1: what should an organiser know?

PCI DSS v4.0.1 defines requirements for protecting data used in card payments.

The safest approach for an organiser is to limit contact between its own system and staff and card data. Card payments are therefore usually processed in the payment provider's environment or through form components supplied by the provider.

However, using an external gateway does not automatically resolve every PCI DSS matter. The scope of the organiser's responsibilities depends, among other things, on how payment has been integrated with the website and registration system.

In practice, the organiser should primarily:

• use a payment solution appropriate for the type of sales being conducted;
• agree with providers who is responsible for each part of the process;
• secure its own website and access to the administration panel;
• never collect card details in the registration form;
• never store card numbers or security codes in messages, notes, or other in-house systems;
• establish a procedure for responding to a security incident.

The detailed scope of PCI DSS requirements depends on the specific configuration. If in doubt, confirm it with the payment provider or a payment security specialist.

Currencies, prices, and taxes

Before sales begin, specify the currency in which the price is displayed and the currency in which the payment will be settled. If attendees can pay in another currency, also check who bears the conversion cost and what information will appear on their account or statement.

Before approving the payment, the attendee should see the full amount due. If you use discounts, additional fees, or different price levels, their impact on the final order value should be clear.

The method of calculating VAT, issuing invoices, and making adjustments depends on the type of transaction, the buyer, and the applicable regulations. The system can support the collection of payer details and the generation of documents, but tax rules should be agreed with the accounting team before sales begin.

Group payments and invoices

In group registration, the person registering the attendees, the attendees themselves, and the payer are not always the same person. Their roles should therefore be defined before the form is prepared.

One payment may cover the entire group, while each attendee's details remain stored separately. This makes it possible to prepare tickets, the attendee list, and participation information correctly while issuing a single sales document to the payer.

Before registration is completed, allow the payer to verify the details required for the invoice. Also define how subsequent changes will be handled, for example:

• replacing one attendee with another person;
• changing the payer's details;
• part of the group withdrawing;
• a partial refund;
• a correction to the sales document.

The earlier these rules are defined, the fewer manual arrangements will be needed once sales have begun.

How to plan refunds

Attendees should know the refund rules before purchasing a ticket. The terms and conditions should clearly specify, among other things:

• the deadline for cancellation;
• whether the refund covers the full amount paid;
• whether the ticket can be transferred to another person;
• what happens if the event is cancelled or rescheduled.

Link every refund to the correct order and payment history. Retain information about the original amount, the refund amount, the date, and the reason for the refund.

Refunding the money does not always mean that the attendee's data should be deleted automatically. You must, however, determine how the refund affects their ticket, attendance status, invoice, and subsequent communication.

It is also worth preparing a chargeback procedure for situations in which the cardholder disputes the transaction with their bank. Evidence of the purchase, the accepted terms of participation, and the history of contact with the attendee will then be useful.

What should be automated, and what still needs supervision?

Automation reduces the number of manual tasks, but the rules must be defined in advance.

The system can respond automatically to a change in payment status, for example by sending an appropriate message or making a ticket available once payment confirmation has been received. The organiser should nevertheless know what happens in exceptional situations: when the payment status remains unchanged for a long time, an attendee pays twice, the amount is incorrect, or a partial refund is required.

It is also worth regularly comparing the payment information stored in the registration system with the payment provider's reports. This makes it possible to identify discrepancies before they affect attendee service or financial settlements.

Checklist before ticket sales begin

• Prices and available participation options are configured correctly.
• Discounts and promotional codes calculate the correct amounts.
• The available payment methods meet attendees' needs.
• A successful payment has been tested.
• Declined and interrupted payments have been tested.
• Messages correspond to the correct payment statuses.
• Payer details are transferred correctly to sales documents.
• Group registration and payment have been checked, if available.
• Full and partial refunds have been tested, if the process provides for them.
• Responsibility for refunds and payment disputes has been assigned.
• Card details are neither collected in the registration form nor stored by the organiser.
• A procedure has been established for failures or payment problems.
• The payment report can be compared with the data stored in the registration system.

Payments as part of the registration process

Well-designed ticket sales do not end with providing attendees access to a payment gateway. Payment should be connected to registration, attendee status, sales documents, and communication.

CONREGO ticket sales connects the registration process with payments, sales documents, and communication. The organiser must still define the rules for sales, refunds, and exceptional situations and test the entire process before registration opens.