Purchases and Refunds

This guide is for both members and hub admins.

Purchase Ledger Basics

Use Purchase History for canonical order records.

Each order shows:

• Source (Paid, Free, Comp),
• Lifecycle state (Completed, Failed, Expired, Partially refunded, Refunded),
• Ownership outcomes per ticket,
• Gross/refunded/net totals.

Designated Member Purchases

When one person pays and designates tickets to others:

• Order remains linked to original payer,
• Holder and payer are tracked separately,
• Refunds return to original payer,
• Designated-at-purchase tickets stay refundable from that original purchase when otherwise eligible,
• If one of those tickets is later transferred after checkout, it must be transferred back before a self-serve refund can be requested,
• Order can be partial if some ticket lines are ineligible.

Refund Types

Baseline Ticket Refund Policy

Tickets are for a specific date, so the usual 14-day online cooling-off right does not apply.

• If you change your mind, can no longer attend, or bought the wrong ticket, Hubbaly does not guarantee a refund.
• The organiser can still choose to issue a refund where their event policy allows it.
• If the organiser cancels the event, moves it, reschedules it, or materially changes it, direct refund handling follows the organiser’s obligations, Hubbaly’s platform rules, and payment-provider requirements.
• Optional ticket returns are separate from refund obligations. They only apply where the event has enabled them for that ticket type.

Single-ticket refund

• Admin refunds a specific eligible ticket.
• Works for designated-holder tickets when eligible.
• Order may become Partially refunded.
• Under the standard paid-ticket policy, the buyer gets back the ticket amount minus the retained Hubbaly fee and retained Stripe processing fee shown in the breakdown.

Whole-order refund

• Admin can run whole-order refund when all active tickets are eligible.
• If some tickets are blocked, action becomes eligible-only partial refund.

Full refund override (organiser absorbs fees)

• Event admins can choose a fuller refund path for eligible paid tickets or orders.
• The buyer gets back the full buyer-paid amount.
• Hubbaly still keeps the platform fee in platform accounting, and the organiser absorbs the retained Hubbaly fee plus Stripe processing from their own economics.
• This is an override, not the default standard refund path.

Moderation-Driven Ticket Outcomes

Some ticket changes come from a moderator decision rather than a normal attendee refund request.

• When a moderator applies an event or hub ban, they choose the outcome for each affected active ticket.
• INVALIDATE_REFUND means access is removed and the ticket is refunded through the normal refund path.
• INVALIDATE_NO_REFUND means access is removed without sending money back.
• Hubbaly does not automatically refund every banned ticket by default; the moderator makes that call explicitly.
• Purchase History remains the ledger for refunded, partially refunded, and voided outcomes, and Safety holds the related moderation history.

Ticket Returns and Released Tickets

Some events use ticket returns as an optional Hubbaly feature for eligible paid tickets. You can request a return before a ticket type is sold out; the queue protects normal ticket availability and waits for a replacement buyer. It is not an automatic legal refund right and it is not a promise that your place will be filled.

What ticket holders should expect

1. Open the order in Purchase History. If you start from a live ticket page, use its shortcut back to the matching purchase row.
2. Check both sections before confirming:
   • Tickets and returns shows the exact original paid amount, retained Hubbaly fee, retained Stripe processing fee, and Refund if your place is filled per ticket.
   • Blocked tickets shows anything that cannot join right now, such as a pending transfer.
