WooCommerce Event Registration on WordPress: Setup Guide

To take event registrations through WooCommerce on WordPress with Eventonomy, install both plugins, switch on your site’s own checkout in Eventonomy’s payment settings, and add paid ticket types to your events. Buyers pick tickets on the event page, pay through the payment methods you already set up in WooCommerce, and come back to a confirmation with a QR ticket for every seat. WooCommerce checkout is a Pro feature, and Pro starts from $99 a year.

This guide is about that one route. If you are still deciding how to sell tickets at all, or you want the money-flow explanation behind the no-fee claim, start with the general guide to selling event tickets without per-ticket fees. Here we stay with WooCommerce: when it makes sense, how the hand-off works, what you will see in each screen, and what to do when something does not behave.

Do you need WooCommerce to sell event tickets?

No. Eventonomy Pro supports three ways to take payment: Stripe, PayPal, and your site’s own checkout, which is the WooCommerce route. Stripe and PayPal each connect straight to your own account with keys you paste into Eventonomy’s settings. Neither needs WooCommerce installed.

So the real question is not whether WooCommerce is required. It is whether adding a full store plugin to your site earns its place. If all you do is sell tickets, the direct Stripe or PayPal route has fewer moving parts: one plugin, one settings screen, one webhook to configure.

All three methods are hosted-redirect. The buyer is sent away to pay and then returned to your site, so card details never touch your site. That holds on the WooCommerce route too: the buyer pays through your WooCommerce checkout and returns to their confirmation.

You can offer more than one method at the same time, with one exception that matters for this guide. When the WooCommerce option is on, it is the only method offered. We come back to that below, because it shapes how you plan your setup.

When does the WooCommerce route make sense?

It makes sense when WooCommerce is already doing a job on your site and you want tickets to live inside that world rather than beside it. The usual reasons:

• You already run a store. You sell merchandise, memberships or courses, and tickets are one more thing you sell. Your customers already know your checkout.
• You want the gateways you already have. Whatever payment methods you have switched on in WooCommerce are the ones ticket buyers get. There is nothing to reconfigure in Eventonomy, because no API keys are entered on the Eventonomy side for this route. WooCommerce holds them.
• Your accounting is built around WooCommerce. Order records for tickets sold this way live under WooCommerce → Orders, next to the rest of your sales.
• Your team already knows the store. Whoever handles payment questions on your site already knows where to look.

It makes less sense in two cases. If you do not run a store and have no plan to, installing WooCommerce only to sell tickets adds a plugin to maintain. And if you want buyers to choose between Stripe and PayPal as separate options on the ticket form, the WooCommerce option is not the one to use, since it replaces those rather than sitting beside them.

None of this changes the cost story. Eventonomy takes no per-user fee, no per-ticket platform fee and no commission, whichever route you pick. The gateways you run inside WooCommerce charge their own processing fees, and those belong to the gateway, not to us.

What do you need before you start?

Three things are required, and the first two are about WooCommerce rather than Eventonomy:

1. WooCommerce is installed and activated.
2. At least one WooCommerce payment method is enabled, under WooCommerce → Settings → Payments.
3. Eventonomy Pro is active.

Eventonomy checks this for you. On its payment settings screen the WooCommerce card shows Ready only when WooCommerce is active and at least one of its payment methods is on. Otherwise it shows Not set up, with a note telling you to switch on a payment method in WooCommerce first.

Each event also has to be set to People register here in its Registration section. An event whose registration lives on another site, or one that takes no registration, refuses orders on the server as well as hiding the ticket panel, so nothing can be sold on it.

How does the WooCommerce bridge work, step by step?

The docs describe the bridge as handing the order to your existing WooCommerce installation and using whatever payment methods you configured there. Here is the setup, in the order you would do it.

