Ticketing Pass Center and the customer Wallet serve related but different purposes. Ticketing owns admission/pass rights; Loyalty owns points/rewards; Add-ons owns purchased uses. Wallet delivers and displays these source records.
Operator Pass Center
At /app/[orgSlug]/ticketing/passes, inspect configured products and issued
passes. Open a pass to see its status/history and perform an eligible governed
transfer, revocation or redemption against a selected Event. Transfers and
revocations capture a reason. Admission still checks current Event and pass
eligibility; a durable pass cannot admit to a non-live Event.
Customer Wallet workflow
- Open a ticket, Loyalty or add-on Wallet link. Contextual links already identify
the business; generic
/walletentry asks the customer to find a recognisable business/venue name. - Verify the email for that business through the purpose-bound verification flow. A normal staff sign-in is not a substitute for this holder authority.
- Browse the linked credentials and open one for its live state, terms, reference and permitted service action.
- Choose Add to Apple Wallet or Add to Google Wallet if that credential's issuer and channel are ready. The Web Wallet remains the fallback.
- Linking another business repeats verification and is independently reversible.
Matching email addresses never auto-link other organisations. Wallet grouping does not merge customer records, consent, balances, sellers or ticket purchasers. A current eligible save bundle can group two to four issued Ticketing/Loyalty credentials; unavailable items remain named and ready items stay individually saveable. Add-on vouchers are Web-only in the current implementation.
Issuer settings and provider behaviour
Settings → Wallet passes publishes Apple/Google channel choices and branding
for an exact Legal Entity, Brand and Site scope under
credentials.issuer.configure. Source ownership, provider configuration,
projection/history activation and device save are separate prerequisites.
Site publication does not enable organisation-scoped Loyalty credentials.
Existing credentials retain their frozen issuer version.
A provider pass is a projection. Refund, transfer, check-in, cancellation, redemption and expiry remain source-authorised server operations. Inactive credentials lose their usable barcode; delayed Apple/Google updates cannot restore rights. A provider outage can delay native delivery/update without changing Soupy's live source state.
The first issuer-administrator setup uses explicit scope-bound consent and
independent platform approval through People & access. It is not a general
self-service grant. Existing-organisation history checking/preparation/activation
has separate domain_events.replay authority; publishing branding does not
activate held source migrations or retrofit existing passes.