Understand ticket purchase and activation
A configured ticket option, a purchaser's pass and an attendee's assignment are different records. The publication's integration provides the purchase and recipient experience; Admin setup alone does not install it.
For City Journal's reader evening, Alex purchases a pass intended for Morgan. Alex owns the pass; Morgan becomes its assigned attendee through the configured assignment or invitation flow. Alex's ownership does not automatically assign Alex or Morgan.
Follow the record, not just the payment
| Stage | What happens | What remains separate |
|---|---|---|
| Ticket configuration | The publication saves the event and ticket definition. | Website integration and successful purchase. |
| Purchase processing | The supported successful-status path creates a pass owned by the purchaser, initially without an attendee assignment. | Completion of all record writes, notifications and attendee assignment. |
| Direct assignment | The owner uses the configured flow to assign an existing publication reader. | Invitation activation; this is a different path. |
| Invitation | The owner creates an invitation for the intended email recipient; Wallkit stores its code and attempts the configured notification event. | Message delivery and the recipient's acceptance. |
| Invitation activation | The intended signed-in reader supplies the invitation code; the flow attempts assignment of the existing pass and marks the invitation activated. | New pass creation, issuance of a sign-in link and physical admission. |
A stored pass is not a receipt. Passes can also be attached through publisher actions, and payment success does not guarantee that every later write or notification completed. Inspect the actual transaction and pass record separately.
Understand recipient requirements
The invitation path requires the intended recipient's active member context for this publication and the supplied invitation code. It checks the code against the signed-in account's email, the resource and the existing unassigned pass. That account-email match is not independent proof of who controls an email inbox.
An already activated invitation or already assigned pass is rejected by this path. Do not treat a code as reusable for another attendee. A notification attempt does not establish delivery; ask the integration owner to inspect the configured flow when an invitation is missing.
Subscription attachment and mailing tags can be attempted where configured, with their own conditions. Invitation activation alone is not proof of a completed membership update, delivered message or article access.
Keep Magic links separate from invitation codes
A Magic link is a private sign-in credential for an assigned reader, when a token and event URL are available. It is different from an invitation code and is not a scanned entry ticket. Invitation activation does not itself generate this credential.
For this sign-in flow, the current authorization check rejects a pass when its event ends less than 24 hours after the link is used. Do not assume the link works until the event ends or is consumed after one use. A successful sign-in is still separate from the event-access decision and physical attendance.
Keep these credentials private. For technical integration work, share Event tickets activation and passes with the implementation owner.
Check access and admission separately
The supported event-access decision looks for an assignment to the selected publication's active event. It does not establish every schedule or pass-state condition, article access or a door check-in.
Use Find and understand tickets and passes to investigate the saved state. Confirm physical admission through the publication's agreed event process; the fields described here do not establish that someone attended.