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

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.

Queue-First Resell (When Enabled)

Some events use resell instead of direct immediate payout.

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 resell shows the exact original paid amount, retained Hubbaly fee, retained Stripe processing fee, and estimated payout per ticket.
   • Blocked tickets shows anything that cannot join right now, such as a pending transfer.
3. Confirm with Queue all eligible tickets to resell to release every eligible ticket in that order at once.
4. Your original ticket is locked from transfer/check-in while queued.
5. A replacement ticket slot is released immediately.
6. The platform tries waitlist-first, then public fallback:
   • If a waitlist offer exists, it is time-limited.
   • The release 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.
7. Your payout is processed only after replacement sale succeeds.
8. Hubbaly fee and Stripe processing are both retained in the standard resell settlement.
9. If no replacement sale happens before event start, request expires and no payout is made.

Mixed eligibility inside one order

• A whole-order resell request only queues the tickets that are currently eligible.
• 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 under event holder-uniqueness rules, purchase detail can show Transfer back blocked instead of Transfer back first.
• Transfer-back can fail under event holder-uniqueness 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 resell processing step and is still working through settlement.
• Refund completed is the final confirmation after money movement finishes.
• Resell 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 resell 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