3. Confirm with Request ticket return, Request holder approval, or Request returns and approvals depending on the tickets in the order.
4. Tickets the purchaser still holds enter the Ticket Return Queue immediately. Their original ticket is locked from transfer/check-in while queued.
5. Tickets currently held by someone else because they were assigned at checkout first ask that holder to approve the return. The holder gets an in-app notification and email, and their pass stays valid while they decide.
6. If the holder approves, Hubbaly can release the place and the pass can stop working if a replacement buyer completes checkout. If the holder keeps the ticket, declines, or transfers it before approving, nothing is released and no refund is created.
7. The platform tries waitlist-first, then public fallback:
   • If a waitlist offer exists, it is time-limited.
   • The released-ticket email/notification tells that buyer they are next in line and includes the exact Purchase by deadline.
   • The release email and waitlist management page can also offer Pass to next person when the buyer does not want the held tickets.
   • If that buyer passes or misses the deadline, Hubbaly offers the slot to the next eligible waitlist buyer before public fallback.
   • When that window closes, the earlier buyer is told the hold ended and gets a rejoin link.
8. Your refund is processed only after a replacement purchase succeeds.
9. Hubbaly fee and Stripe processing are both retained in the standard ticket return settlement. Your refund if your place is filled equals the original buyer-paid amount minus both fees - the exact figure is shown next to the ticket before you request a return or approval.
10. If no replacement purchase happens before event start, the request expires and no refund is made. This is distinct from the event being cancelled by the organiser (see below).

Ticket eligibility

• Only paid tickets can enter the Ticket Return Queue. Free comp / invite tickets show no ticket return action.
• Staff-assigned tickets (issued by an event admin outside a purchase) cannot use ticket returns - the assignment is tied to a specific person.
• Tickets the ticket type’s admin has explicitly marked as not eligible for ticket returns never show the return action, regardless of event-level settings.
• The ticket must currently be held by the original purchaser, or have been assigned at purchase and never transferred. If it is still with the designated checkout holder, that holder must approve before Hubbaly releases the place.
• A ticket that’s been accepted by a different holder through a later transfer has to be transferred back before it can enter the Ticket Return Queue.
• New self-serve ticket return requests cannot be started once the event has started. Use organiser/support handling for post-start refund questions, cancellations, postponements, or major event changes.

Who can request a return for a transferred ticket

• The original purchaser is the refund owner. Stripe sends any successful ticket return refund back to the payment method used for the order.
• The current holder is the attendee. Holding a ticket after a transfer does not make that person the refund owner.
• A ticket assigned to another member during checkout can still be requested from the original purchaser’s order when it has never moved again after checkout, but the current holder must approve before Hubbaly releases the place.
• Pending holder approval is not a return request. The ticket stays valid and the holder can keep, use, or transfer it while deciding. If the holder transfers it before approving, Hubbaly cancels that approval request because a different person now holds the ticket.
• If the holder approves, the purchaser sees the request move into the Ticket Return Queue. If the holder declines or the purchaser cancels first, the ticket is unchanged.
• Once a ticket has been accepted through a later transfer, the self-serve path is: transfer it back to the original purchaser, then request the return from the original purchaser’s Purchase History.
• Members plus guests events allow the original purchaser to hold extra guest tickets, so this duplicate-holder rule should not block transfer-back there.
• If a strict members-only event does not allow guest tickets and the original purchaser already holds another active ticket for the same event, Hubbaly can show Transfer back blocked. That means transferring the ticket back would give the purchaser two active tickets in an event that only allows one member-held ticket per person, so organiser/support review is required.

What happens if the event is cancelled, the ticket is transferred out, or the ticket is already refunded

• Event cancelled by the organiser: the Ticket Return Queue is closed immediately. Any queued/held/matched requests stop progressing; Hubbaly does not issue an automatic ticket return refund. The purchase detail surfaces a clear banner and points you at the organiser for a direct refund.
• You transfer the ticket out after requesting a return: the underlying ticket is no longer yours at settlement time. Hubbaly detects this and does not refund the original purchaser. If the replacement purchase already completed, Hubbaly automatically refunds the replacement buyer so nobody keeps money for a phantom sale.
• The ticket is already refunded or voided through another path: the queue request expires and no further refund is made. The status shows alongside the ticket so you can see what happened.

If Stripe settlement fails

