Skip to content

Option to have separate email/name for each ticket in the same basket. #61

Open

Description

@G1ne

One user can order multiple tickets or types of tickets and optionally add a different email/name to each and purchase in one go. Basically adding tickets to "basket" with different personalisation for each.

Activity

  1. self-assigned this
    on Jun 26, 2026
  2. dadofsambonzuki commented on Oct 6, 2026

    @dadofsambonzuki

    We've gone the other way in #64 (draft), so being explicit rather than leaving this hanging.

    Basket checkout is one order = one buyer: a single name and email at basket level, and every ticket in the basket carries those details. The buyer gets one email listing all their tickets. We did build per-attendee fields first and then deliberately simplified them away — for the common case (buying several tickets for yourself) a name box per ticket plus a "copy details to all" checkbox was friction with nothing to show for it.

    What that means in practice today: if each attendee needs their own name on their ticket, it's one purchase per attendee. There's also no way to rename a ticket after purchase — the admin table can register, resend, deactivate or delete, but not edit.

    Two ways to close the gap if you need it:

    1. Optional per-ticket override — keep the basket-level name/email as the default and let the buyer expand a ticket to give it its own name/email. Your issue wording ("optionally add a different email/name to each") points this way, and it's the smaller change from where the code is now.
    2. Admin-side per-ticket rename — useful regardless of the checkout decision, since organisers currently can't correct a typo'd attendee name at all.

    Which of these matters for your events? Leaving this open until we know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions