When someone pays for an event registration, the payment is only part of what happens. The key change happens right after the registration package line on the order is reported paid, when Rhythm runs fulfilment. Fulfilment makes the registration real: Rhythm activates it, or holds it for approval, and creates the related records the buyer paid for. That can include guests, sessions, function tickets, course enrolments, and a webinar join link, all from the same order and without staff creating them by hand.
From Payment to an Active Registration
When an order includes a registration package, Rhythm activates the matching registration as soon as that package line is reported fulfilled. Fulfilment depends on the registration package's own line, not on whether the whole order has settled. An order can include other lines that fulfil on a different schedule, so one line's state does not have to match another line's state or the order's overall status. If the registration type requires approval, Rhythm saves the registration as pending approval instead, so staff can review it before it takes effect. You cannot configure a registration type or package so someone registers first, waits for approval, and pays only after approval is granted. Approval happens to an already-paid, fulfilled order, not before one. If a registrant directory is limited to admitted attendees, that registrant does not appear until approval is complete. Guests work differently: even when the parent registration is held for approval, each guest registration is saved as active because guests do not carry the approval flag themselves.
A registration's status and its related order's status are separate, and they do not always move together. The registration's status — Active, Pending Approval, Draft, or Cancelled — determines whether Rhythm treats someone as registered. The order's status describes the transaction that paid for it. An order can show Completed while the registration it paid for is still Pending Approval, and later order changes do not automatically change the registration's status. If you build an integration on top of Rhythm, use the registration record as the source for whether someone is registered, not only the order state. A cancelled registration can still be attached to an order that remains completed or settled, so an integration that checks only the order can overstate who is actually registered.
Warning
If a fulfilment report for an order is redelivered, such as after a temporary error, Rhythm recalculates the registration's status from that report. A registration that a staff member cancelled by hand can therefore be set back to active by a redelivered report for the same order. If a cancelled registration appears active again and no one reactivated it, check whether its order was recently reprocessed.
Tip
Fulfilment runs in the background after an order is reported paid, so a registration's status can take a short time to catch up. A checkout screen that shows a "just a moment" message for a few minutes, or a registration that briefly shows Draft right after payment, usually means fulfilment is still working. In a group order, one person's registration can finish fulfilling before another's. The registration can also take a short time to appear in Registration 360, attendee lists, and event queries after the order is placed. Give it a little time and check again instead of resubmitting. If a registration stays in Draft, or stays missing from a report, well beyond a short wait, contact Support.
Rhythm does not check whether the same contact already has another active registration for the event before activating a new one. The self-service registration form does refuse someone who already has an active or pending registration for the event, but that form-level check does not apply when an order is created directly, such as through Console order entry or a shopping cart. Because of that, someone can end up with two active registrations for the same event. If someone is registered twice, whether deliberately or by mistake, Rhythm creates two active registrations instead of blocking the second one. Both registrations count in attendee and registration queries, which can inflate registration counts, revenue, and similar figures. Each registration can also send its own confirmation email, so the same person may appear to have registered, and been charged, twice.
If a paid registration is not showing where you expect it, check it in order. First, check the registration's own status: Active, Pending Approval, or still Draft. Next, check whether a restricted directory is hiding a pending-approval registration. Then confirm the related order shows Completed and paid, not only that the purchaser believes they paid. A group registration can show pending with no invoice or payment created if checkout did not fully go through. When that happens, confirm with the purchaser whether their card was actually charged before asking them to try again. If a registration is stuck in Draft because fulfilment never completed, records that depend on it may not exist yet either, such as an invoice or a confirmation resend. Those actions can fail until the registration is properly activated.
An event registration invoice created by hand, outside the normal registration checkout, does not create an order or a Registration 360 record on its own. The same is true for a registration created manually, or one whose invoice or order was set up through a separate process. Fulfilment is what links a registration to its order, so a registration assembled this way will not automatically show that order's total, amount paid, or balance due. Use the normal registration checkout when you need those figures to populate, or link the registration to its order yourself.
If registration payments are failing for some people at an event but not others, compare a failed attempt with a successful one before assuming the event setup is broken. If a different payment method succeeds, the issue points to that payment method rather than the event.
Even a free registration goes through the same order process. Rhythm relies on order processing to create the registration and trigger integration-related actions such as webinar enrolment. Because of that, a $0.00 registration still needs to complete the normal checkout in both the Portal and the Console instead of skipping straight to a result. You also cannot remove the payment-oriented step from an order-based registration flow as a configuration choice. Doing that would require a fundamental change to how order processing works, so it is not something you can turn off.
A fully discounted checkout, such as a group registration order covered entirely by a 100% coupon, can finish before the attendee registration records and status indicators are visible. Fulfilment runs asynchronously, so give it a moment before concluding that a completed checkout did not register anyone.
Fulfilment is not limited to orders that started from the registration form. If staff sell an event ticket or add-on for someone through Orders instead of through registration, fulfilling that order still creates a registration for them. Rhythm uses the order's contact, sessions, function tickets, and add-ons, so the buyer appears on the event's registration and ticket lists just like a self-service registrant.
What Gets Set Up Automatically
Rhythm sets up everything below from the same order at the same fulfilment moment, with no separate staff step:
- Guests. Each guest named on the order gets their own guest registration, linked back to the registrant's registration. Rhythm takes the guest's name from the order at that moment. If you later correct the spelling on the guest's own contact record, the name already stored on that order does not update, so check guest names before checkout. A guest registration that is still in Draft, because the checkout that would have created it never fully completed, may not show its fee yet in a report that totals paid amounts.
- Contacts for guests. By default, Rhythm creates a contact record in your Rolodex for each new guest. If the registration type's process is set not to save guests as contacts, Rhythm registers them without creating contact records. That guest becomes a transient guest registration that stays linked to the registrant's own contact, so the guest's row shows the registrant's contact details instead of its own. This option belongs to the registration type's process, not the event settings or the registration itself. Because of this, reporting can break out a guest's payment separately only when that guest has a contact-linked registration of their own. When guest contacts are turned off, the guest's amount stays combined with the registrant's.
Warning
A condition offered in some criteria and automations, "Is Guest Registration," is true only when the registration record being checked is itself a guest registration. It cannot tell you whether a registrant brought guests, because Rhythm does not allow someone to register directly as a guest outside that flow.
- Sessions. Rhythm books every session the registrant chose and paid for as a session registration, which puts them on that session's attendee list. Rhythm checks session capacity earlier, when the order is placed, and does not check it again during fulfilment.
- Function tickets. Rhythm issues each function ticket from the order to the registrant, including any meal or other choice they made for it.
- The deadline tier. Rhythm records the registration deadline tier that was in effect when the order was fulfilled. The price is set when the order is placed, while the deadline tier is recorded later at fulfilment. If payment arrives after a deadline passes, the price and deadline tier can point to different tiers.
- The group's organization. Rhythm stamps a group member's registration with the group's organization, so the registration and badge show that organization instead of staying blank. If the registration already names an organization, Rhythm keeps it.
- Course enrolment and credits. When the event is configured for it, Rhythm enrolls a registrant in the certification courses their registration paid for. Turning course registration on after people have already paid does not add courses to registrations that completed before the change. If people paid for course-linked registrations before the setting was in place, identify them with a query and either add them to the course offering by hand or create $0 orders to generate the missing course registrations. Eligible registrants receive certification credits at registration instead of waiting for event attendance. Credits are awarded only to eligible registration types, and guests never receive credits.
- Memberships. If a registration form lets someone join or renew a membership while they register, Rhythm adds that membership package to the order. The Membership application creates or renews the membership once the order is paid; Events fulfilment does not act on that line itself. This works when the membership is sold as its own line item on the order. A membership configured as a bundled, inline product inside the registration package instead of its own line does not activate this way, so sell it as a regular line item if you need it to take effect.
- A webinar join link. If the event's settings enable a webinar integration, Rhythm enrolls a virtual attendee in the event's webinar or meeting and gives them a personal join link. Guests are not enrolled in the webinar this way.
Because fulfilment creates these linked records automatically, plan test registrations and orders with that in mind. Once an event has real registrations, guests, or other dependent records attached, removing them again is not always straightforward.
Confirmation Emails
Rhythm sends a confirmation after fulfilment when the registration type's process has confirmation switched on, includes an email template, and the registrant's contact has an email address. Sending also depends on an account-wide setting. If Successful Order Confirmation Email is turned off under Setup › Settings in Orders and Inventory, registration orders stop sending confirmation emails no matter how the registration process is configured. Turning that setting back on restores them. The checkbox to send the order's own confirmation at checkout is separate from whether the registration completes. Leaving it unchecked can stop the order's own confirmation from going out, but it does not stop the order from processing or the registration from becoming active. The registration's own confirmation can still go out based on its own settings.
The confirmation lists everything that contact bought for the event, including other sessions or function tickets purchased in the same order. Rhythm lists items by contact and event, not by order line. If the registrant later asks staff to resend the confirmation, the registration's own process supplies the template, even though the type's process supplied it the first time.
Confirmations depend on the registration reaching an active state, not strictly on the order balance being paid in full. A registration activated while a balance is still owed can still receive its confirmation because fulfilment triggers the email, not the balance reaching zero. The sequence depends on when payment happens. When someone pays while registering, the order's own Successful Order Confirmation email also works as their payment receipt, and they separately receive the confirmation configured on the registration process. When payment is deferred, such as by choosing Pay Later, the registrant receives the order confirmation, an invoice email, and the registration process's confirmation up front, while the order itself stays pending or awaiting payment. A separate payment receipt follows once the balance is actually paid.
Because several kinds of email can go out around one registration, it helps to know which is which. Depending on how payment happens and what is enabled, a buyer may see the order's own confirmation from Commerce, the registration's own confirmation described here, an invoice or payment receipt for what is owed, and, if the order is later cancelled, a refund receipt. These are separate messages controlled by separate settings, so more than one message about the same purchase is expected and does not mean something duplicated.
When you build or edit the confirmation template, a few merge fields need care. Use registration.order_currency_code (in the merge field picker under All, labeled Order Currency Code) to show the currency the registration was paid in. To list the functions someone purchased, loop over registration.functions and output each item's name field inside the loop. {{order.total}} shows the full amount paid on the order, including any guest registrations included in it. A registration-scoped amount field reflects only that registrant's own share, so the two are not interchangeable once guests are involved.
Warning
Do not add a webinar join link merge field to the Rhythm confirmation email. Zoom sends the join link separately, so Rhythm's own confirmation should not try to duplicate it. Also check the Order Amount Paid merge field in preview before relying on it: it does not always render with two decimal places, so a paid amount can display as 75.5 instead of 75.50.
Event times in the confirmation are converted for the time zone of the person reading it. A recipient in a different time zone from the event can see a different clock time than a colleague reading the same email from the event's own time zone. If a registrant asks why the time in their confirmation looks wrong, check which time zone they were reading it in before assuming the email is wrong.
Group Registrations
Group registrations add two more settings that are easy to mix up:
- Each individual registrant's confirmation can be sent to the registrant only, or to both the registrant and the group administrator. When it is sent to both, the group administrator receives a copy of each individual registrant's own confirmation, not one combined confirmation. Those copies land in the group administrator's inbox, but they may not appear on the group administrator's own CRM Email tab. Check the inbox itself rather than relying on that tab to confirm delivery.
- A separate group registration confirmation, a one-time summary of the whole group purchase, can be sent to the group administrator on its own, as long as the group has an administrator with a contact record.
These two settings are independent. Turning off the individual registration confirmation for registrants only stops that email for the registrants themselves. The group administrator still receives the group confirmation enabled at the process level, even when individual confirmations are switched off. If you expect the group administrator to stop receiving messages about a registration entirely, check both settings, not just the one for individual registrants. The group administrator can also still receive the order's own confirmation from Commerce, even when the registration confirmation setting excludes them.
Delivery to a copied recipient does not always succeed even when the registrant's own copy arrives. If a group administrator or another copied recipient reports not receiving a confirmation that the registrant did get, treat it as a delivery problem for that recipient rather than a sign that the registration itself has a problem.
flowchart LR
A[Order paid] --> B{Fulfilment}
B --> C[Registration activated<br/>or held for approval]
C --> D[Guests, sessions,<br/>tickets, credits set up]
D --> E[Confirmation email<br/>sent per process settings]