• Once the replacement sale is recorded, Hubbaly moves the request into REFUND_PENDING and attempts to push the refund to Stripe. If Stripe reports a temporary failure, the refund retries automatically with backoff (up to five attempts). You’ll see the refund arrive in the Refund completed email without needing to take any action.
• If all retries fail, the request moves to FAILED and surfaces to ops. You can reach out to the organiser or support; the captured error is preserved on the request for investigation.

Mixed eligibility inside one order

• A whole-order ticket return request only queues the tickets that are currently eligible.
• If some eligible tickets need holder approval, Hubbaly queues the purchaser-held tickets and sends approval requests for the holder-held tickets instead of releasing them immediately.
• Blocked tickets stay in the order with the blocker reason shown in the review step.
• A pending transfer blocks that ticket until the transfer is cancelled, accepted, or expires.
• A ticket transferred after purchase stays blocked until it returns to the original purchaser.
• If Hubbaly already knows transfer-back will fail because the original purchaser already holds another active ticket for a strict members-only event that does not allow guest tickets, purchase detail can show Transfer back blocked instead of Transfer back first.
• Transfer-back can fail under strict members-only holder rules, in which case the case moves to organiser/support handling.

Refund emails you may receive

• Refund accepted means Hubbaly accepted the refund action or ticket return processing step and is still working through settlement.
• Refund completed is the final confirmation after money movement finishes.
• Ticket return completion emails include ticket type, original paid amount, retained Hubbaly fee, retained Stripe processing fee, and final refund amount.

Queue position visibility

• While your request is still waiting, Hubbaly shows your Ticket Return Queue position on the purchase detail and ticket detail pages, and the purchase-level summary keeps the active queued positions visible.
• Queue position is per event and ticket type.
• Once a replacement buyer is actively being processed, the status becomes more important than the queue number and the request moves into OFFERED, MATCHED, or later settlement states.

Waitlist offer claim rules

• Member/private contexts: the matching signed-in account must claim the offer.
• Public contexts: waitlist email includes a one-time claim link/token; claim first, then checkout using the short-lived checkout claim token.
• Passing a held slot does not require a pre-existing session; the signed Pass to next person action can hand the slot on directly from the email.
• Offer windows are time-limited; expired or already-used offers return unavailable/invalid outcomes and the prior buyer gets the expiry/rejoin message.

Queue statuses you may see

Blocked Refund Reasons and What To Do

When A New Paid Ticket Shows 0 Hubbaly Fee / 0 Stripe Fee

For organisers, this is a warning sign rather than the normal Connect-ready outcome.

• On recently sold paid tickets, 0 Hubbaly fee / 0 Stripe fee usually means the sale was recorded through legacy routing or while the platform paid-ticket path was incomplete.
• Check Hub -> Admin -> Settings -> Payments first.
• If that card says Connected, rollout not active, Platform setup incomplete, or Needs review, investigate before more paid sales.
• Old event versus new event is not enough to explain this by itself. The hub rollout mode and the checkout path used for that sale matter more.

If Stripe already shows a settled processing fee for a new Connect sale but Hubbaly still shows Stripe processing £0.00, that now indicates stale stored financial snapshots rather than the wrong Stripe route. Opening the purchase detail, ticket detail, or Event Admin sold-ticket view now triggers a settled-fee refresh so those snapshots can repair themselves.

Admin Refund Decision Flow

From Event Admin Tickets:

1. Open Order Refunds.
2. Click Review Refund Scope.
3. Read both sections:
   • Will refund now
   • Not refundable now (+ reasons)
4. Confirm action:
   • Refund Whole Order when fully eligible,
   • Refund Eligible Tickets when partially eligible.

Before confirming, answer these explicitly:

1. What amount is being refunded now?
2. Which tickets are excluded and why?
3. Is this the standard fee-retaining refund or the organiser-absorbed full-refund override?
4. What should the admin do next for excluded items?

Related Guides

• Events and Tickets
• Support Playbooks
• Troubleshooting