How to reuse payment groups for repeating events

Churches and ministries with a busy calendar hit the same question: how do you take bookings for event after event without either one enormous dropdown of every event you’ve ever run, or a fiddly workaround that only one person understands? The answer is a pattern: build one master payment group as your template, clone it for each event, and archive the clones when they’re done. It keeps every event’s bookings, emails and money separate, and setting up the next event becomes a couple of clicks.

Build your master template group

1. Set up a payment group and name it something obvious like ‘Event booking template’. This group never takes a real booking; it just holds your standard setup.
2. Add placeholder choices, ‘Option one’ and ‘Option two’ will do, plus the extras most of your events share, such as an optional-donation choice with a variable amount. In the booking options, leave the minimum and maximum number of choices blank if you don’t want to force a selection; blank means no rule, whereas zero tells people they must select between zero and zero.
3. Set up the data you collect from bookers and delegates once, including any standard consent questions and your terms and conditions, and turn on registrations on behalf of others so one person can book a couple or a whole team in one go.
4. Tidy the confirmation emails once, in the template, keeping the merge fields, so every clone inherits presentable emails.
5. In the introductory text, add a friendly line asking people to log in if they’ve booked before, and link the words to the login page (highlight the text, add a link, choose system page, then the login page). This one sentence is your best defence against duplicate John Smiths: bookings made while logged out create fresh profiles, and merging them later is tedious.

---

Clone it for each event, then archive

1. When an event needs bookings, open the template group and use Tasks > Copy. The clone arrives safely inert: it isn’t included in the menus, and its registration opening date is set a year ahead, so nobody can book before you’re ready.
2. Rename the clone after the event, adjust the choices and prices, and set the real registration open and close dates. Closing registrations the day after the event means latecomers see a polite ‘registrations have closed’ message instead of a booking form.
3. A payment group is its own page, so you don’t need to build an article for each event: the introductory text is the page content, and you can link straight to the group. On the calendar, edit the event and set its link to the payment group, and the event’s more-information link becomes the booking button; taking bookings for an event covers the event side.
4. After the event, create an ‘Archive’ subgroup under wherever your payment groups live (Tasks > Create a subgroup), then move the finished group into it (Tasks > Move to another group). Adding the year to the name as you archive, ‘Autumn Conference 2025’, keeps the history legible. Your working list stays short; nothing is deleted.
5. For the annual event, don’t reuse last year’s group: clone it, add the new year, and you get a clean list of this year’s bookers while last year’s stays intact in the archive.

---

Good to know

• A group per event is what makes the reporting effortless: each group’s summary shows how many booked and how much came in, the receivables tab lists every payment in date order, and Tasks lets you export to Excel, so comparing this year’s conference against last year’s is two exports and a spreadsheet.
• It also means personalised confirmation emails per event and an automatic list of exactly who booked that event, which one shared booking group can never give you.
• Resist the temptation to run many events through one group with a choice per event: the dropdown grows forever, every choice becomes a permanent subgroup, and reporting per event gets murky. The clone-and-archive pattern exists because the workaround always costs more later.
• Leave ‘create a website login upon completion’ off for event bookings: if someone already has an account but books while logged out, it would mint them a second username rather than reuniting them with their first.