1. Set up WooCommerce payments first. In WooCommerce → Settings → Payments, switch on the methods you want ticket buyers to see. Test them the way you would for any product in your store.
2. Open Eventonomy’s payment settings. Go to Eventonomy → Settings → Payments → Payments (Pro). Under Offer at checkout you will see each method with a status badge.
3. Tick the WooCommerce option. It is labelled This site’s own checkout (WooCommerce). No API keys are needed here, since WooCommerce holds those. Save your changes.
4. Know what the save does to other methods. Any other method you had switched on stops being offered, because the WooCommerce option takes over. Buyers will not see Stripe or PayPal while the WooCommerce option is on.
5. Add paid tickets to an event. Open the event editor, open the Tickets panel and add a ticket with a name, a Paid type, a price and a quantity. A quantity of 0 means unlimited. You can set an optional sales window, with a start and an end in the event’s time zone.
6. Check the buyer’s view. Open the event page in a private window. Until a visitor picks a quantity, the page shows only the tickets and prices. After that, the buyer fields appear, along with a live summary showing subtotal, any discount, service fee, tax and total.

When a buyer completes the purchase, three things follow:

• The buyer pays through your WooCommerce checkout and returns to your site.
• The order is settled as paid, and an attendee ticket with its own QR code is created for each seat. Three seats means three separately scannable tickets.
• A confirmation email and a downloadable PDF invoice are generated.

Where the buyer lands depends on whether they are signed in. Signed in, they see the order confirmation card on their member dashboard. Not signed in, they get their own order page showing the event, every ticket with its QR, and the invoice link. No account is needed for that page; the link is the credential, and it is repeated in the confirmation email.

One detail you may like: buyers never see the word WooCommerce. Eventonomy presents the option as paying on your site, because from the buyer’s side that is what it is.

Why is it the only method offered?

Because it already contains your WooCommerce methods. If Stripe is one of your WooCommerce gateways and Eventonomy also listed Stripe separately, the buyer would be choosing between a method and the checkout that holds it. The money would also land in a different place depending on which they picked. So Eventonomy offers one or the other, never both.

If you would rather give buyers a Pay with selector with Stripe and PayPal side by side, leave the WooCommerce option off and switch those two on instead. With several methods on, the Active gateway setting decides which one is pre-selected.

What shows up in WooCommerce orders and what shows up in Eventonomy?

Two places hold records for the same sale, and each answers a different question.

WooCommerce → Orders is where the order records for WooCommerce-paid ticket sales live. That is the place for payment questions: what was charged, which method was used, what your gateway reports.

Eventonomy → Attendees & Orders is where you manage the event side. It has an Attendees tab and an Orders tab. For each attendee you see name, email, RSVP status, party size, whether they have been checked in (Pro) and when they registered. You can filter by event, status, check-in state, date range and search, and export attendees or orders to CSV. Orders carry a status of pending, paid, cancelled, refunded or failed, and an order number with a prefix you set at Settings → Payments → Orders → Order number prefix.

A person who holds a ticket from an order shows as a Ticket holder rather than getting a status menu, because their status follows the order. To remove them, cancel or refund the order. That frees the seat and voids the ticket together.

Our docs do not describe a field-by-field mapping between the two order screens, so we will not invent one. The practical advice is to run one test purchase before you go live and look at both screens side by side. You will see exactly what your own setup records.

Can you offer free RSVPs alongside paid tickets?

Yes. Free tickets work in the free plugin, and an event can hold up to 100 ticket types. A common pattern is a free general ticket next to a paid ticket that includes something extra, such as a workshop seat or a dinner.

A free ticket is a zero-dollar ticket, and registration completes immediately with no payment step. The order is created as paid straight away. Paid tickets need Pro and a working payment method. On the free plugin, or on Pro with no method configured, a paid-ticket event shows a plain notice that online ticket sales are not available yet, instead of an Order button that goes nowhere.

If an event needs no payment at all, you do not need WooCommerce for it. See event registration on WordPress for how plain RSVPs work.

How do capacity and waitlists work with paid tickets?

Each ticket type has its own quantity, and the event can also carry an overall capacity. Because every seat is its own attendee and you cannot add guests to a ticket booking, a ticketed event cannot be oversold by the guest field. A buyer who wants a friend to come buys a second seat and enters that person’s name.

When a paid event sells out, you can let visitors join a waitlist. Turn on Waitlist when full under Eventonomy → Settings → Registration. A visitor then sees a Join waitlist button, needing only a name and an email if they are logged out. Nothing is charged, no order is created and no ticket is issued.

The important point for paid events is that nobody is promoted automatically. On a free RSVP event, the oldest waitlisted person is promoted when someone cancels. On a ticketed event that step is switched off on purpose, because a paid seat needs a paid ticket.

Instead, when a seat frees up, everyone on the waitlist gets an email headed “A seat is open for” the event, with a Buy your ticket button. A seat frees up when someone cancels, a refund is issued, or an unpaid checkout expires. The first person to complete checkout gets the seat. Nobody has a reserved seat and there is no countdown, so the waitlist does not show a queue position. This email is classed as essential and still reaches people who unsubscribed from notification mail.

That email links to the event page, which sends the buyer back through your normal checkout. With the WooCommerce option on, that means your WooCommerce payment methods.

If you would rather pick who gets in, you can contact people from the attendee roster, or use Add attendee with a comp ticket for someone you are admitting without charge. The full detail is in the docs on waitlists for sold-out paid events. For the free-event side, see RSVP and waitlist on WordPress.

How do refunds work for WooCommerce-paid tickets?

Refunds are a Pro feature, and there are two things to know.

You can refund from Eventonomy. On the Attendees & Orders screen, each paid order with a gateway has a Refund button. Click it and confirm the two-step prompt. For a WooCommerce-paid order, the docs say the button drives WooCommerce’s own refund for you, even though the order record itself lives in WooCommerce → Orders. You do not have to open WooCommerce to do it.

A refund is always the whole order. Neither the Refund button nor the REST route takes an amount. This is deliberate: a part-refunded ticket has no clear meaning at the door. If you need to return part of a payment, do it in your gateway’s own dashboard. Eventonomy records what the gateway reports, the order stays paid and the tickets stay valid.

When a full refund goes through, Eventonomy does the following on its own side:

• Releases the ticket stock so the seat can be sold again.
• Voids the attendee tickets, so a scan of a refunded QR is refused at the door.
• Releases any held coupon use, so a limited-use code is free for someone else.
• Emails the buyer to say what happened, including that the money can take a few days to appear.

Two related points. Cancelling an event does not refund anything by itself; you refund each paid order from the Attendees & Orders table. And ticket holders can ask to cancel. They use a Cancel and request refund button on the event page, in My tickets, or on their order receipt page. Asking moves no money and frees no seat until you approve, and you can also decline, in which case the order stays paid and the tickets stay valid. Open requests are listed under the Refund requested filter on the Orders tab.

You can also show your refund and cancellation policy text to buyers. Enter it at Eventonomy → Settings → Payments → Refund and cancellation policy.

How do tax and booking fees work?

Eventonomy Pro can add a tax rate and a booking fee to every paid order. Both are set at Eventonomy → Settings → Payments → Tax & Fees (Pro), and both appear in the order summary before the buyer pays.

The order of operations is fixed. The coupon discount comes off the subtotal first. Then the booking fee is calculated on the discounted amount, and tax is applied on top of the discounted subtotal plus the fee when the buyer pays the fee, or on the discounted subtotal alone when you absorb it. All of it is recalculated on the server when the order is charged, so a tampered price in the browser changes nothing.

On tax, you choose whether ticket prices already include tax or whether tax is added on top, and you can relabel it as GST or VAT. The rate is one site-wide percentage. There is no per-event or per-ticket setting, though developers can vary it by event with a filter.

On fees, you pick a percentage of the subtotal or a fixed amount per order, and decide whether the buyer pays it or you absorb it. If you absorb it, it is recorded on the order but not added to the charge.

If you are on the WooCommerce route, you may already have tax configured inside WooCommerce. Our docs do not describe how that interacts with Eventonomy’s own tax setting, so do not assume they combine or cancel. Decide which one you want to be the source of tax on tickets, and confirm what a test order shows before you take real payments.

