What should you look for in event registration software?

Three questions a demo will not answer

Feature lists converge. Most platforms sell tickets, send confirmations and scan QR codes. The differences that decide whether a platform suits you sit underneath the feature list:

Everything else in this guide is a way of answering one of those three. If a vendor cannot answer them in writing, the demo was the product.

Price the platform at your volume, not at theirs

Registration software is priced in four ways, often combined. None is a trick; each suits a different pattern of events.

Payment processing is a fifth cost and it is not optional. Whoever processes the card charges for it, whichever model the platform uses. When the platform processes payments itself, that charge is often folded into its own fee, so compare what reaches your bank per ticket, not the headline percentage.

The one calculation worth doing is the crossover: the revenue at which a percentage fee overtakes a fixed one.

Then put a real year through every model you are considering. The figures below are placeholders — use your own events and each vendor's actual rates:

Same events, same attendance, and the cheapest model changes with the ticket price. That is why a platform that is cheap for one organiser is expensive for another, and why comparing headline rates tells you nothing. Run the calculation for the events you expect to run next year, including the free ones, before any sales call.

Where the money sits between sale and payout

Two models exist. Either the platform sells the ticket and pays you later, holding attendees' money in between, or you connect your own payment account and the money is yours from the moment it clears.

• When the platform holds the funds, its payout schedule is your cash flow and its terms decide when you can pay the venue deposit. Ask when payouts happen, whether anything is held back until after the event, and what happens to held funds if the event is cancelled.
• When you use your own account, you carry the relationship with the payment provider — onboarding, chargebacks, refunds from your own balance — and in exchange nobody sits between your attendees and your bank.

Neither is wrong. What is wrong is not knowing which one you are buying, because it decides whose name is on the attendee's card statement and who a refund comes from. If your events sell through more than one legal entity, it decides whether that is possible at all.

The checkout is the part attendees judge you by

Your attendees never see the dashboard. They see the registration page, on a phone, often between meetings. Buy the checkout by testing it the way they will use it:

• Complete a purchase on a phone, with a real card. Count the screens and the fields. Every field that is not needed for this event is a reason to stop.
• Pay with an EU card if you sell to Europe. Article 97 of the Payment Services Directive requires card issuers to apply strong customer authentication to most online payments, so the checkout has to hand the buyer to their bank's approval step — usually 3-D Secure — and bring them back. A checkout that handles it badly loses the sale at the last screen.
• Buy as a company. Many conference tickets are paid by an employer who needs an invoice in the company's name, with its address and tax number. Check whether that can be captured at checkout, or whether it becomes an email to your finance team.
• Buy for a colleague. One person paying for five attendees, each of whom needs their own ticket and their own confirmation, is ordinary for conferences and awkward on platforms built for one buyer, one ticket.
• Look at the price you are shown first. Whether booking or service fees appear in the price on the first screen or only at the end is increasingly a legal question, not a design one — covered in the ticket pricing guide.
• Try it with a keyboard and a screen reader. An online shop selling to EU consumers has been within the European Accessibility Act since 28 June 2025, unless the business is a microenterprise. The Act does not name a web standard itself; WCAG 2.1 at level AA, through the harmonised standard EN 301 549, is the practical benchmark to test a checkout against.

Test the event day before you sign

Check-in fails in predictable ways, and each one can be tested in an afternoon during a trial. Do these before you commit, not the week before the event:

The network test is the one that matters most, because venue WiFi fails at exactly the moment everyone arrives and uses it at once. A system that needs a live connection to scan a ticket is a system that stops at the door.

Data, contracts, and the way out

You are the one responsible for attendee data, whichever platform holds it. Five things to have in writing before the first registration:

• A processor agreement. GDPR Article 28(3) sets out what the contract with a platform processing attendee data for you must contain. Ask to read it before you buy, not after.
• The sub-processor list and the hosting location. Where attendee data is stored and who else touches it — email delivery, payments, analytics — named, not summarised.
• A complete export. Attendees, form answers, orders, refunds, discount codes and check-in records, in a format you can open without the platform. An export that stops at the attendee list loses the financial history.
• Roles and permissions. Whether a colleague can be given one event, or scanning only, without seeing everything.
• The end clause. How long data stays available after the contract ends, how you get it, and how deletion is confirmed.

A trial that tests the right things

A free trial is usually spent building a pretty event page. Spend it on this instead — about half a day:

• Sell yourself a real ticket with a real card, then read your card statement. Whose name is on it?
• Refund it. See where the refund comes from and whether the fees on it come back.
• Buy as a company for three colleagues and look at the invoice and the three confirmations.
• Export everything and open the files without logging in.
• Scan with the network off, on the phones your staff will use.
• Add a colleague with limited access and log in as them.
• Ask support one real question from your last event, and note how the answer arrives.
• Ask for the processor agreement and the sub-processor list and see how long they take.

What actually goes wrong

These follow from choices made at purchase, which is why they are cheap to avoid then and expensive afterwards:

• Chosen on a headline rate, outgrown on the actual one. A percentage fee that was sensible for a first small event becomes the largest line in the budget once prices and attendance grow — or a subscription chosen for a busy year keeps charging through a quiet one.
• Free events priced as if they were paid. A per-registration fee applies to free tickets too, so a large free community event can cost more to run than a paid conference.
• The check-in demo ran on office WiFi. Nobody tested the door without a network, and the first time anyone does is the first morning of the event.
• The export leaves out the money. Attendee lists come out cleanly, but orders, refunds and discount usage do not, so switching platforms means losing the financial history or rebuilding it by hand.
• The processor agreement was never asked for. The subscription was signed; the contract that GDPR requires for attendee data was not, and a year of registrations ran without it.
• Company buyers cannot get an invoice. The checkout was built for individuals, so every employer-paid ticket becomes a manual invoice and a reconciliation problem.

What to ask every vendor

Send the same questions to every platform on your shortlist — ours included — and compare the written answers, not the demos:

• What would last year's events have cost, in total, under your pricing, including payment processing and free events?
• Whose payment account takes the money, and whose name appears on the attendee's card statement?
• What happens at check-in when the network is down, and how do scans reconcile afterwards?
• Can we export every attendee, order, refund and check-in in an open format, at any time, without asking support?
• Can we read the processor agreement and sub-processor list before we sign?
• How do company buyers get an invoice, and how does one person buy for several attendees?
• What happens to our data when the contract ends?

The answers will not choose a platform for you. They will tell you which platforms you are actually comparing — which is usually fewer than the shortlist.