Define central-purchase workflow and fulfillment #15
Labels
No labels
needs-info
needs-triage
ready-for-agent
ready-for-human
wayfinder:grilling
wayfinder:map
wayfinder:prototype
wayfinder:research
wayfinder:task
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
#5 Define ticket-request allocation and fulfillment
MISChaufen/prevouch
#6 Choose successor routing and incoming-voucher trust rules
MISChaufen/prevouch
#10 Define administrator authority, queue visibility, and event lifecycle
MISChaufen/prevouch
#16 Define upfront-payment tracking and refunds for central purchases
MISChaufen/prevouch
Reference
MISChaufen/prevouch#15
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Part of #1
Question
How should prevouch support an Orga-team buying tickets on behalf of participants, alongside the existing self-purchase mode?
The central-purchase option is required. Participants never receive the vouchers in this mode: the Orga-team uses them to buy tickets for participants. Participants pay upfront to the designated bank account, and unused funds must be returnable when tickets cannot be bought. Whether the application merely tracks those bank operations or initiates them remains a decision, not an existing authorization to move money.
Decide whether purchase mode is configured per event or per request, whether an event can mix modes, and whether or when a request can switch modes. Define the participant, purchaser, and companion relationships and which names or seller-required information the Orga-team needs.
Work through reserving a voucher for a funded request, exposing it only to the Orga-team, claiming a purchase so two organizers cannot buy the same request, recording the seller order, and delivering or making the bought ticket available to the participant. Decide which parts are human actions and which are application assistance; do not assume automated checkout.
Settle what fulfills a centrally purchased request and which evidence supports it. Voucher email delivery to a participant fulfills the previously discussed self-purchase mode only; it cannot fulfill central purchase. Keep upfront payment, seller order/payment, voucher use, ticket delivery, and successor arrival as distinct facts. Decide the return-address instructions and responsibilities for an organizer purchasing through the external seller.
Cover multiple organizers, +n purchases, partial group success, failed purchases, and a voucher becoming unusable between reservation and checkout. Define the purchase outcomes Define upfront-payment tracking and refunds for central purchases needs, without deciding reconciliation and refund rules here. The composite request state model remains in Define ticket-request allocation and fulfillment, and detailed failure/recovery procedures remain in their existing decision.
Resolution: an agreed central-purchase workflow, fulfillment evidence, and worked examples. No real purchase or bank operation is part of resolving this planning ticket.
Planning checkpoint — central-purchase questions Q26–Q29
The human agreed to all four recommendations. This records inputs to the open central-purchase decision, not a final resolution.
The prior allocation contract remains in force: organizer-controlled start, automatic assignments afterward in the established order, no voucher codes for central-purchase members, and the permanent allocation-policy lock at the first successful voucher send or central ticket purchase. Funding eligibility and financial consequences remain in Define upfront-payment tracking and refunds for central purchases.
Still to settle here: purchase-mode changes, organizer claims and checkout handovers, required participant information, purchase evidence, how tickets become available, partial purchases, and the outcomes consumed by funding and recovery decisions. The glossary now records the agreed requester, companion, event-wide purchase mode, and central fulfillment terms.
Planning checkpoint — central-purchase questions Q30–Q33
This records the human's revisions and agreements. The central-purchase decision remains open.
The seller-direct ticket workflow is a product requirement, not a new assertion that any particular seller supports separate ticket and replication addresses. Seller-specific support and successor routing remain with Obtain redacted evidence of successor-address routing and Choose successor routing and incoming-voucher trust rules.
The glossary now distinguishes requester, companion, ticket holder, ticket email address, return address, and purchase claim. Remaining central-purchase questions include safe mode changes, purchase and ticket-access evidence, organizer handovers, partial outcomes, and the facts supplied to funding and recovery decisions.
Planning checkpoint — central-purchase questions Q34–Q37
The human agreed to all four recommendations. This records further inputs to the open central-purchase decision.
The glossary now records purchase handover and sharpens central fulfillment to the agreed seller-confirmed sending evidence. Remaining boundaries are the exact first-purchase milestone when seller payment is pending, handling a purchase awaiting seller payment, and the purchase record needed by the funding and recovery decisions. These do not decide bank reconciliation, refund execution, or recovery deadlines.
Planning checkpoint — central-purchase questions Q38–Q40
The human agreed to all three recommendations. The consolidated contract and worked examples will receive a final shared-understanding check before resolution.
The glossary now defines seller order as the binding purchase commitment, distinct from seller payment, direct ticket-access delivery, upfront bank receipt, and successor arrival.
Resolution — central-purchase workflow and fulfillment
The human confirmed this complete contract and its worked examples in Q41, after agreeing to and revising Q26–Q40. This resolution supersedes the earlier checkpoint proposals for freezing purchase mode at the first request and providing purchased tickets through private prevouch downloads.
Event purchase mode and its lock
Each event has exactly one purchase mode: self-purchase or central purchase. Different events may choose differently; requests within an event do not mix modes.
Purchase mode may change until the first ticket has been bought. Here, "bought" means that the seller has accepted a binding ticket order, even if payment or ticket delivery is still pending. That first purchase commitment permanently fixes the purchase mode.
Before a permitted change, pause allocation and establish outstanding outcomes. Resolve active or uncertain checkouts and safely recover disclosed vouchers before switching. An unrecorded purchase must not be assumed absent, including after a self-purchase voucher was sent. Existing upfront funds and their financial consequences are handled by the funding decision, not silently discarded or reclassified by changing mode.
This is distinct from the allocation-policy lock in Define allocation policies and organizer-triggered shuffling. That policy locks at the first successful voucher send in self-purchase, or the first central ticket purchase. The binding-order milestone above makes the latter precise. A purchase-mode change does not authorize a new shuffle or override an already locked allocation policy.
Requester, companion, and ticket holder
A requester manages their own and +n companion requests. Self +n creates n+1 requests. Companions need no separate prevouch account.
Collect seller-required names, ticket details, and the intended holder's ticket email address when requests are submitted. Require complete information before checkout starts. Corrections are allowed beforehand; changes after checkout starts go through the purchasing organizer. A companion can be the ticket holder even though another person manages the request.
Allocation and organizer purchasing
The event retains its organizer-controlled distribution start and established allocation policy. Afterwards, prevouch automatically assigns usable vouchers to eligible requests in the established order. Funding eligibility is supplied by Define upfront-payment tracking and refunds for central purchases; this decision does not decide how unpaid or partially paid requests behave.
Central purchase is assisted manual purchasing. Organizers complete checkout on the external seller's website. prevouch coordinates voucher assignments and exclusive purchase claims, provides the necessary request and address information, and records outcomes. Multiple requests can be assigned concurrently, including requests from the same requester and an initial batch of eight vouchers.
An organizer must exclusively claim a request and its assigned voucher before revealing the voucher code or starting checkout. Other organizers see the claim owner and progress. A request or voucher cannot be purchased simultaneously by two organizers. Central-purchase members never receive voucher codes.
Before code disclosure, a claim may be cleanly released. After disclosure or checkout starts, transferring responsibility requires an explicit handover containing the current seller status. Uncertain outcomes remain held for recovery. A timeout alone does not authorize releasing the reservation or making a replacement purchase.
Seller-direct ticket access and successor routing
During checkout, the organizer supplies the ticket holder's email address for ticket access. The seller sends ticket-access email directly to that holder, including for companion tickets. Purchased-ticket uploads, private prevouch ticket downloads, and requester redistribution of companion tickets are not the selected workflow.
The organizer separately supplies the prevouch-owned return address for successor/replication emails. Ticket access goes to the ticket holder; successor vouchers return to prevouch and enter the event's common usable stock under the established allocation policy. Successors are not reserved for the person whose purchase produced them.
Separate ticket and successor routing is a product requirement. Exact seller fields, their behavior, and controlled inbound routing remain to be validated by the existing routing decisions; this resolution does not assert that a particular seller configuration has already been verified.
Commitment, seller payment, and fulfillment
Keep these facts distinct: upfront bank receipt, exclusive assignment and claim, accepted binding seller order, seller payment, ticket-access sending, and successor arrival.
Seller-confirmed sending is the agreed central-purchase evidence. The separate self-purchase fulfillment rule remains recipient-mail-server acceptance of the voucher email. Neither mode's fulfillment nor a successor's arrival guarantees admission. A later delivery failure is a recovery input, not permission to buy another ticket automatically.
Purchase records and partial outcomes
Retain linked requests and vouchers, ticket holders, responsible organizers, seller order references, actual prices and currency, payment and delivery states, and a history of confirmations and corrections. One seller order may cover several requests, with outcomes recorded individually.
If only some of a requester's tickets are bought, preserve those purchases. Each remaining request keeps its actual failed, uncertain, or waiting outcome. Grouped allocation preserves the established group turn; it does not guarantee sufficient stock to purchase the whole group, and partial success is not rolled back.
These records supply the purchase commitments, seller spending, and unserved demand needed by the funding decision. They do not themselves choose balance calculations, fee allocation, refund rules, bank reconciliation, or bank-transfer execution.
Worked examples
Remaining decision ownership
No additional independent ticket is needed for this resolution: the existing decisions cover the remaining work. The shared terms are recorded in the root GLOSSARY.md. No real purchase or bank operation was performed.