Coupons follow the same logic: percentage or fixed amount, usage limits, start and end dates, a minimum subtotal, and a restriction to one event or ticket type. Early-bird pricing is set per ticket and returns to the normal price when its end time passes.

How do you check people in at the door?

Check-in is a Pro feature and it works the same whichever payment route you used. Every attendee ticket carries a QR code, and it appears on the order confirmation card, in the confirmation email and in My Tickets.

At the door, a staff member scans the QR with any phone camera. No app is needed. The attendee is checked in, and a second scan of the same ticket shows Already checked in rather than counting twice. A ticket from a refunded order is refused.

Who can scan matters. Only two kinds of signed-in user can redeem a ticket: the event’s own organizer, meaning whoever created the event, and a site administrator. An Editor who did not create the event is not admitted. If your door staff are Editors, make them the author of the event or give them the Administrator role. Anyone else who scans a code, including the buyer scanning their own, sees a neutral page that says to present it at the door, and nothing is checked in.

For hardware readers or a backup when a ticket will not scan, the check-in block has a Find attendee field: type a name or email, or paste a ticket link. For a longer walk-through of running a door, see the event check-in guide.

What goes wrong, and how do you fix it?

Most WooCommerce route problems come down to a few settings. The full list lives in the payment troubleshooting page of the docs; these are the ones that come up first.

The WooCommerce card says Not set up. The card shows Ready only when WooCommerce is active and at least one payment method is on. Go to WooCommerce → Settings → Payments, switch a method on, then reload the Eventonomy card.

Buyers only see one payment option. That is the design. With the WooCommerce option on, it is the only method offered. Untick This site’s own checkout (WooCommerce) under Offer at checkout if you want Stripe or PayPal offered directly. In the settings the other methods can show as Replaced by WooCommerce while it is on.

A method is ticked but buyers do not see it. The badge will read Not offered: finish setup. A method needs to be both configured and switched on. Open its card and fill in what its row says is missing.

A paid order stays pending. For Stripe, check the webhook signing secret first. For any method, Eventonomy Pro re-checks stale pending Stripe orders hourly, and that relies on working background tasks on your site. If your site has trouble running scheduled jobs, fix that too.

Online ticket sales are not available for this event yet. Either Pro is not active, no payment method is ready, or the event is not set to People register here.

A late payment arrives after checkout expired. A buyer who takes too long loses the hold, and the hourly sweep cancels the pending order and frees the seats. If the payment completes anyway, Eventonomy honours it, and the buyer gets their tickets. If the room filled in the meantime, the event is over capacity, the organizer is emailed with a link to the attendee list, and you can refund the order there if you cannot seat everyone.

A setup checklist for WooCommerce event registration

Work down this list on a staging copy or with a hidden test event before you announce anything.

1. Install and activate WooCommerce, and switch on at least one payment method.
2. Install and activate Eventonomy Pro.
3. Confirm the WooCommerce card under Eventonomy → Settings → Payments shows Ready.
4. Tick This site’s own checkout (WooCommerce) under Offer at checkout and save.
5. Set your currency under Settings → Setup → Currency. Ticket prices are always in the store currency.
6. Decide on tax and booking fees, and set them under Tax & Fees. Decide where tax comes from if WooCommerce also has tax configured.
7. Write your refund and cancellation policy text.
8. Create an event, set Registration to People register here, and add a free ticket and a paid ticket.
9. Turn on Waitlist when full if you want a waitlist on sell-outs.
10. Buy a paid ticket yourself. Check the confirmation, the email, the PDF invoice, WooCommerce → Orders and Eventonomy → Attendees & Orders.
11. Refund your test order from Attendees & Orders and confirm the seat comes back and the ticket stops scanning.
12. Pick your door staff and make sure each one is the event’s organizer or an Administrator.

Where to go next

The free plugin covers events, free tickets, RSVPs, capacity, waitlists, reminders and CSV exports. Taking payment, including the WooCommerce route, needs Pro. The Free vs Pro page lists exactly what sits on each side. For the wider picture of how ticketing works on your own site, see Event tickets on WordPress, and for the gateway setup in full, read the payment gateways docs and the refunds and cancellations docs.