Transfer the ticket and keep the original order
Transfer one event admission to a new guest, verify its usable credential, and preserve the original purchaser and payment record.
CharityStack
·4 min read
A nonprofit event ticket transfer should give the new guest one usable admission while preserving the original purchase record. Verify who requested the change, update the intended ticket, and confirm which admission credential the new guest should use. Do not rewrite the payment history just because a different person will attend.
This decision starts after the ticket has been issued. Collecting the first attendee's information and transferring their place later are different jobs.
Define what the transfer changes
Before offering transfers, choose the deadline, eligible ticket types, and process your team can support. State whether the original buyer must request the change or whether the named attendee can do it. Use the platform's supported ownership checks; a forwarded screenshot should not be your only evidence of authority.
Givebutter's sold-ticket guidance documents administrator reassignment to a new ticket holder. It says the reassigned ticket carries the new holder's details while purchase date and other information remain the same. That is one implementation, so inspect how your own system handles reassignment and delivery.
Keep three facts separate: who bought the order, who currently holds the admission, and which ticket the door team should accept. The original buyer-versus-attendee distinction still applies after the guest changes.
Change the specific ticket
Find the ticket through its stable identifier and check the event, date, and ticket type. If the buyer purchased several places, identify the one being transferred. Avoid changing every guest on an order because one attendee can no longer come.
Capture the new guest's name and appropriate contact details, then use the supported reassignment workflow. Ask for any event information that genuinely needs updating, such as a meal selection or seating request. Do not copy the original guest's personal requirements to someone else by default.
Keep a short record of the request, previous holder, new holder, time of change, and staff member who handled it. This is a proposed operating trail; it does not imply your platform provides each field automatically.
Reassignment should not create a second paid order. If the system requires replacing a ticket, connect the replacement to the original admission and document what happened to the former credential.
Verify the admission credential
Check whether the system changes the barcode, keeps the same identifier with a new holder, or invalidates and replaces the ticket. Do not promise a new code unless your platform actually issues one.
The operating requirement is one valid admission for the transferred place. If an old credential remains usable, establish how the door team will recognize the current holder and prevent a second entry. If your setup cannot resolve competing credentials, complete the transfer with the ticketing provider before confirming it to the guests.
Givebutter's guidance distinguishes revoking a ticket from refunding a purchase: revocation invalidates the ticket but does not automatically issue a refund. Use that distinction when you inspect your own workflow. Admission changes and money movement need separate confirmation.
Check related event arrangements
Update the current guest on the seating list, table allocation, and any event-specific handoff that uses attendee details. Preserve the original purchaser for questions about the order. Apply your existing refund policy to the purchase rather than inventing a new refund recipient during a transfer.
Make delivery part of the transfer's completion check. A correctly edited record does not help the guest if they cannot access the usable ticket. Verify the destination and which ticket version they should bring without distributing the original buyer's entire order.
Use your event check-in test to confirm the changed ticket appears under the current guest and that a duplicate admission attempt is handled as expected. Run this with test records before you publish transfer instructions.
Set a cutoff the team can operate
Near the event, seat assignments and door lists may already be distributed. Set a transfer cutoff based on how quickly your team can refresh those materials, and give late requests one clearly named contact.
For a late approved change, record which lists were updated and who at the door knows about it. Do not depend on a volunteer discovering the request in an inbox while a guest waits.
A transfer is complete when the current holder, valid admission, and related event lists agree. Close that loop while the original order still tells the truth about who paid.