MISChaufen/prevouch
0
0
Fork 0
Code Issues 9 Pull requests Projects Releases Packages Wiki Activity Actions

Define upfront-payment tracking and refunds for central purchases #16

New issue
Closed
opened 2026-10-22 09:09:37 +00:00 by phg · 4 comments
phg commented 2026-10-22 09:09:37 +00:00
Owner
Copy link

Part of #1

Question

How should prevouch track upfront bank payments, determine which central-purchase requests are funded, and account for money to return when tickets cannot be bought?

Required behavior: participants pay upfront to the designated bank account so the Orga-team can buy for them; the application tracks whether they have paid and supports accounting for returning unused money when further tickets cannot be bought. The mechanism for bank reconciliation and for actually making transfers is not yet chosen.

Decide who owes what for self +n requests, how payments are identified and associated with the correct event/person/request group, and what evidence confirms receipt. Choose the intended boundary between manual recording, statement import, and any bank integration; a requirement to track payment does not by itself choose automated transfers.

Settle partial, missing, late, duplicate, overpaid, reversed, or unmatched payments; price differences and fees; and who may confirm or correct records. Define the precise funding-eligibility contract for allocation: whether an unpaid request keeps a place, is temporarily skipped, blocks others, or expires; how payment eligibility interacts with FCFS order or the initial shuffle and fixed subsequent order, including unpaid requests at shuffle time and later payment; and how much funding a group needs before one or several of its requests can be served.

Define how received funds, funds committed to a purchase, seller spending, refundable amounts, and completed refunds relate, using the purchase outcomes from Define central-purchase workflow and fulfillment. Cover exhaustion of ticket/voucher supply, event or participant cancellation, partial fulfillment of +n groups, failed seller purchases, and overpayments.

Decide how a refund becomes due, who approves and executes it, where necessary refund details are held, what evidence marks it sent/completed, and how corrections or retries avoid returning the same money twice. Specify participant-visible balances/status and organizer reconciliation/history without choosing storage technology.

Resolution: an agreed funding and refund state model with worked amounts for fully served, partially served, and unserved participants. Feed eligibility and cancellation consequences into Define ticket-request allocation and fulfillment, and permissions/notifications into their existing decisions. No actual money moves in this planning effort.

Part of #1 ## Question How should prevouch track upfront bank payments, determine which central-purchase requests are funded, and account for money to return when tickets cannot be bought? Required behavior: participants pay upfront to the designated bank account so the Orga-team can buy for them; the application tracks whether they have paid and supports accounting for returning unused money when further tickets cannot be bought. The mechanism for bank reconciliation and for actually making transfers is not yet chosen. Decide who owes what for self +n requests, how payments are identified and associated with the correct event/person/request group, and what evidence confirms receipt. Choose the intended boundary between manual recording, statement import, and any bank integration; a requirement to track payment does not by itself choose automated transfers. Settle partial, missing, late, duplicate, overpaid, reversed, or unmatched payments; price differences and fees; and who may confirm or correct records. Define the precise funding-eligibility contract for allocation: whether an unpaid request keeps a place, is temporarily skipped, blocks others, or expires; how payment eligibility interacts with FCFS order or the initial shuffle and fixed subsequent order, including unpaid requests at shuffle time and later payment; and how much funding a group needs before one or several of its requests can be served. Define how received funds, funds committed to a purchase, seller spending, refundable amounts, and completed refunds relate, using the purchase outcomes from [Define central-purchase workflow and fulfillment](https://git.s1q.dev/MISChaufen/prevouch/issues/15). Cover exhaustion of ticket/voucher supply, event or participant cancellation, partial fulfillment of +n groups, failed seller purchases, and overpayments. Decide how a refund becomes due, who approves and executes it, where necessary refund details are held, what evidence marks it sent/completed, and how corrections or retries avoid returning the same money twice. Specify participant-visible balances/status and organizer reconciliation/history without choosing storage technology. Resolution: an agreed funding and refund state model with worked amounts for fully served, partially served, and unserved participants. Feed eligibility and cancellation consequences into [Define ticket-request allocation and fulfillment](https://git.s1q.dev/MISChaufen/prevouch/issues/5), and permissions/notifications into their existing decisions. No actual money moves in this planning effort.
phg self-assigned this 2026-10-22 12:05:16 +00:00
phg commented 2026-10-22 12:25:26 +00:00
Author
Owner
Copy link

Agreed checkpoint: responsibility, banking boundary, prices, and authority

The requester confirmed these choices in the live wayfinder discussion. This is a checkpoint, not the final resolution; funding eligibility, edge cases, and refunds are still being discussed.

  • Responsibility: One requester balance per requester and event covers their own and companion ticket requests. Give it a unique payment reference. Multiple transfers and third-party payers are allowed when an organizer can match the payment.
  • Initial banking boundary: Finance-authorized organizers manually confirm incoming money from bank records and record refunds made through their bank. Store transaction references and correction history. Bank-statement import and direct bank integration are later work.
  • Dynamic ticket tiers: Organizers define the event's ticket tiers, their prices, known seller fees, and required details upfront. Examples requested by the user are Standard, Family & Friends, and CCC e.V. Member Ticket; the latter requires a CCC e.V. member number. These are configurable options, not a fixed built-in list.
  • Agreed amount: State the amount for each requested ticket, including known seller fees. Return unused money. Obtain the requester's agreement and a top-up before buying above the agreed amount. Organizers absorb their own banking and administrative costs.
  • Authority: Use a separate finance permission for confirming and correcting money records and approving refunds. Record the actor, time, and reason for every change. One authorized person can handle a refund; second-person approval is optional.

Next discussion: funding and queue order, partial funding of self +n requests, per-holder tier selection and changes, and refund destination when third parties paid. No decision on these is implied by this checkpoint.

## Agreed checkpoint: responsibility, banking boundary, prices, and authority The requester confirmed these choices in the live wayfinder discussion. This is a checkpoint, not the final resolution; funding eligibility, edge cases, and refunds are still being discussed. - **Responsibility:** One requester balance per requester and event covers their own and companion ticket requests. Give it a unique payment reference. Multiple transfers and third-party payers are allowed when an organizer can match the payment. - **Initial banking boundary:** Finance-authorized organizers manually confirm incoming money from bank records and record refunds made through their bank. Store transaction references and correction history. Bank-statement import and direct bank integration are later work. - **Dynamic ticket tiers:** Organizers define the event's ticket tiers, their prices, known seller fees, and required details upfront. Examples requested by the user are Standard, Family & Friends, and CCC e.V. Member Ticket; the latter requires a CCC e.V. member number. These are configurable options, not a fixed built-in list. - **Agreed amount:** State the amount for each requested ticket, including known seller fees. Return unused money. Obtain the requester's agreement and a top-up before buying above the agreed amount. Organizers absorb their own banking and administrative costs. - **Authority:** Use a separate finance permission for confirming and correcting money records and approving refunds. Record the actor, time, and reason for every change. One authorized person can handle a refund; second-person approval is optional. Next discussion: funding and queue order, partial funding of self +n requests, per-holder tier selection and changes, and refund destination when third parties paid. No decision on these is implied by this checkpoint.
phg commented 2026-10-22 12:50:49 +00:00
Author
Owner
Copy link

Agreed checkpoint: funding eligibility, ticket tiers, and refund destination

The requester confirmed these choices in the live discussion. This supplements the earlier checkpoint; the ticket remains open for the remaining decisions.

  • Unpaid requests retain position: Include unpaid requests in the initial shuffle. Under every allocation policy, preserve their established position but skip them while insufficiently funded. Later confirmed payment restores eligibility at that position without undoing purchases or existing assignments for others. Being unpaid alone does not cause automatic expiry.
  • Fund individual requests: One request needs its full stated amount. A self +n group need not be fully funded before some of its tickets can be bought: three requests at EUR 150 each with EUR 300 received can fund two. Apply available money in the requests' existing allocation order; do not bypass an earlier expensive request to fund a later cheaper one. Reserve funds when a voucher is assigned so concurrent purchases cannot spend the same funds twice.
  • Per-holder ticket tiers: Each ticket holder may select a different organizer-defined tier. Supply all tier-required details before purchase eligibility. Each event uses one currency. Existing tier selections and agreed prices remain unchanged unless the requester explicitly accepts a change.
  • Refund destination: The requester confirms a refund account; someone with finance permission approves it. The original sending account may be suggested, but refunds need not automatically go there when third parties paid. Keep refund details in a private event record visible to the requester and finance staff.

Still to resolve: the exact interaction between restored funding and an already active group turn; when unused funds become refundable; problematic receipts and reversals; changes during purchase; refund execution evidence and retries; and whether organizers need personal-advance reimbursement.

## Agreed checkpoint: funding eligibility, ticket tiers, and refund destination The requester confirmed these choices in the live discussion. This supplements the earlier checkpoint; the ticket remains open for the remaining decisions. - **Unpaid requests retain position:** Include unpaid requests in the initial shuffle. Under every allocation policy, preserve their established position but skip them while insufficiently funded. Later confirmed payment restores eligibility at that position without undoing purchases or existing assignments for others. Being unpaid alone does not cause automatic expiry. - **Fund individual requests:** One request needs its full stated amount. A self +n group need not be fully funded before some of its tickets can be bought: three requests at EUR 150 each with EUR 300 received can fund two. Apply available money in the requests' existing allocation order; do not bypass an earlier expensive request to fund a later cheaper one. Reserve funds when a voucher is assigned so concurrent purchases cannot spend the same funds twice. - **Per-holder ticket tiers:** Each ticket holder may select a different organizer-defined tier. Supply all tier-required details before purchase eligibility. Each event uses one currency. Existing tier selections and agreed prices remain unchanged unless the requester explicitly accepts a change. - **Refund destination:** The requester confirms a refund account; someone with finance permission approves it. The original sending account may be suggested, but refunds need not automatically go there when third parties paid. Keep refund details in a private event record visible to the requester and finance staff. Still to resolve: the exact interaction between restored funding and an already active group turn; when unused funds become refundable; problematic receipts and reversals; changes during purchase; refund execution evidence and retries; and whether organizers need personal-advance reimbursement.
phg commented 2026-10-22 13:16:36 +00:00
Author
Owner
Copy link

Agreed checkpoint: group continuity, refund lifecycle, and exception handling

The requester agreed to each of these proposals in the live discussion. The final accounting presentation and worked examples are being assembled for review before resolution.

  • Group continuity under funding eligibility: A group whose next original request becomes unfunded or otherwise ineligible yields its turn. It retains its original group position. If another group has started a turn when the skipped group becomes eligible again, that active turn continues while its next original request remains eligible. The restored group then precedes later groups. No existing assignment is revoked. A whole group's funds are not required; funding its next request is enough. This explicitly qualifies the continuity rule in Define allocation policies and organizer-triggered shuffling.
  • When refunds become due: Retain funds needed for active requests. Surplus may be requested back. Withdrawal or explicit distribution finalization makes remaining unused funds due. Before a binding order, release a purchase reservation only after confirming checkout cannot still succeed. After a binding order, preserve the commitment until cancellation/recovery establishes actual costs and any seller repayment. Preserve individually successful tickets in partially served groups.
  • Receipt evidence and exceptions: Finance staff credit only verified bank money matched to the correct requester and event. Unmatched and wrong-currency payments await manual resolution. Distinct real transfers all count; recording the same bank transaction twice must not. Late receipts fund active requests or become refundable after finalization. Use linked adjustments instead of overwriting history. A reversal removes uncommitted funding; a deficit affecting held or binding purchases requires finance review and a top-up rather than a fictitious refund.
  • Changes to ticket tiers: No automatic substitution when a tier sells out, costs more, or required details are rejected. An accepted change before assignment preserves position and recalculates funding. An assigned purchase changes only through its responsible organizer after confirming safe checkout status. Binding orders follow seller change/cancellation outcomes. An unresolved tier problem makes the request ineligible without automatically expiring it.
  • Refund execution: Due -> approved -> in progress -> sent. Finance staff mark sent only with bank execution evidence and a transaction reference; recipient acknowledgment is unnecessary for prevouch completion. Approved, in-progress, and uncertain transfers retain their holds. Failed or returned transfers reopen the amount; retries are linked attempts, with no two live transfers for the same refund. Uncertain outcomes require investigation before retry.
  • Seller payment source: The designated account or its payment method funds seller purchases. Personal advances and organizer reimbursements are outside this workflow.
## Agreed checkpoint: group continuity, refund lifecycle, and exception handling The requester agreed to each of these proposals in the live discussion. The final accounting presentation and worked examples are being assembled for review before resolution. - **Group continuity under funding eligibility:** A group whose next original request becomes unfunded or otherwise ineligible yields its turn. It retains its original group position. If another group has started a turn when the skipped group becomes eligible again, that active turn continues while its next original request remains eligible. The restored group then precedes later groups. No existing assignment is revoked. A whole group's funds are not required; funding its next request is enough. This explicitly qualifies the continuity rule in [Define allocation policies and organizer-triggered shuffling](https://git.s1q.dev/MISChaufen/prevouch/issues/14). - **When refunds become due:** Retain funds needed for active requests. Surplus may be requested back. Withdrawal or explicit distribution finalization makes remaining unused funds due. Before a binding order, release a purchase reservation only after confirming checkout cannot still succeed. After a binding order, preserve the commitment until cancellation/recovery establishes actual costs and any seller repayment. Preserve individually successful tickets in partially served groups. - **Receipt evidence and exceptions:** Finance staff credit only verified bank money matched to the correct requester and event. Unmatched and wrong-currency payments await manual resolution. Distinct real transfers all count; recording the same bank transaction twice must not. Late receipts fund active requests or become refundable after finalization. Use linked adjustments instead of overwriting history. A reversal removes uncommitted funding; a deficit affecting held or binding purchases requires finance review and a top-up rather than a fictitious refund. - **Changes to ticket tiers:** No automatic substitution when a tier sells out, costs more, or required details are rejected. An accepted change before assignment preserves position and recalculates funding. An assigned purchase changes only through its responsible organizer after confirming safe checkout status. Binding orders follow seller change/cancellation outcomes. An unresolved tier problem makes the request ineligible without automatically expiring it. - **Refund execution:** Due -> approved -> in progress -> sent. Finance staff mark sent only with bank execution evidence and a transaction reference; recipient acknowledgment is unnecessary for prevouch completion. Approved, in-progress, and uncertain transfers retain their holds. Failed or returned transfers reopen the amount; retries are linked attempts, with no two live transfers for the same refund. Uncertain outcomes require investigation before retry. - **Seller payment source:** The designated account or its payment method funds seller purchases. Personal advances and organizer reimbursements are outside this workflow.
phg commented 2026-10-22 13:26:27 +00:00
Author
Owner
Copy link

Resolution: upfront funding and refunds for central purchase

Agreed with the requester in the live wayfinder discussion, including the accounting model, worked amounts, visibility rules, and confirmation that the decision is complete. This resolution is the canonical decision and supersedes the earlier checkpoints.

Responsibility and ticket tiers

  • Keep one requester balance per requester and event, covering their own and all companion ticket requests. Companions need no separate balance or account. Several transfers and identifiable third-party payers are allowed. Each event uses one currency; balances do not fund another requester or event.
  • Give each requester balance a unique payment reference and display the designated account, event currency, required amount, and reference in payment instructions. No receipt is established by a participant saying they paid.
  • Organizers define dynamic ticket tiers, their prices including known seller fees, and tier-required holder details before participants select and pay. Examples are Standard, Family & Friends, and CCC e.V. Member Ticket requiring a CCC e.V. member number. These are configurable examples, not built-in products. Each holder can select a different tier.
  • Preserve each request's accepted tier and agreed amount. Organizer edits do not silently change existing requests. Require requester acceptance and enough additional confirmed funding before buying above that amount. Lower actual costs remain in the requester balance. Organizers absorb their own banking and administrative costs.
  • Before assignment, an accepted tier change preserves the request's position and recalculates required funding. After assignment, the responsible organizer establishes a safe checkout state before changing or releasing anything. Binding orders follow their actual seller change/cancellation outcome. No automatic tier substitution. Missing or rejected required details make the affected request ineligible without automatic expiry.

Manual bank records and authority

  • Initial scope is manual reconciliation and manual external bank transfers. Someone with separate finance permission verifies bank evidence, matches money to the requester/event, and confirms or corrects receipts and refund records. Do not build statement import, direct bank integration, personal advances, or organizer reimbursement into this workflow. Seller purchases use the designated account or its payment method.
  • Record transaction identity/reference, amount, currency, bank evidence, matching target, actor, time, and reason. A bank transaction must not be credited twice, including across requester balances. Multiple distinct real transfers all count. Use linked corrections/reversals; retain the original history.
  • Unmatched or wrong-currency money stays outside spendable requester credit until manually resolved. Do not guess a match or perform implicit currency conversion. Recording bank facts and changing a purchase/fulfillment outcome are distinct actions with their own evidence.
  • Missing/partial payment leaves demand waiting. Late confirmed money funds still-active demand under its existing order; money arriving after withdrawal/finalization becomes refundable, not a new queue entry. A reversed receipt removes available funding. A deficit affecting reservations or binding purchases requires finance review and a top-up; it does not create a negative refund or erase a seller obligation.
  • One finance-authorized person can approve and record a refund; second-person approval is optional. Keep requester-confirmed, finance-approved refund details privately for the event, visible to that requester and finance staff. Suggest the original sending account without assuming a third-party payer is the intended refund recipient. A changed destination invalidates the old approval before execution; an uncertain attempt retains its recorded destination until resolved.

Funding eligibility and queue order

  • Upfront receipt, funding eligibility, voucher assignment, organizer purchase claim, binding seller order, seller payment, seller-confirmed sending of ticket access, and refund are separate facts. A funded or assigned request is not yet a purchased/fulfilled ticket. Preserve the fulfillment contract in Define central-purchase workflow and fulfillment.
  • Include unpaid requests in the initial shuffle. FCFS and both shuffled modes preserve their established order while temporarily skipping ineligible requests. A request needs its full agreed amount and all required holder/tier details before purchase eligibility. Being unpaid or lacking details does not by itself expire the request. Confirmed funding or corrected details restore eligibility at the existing position, never revoking an existing assignment or purchase for someone else.
  • Fund individual requests in their existing allocation order, not whole self +n groups. Within one requester balance, an earlier unfunded expensive request cannot be bypassed to fund a cheaper later request. Retain partial money toward that earlier request. In shuffled modes, establish the actual order at the initial shuffle before determining the funded prefix; pre-shuffle totals do not promise a particular holder's place.
  • Reserve the full agreed amount at voucher assignment, alongside the request/voucher reservation, before another assignment or refund can consume it. Existing reservations/commitments take priority over funding additional waiting requests. Multiple usable vouchers and organizers cannot spend the same money twice. Funding changes trigger eligibility reevaluation, but automatic allocation still requires distribution to have started.
  • In Shuffled (grouped), the active group continues while its next original request is eligible. If that request becomes unfunded or otherwise ineligible, skip the group rather than blocking others or bypassing its next member. The skipped group retains its original group position. If it becomes eligible while another group has an active turn, finish that active turn while its next original request remains eligible; then resume the earlier group ahead of later groups. Later additions never extend a turn. This explicitly qualifies group continuity in Define allocation policies and organizer-triggered shuffling.

Accounting model

Use amounts in the event currency at that currency's monetary precision. These are domain balances and transitions, not a storage-technology choice.

  • Net receipts: confirmed upfront money minus reversed/returned incoming payments, as amended by linked corrections.
  • Net seller spending: confirmed seller payments minus seller repayments actually received and confirmed. Expected seller refunds do not count as cash.
  • Net refunds sent: bank-confirmed participant refunds minus transfers confirmed failed/returned after being recorded as sent. Reopening a refund must account for returned cash exactly once.
  • Held balance = net receipts - net seller spending - net refunds sent. It can be negative after a reversal/correction; display that deficit and require finance review rather than clamping away the discrepancy.
  • Purchase holds: funds for assigned/uncertain purchases or the unpaid part of a binding seller order. When actual committed cost is known, use that amount; while uncertain retain the approved exposure. Seller payment moves an amount from hold to spending, not into both. Failed checkout releases a hold only after confirming no binding order or outstanding charge remains.
  • Refund holds: amounts allocated to due/approved/in-progress refunds and uncertain attempts. Hold them when a specific refund is created so neither a new purchase nor another refund can spend them. Approval/execution rechecks available funds and destination; sent moves the amount from hold to net refunds sent exactly once. A canceled unpaid refund releases its hold with a recorded reason. A failed attempt retains the amount for the same refund until safely retried or canceled.
  • Unheld funds = held balance - purchase holds - refund holds. Retain the amount needed for active waiting demand, including partial funding of its next request. Any positive excess is surplus that the requester may ask to have returned. Do not auto-refund partial funding needed for an active request.
  • After safe withdrawal or explicit finalization, create refunds due from released, unused unheld funds. An unresolved purchase/seller repayment can coexist with a refund of a separately established unused amount. Recompute when new bank or seller evidence arrives; never promise expected seller recovery as available money.
  • A deficit or shortage against existing holds blocks additional assignments and new/refreshed refund execution from that balance until finance resolves it. Existing purchase facts and liabilities stay recorded; the responsible organizer handles them through recovery. No borrowing from another requester/event balance.
  • Keep per-order actual costs and fees allocated to the linked requests; request amounts must sum to the order total so shared fees are not duplicated. Financial settlement does not change the seller-payment/ticket-delivery fulfillment evidence.

Cancellation, supply exhaustion, and mode changes

  • For withdrawal or canceled events, stop new purchasing for the affected demand. Release an unstarted assignment only when checkout cannot still succeed. Uncertain work remains in recovery. A binding seller order retains its cost/exposure until its cancellation outcome is known. There is no automatic full refund of already spent/committed money merely because the participant or event canceled.
  • Supply exhaustion becomes financial finalization through an explicit organizer action, not a temporary absence of vouchers. Finalize remaining waiting demand as unserved; refund its unused funds. Pending purchases and recoveries remain separately visible until settled. Preserve individually successful purchases in partially served groups.
  • For failed purchases, safely released funds can fund a retry under the established queue order while the request stays active. On withdrawal/finalization they instead become due for refund.
  • A purchase-mode change cannot erase, relabel, or move upfront money. Under the pre-order mode-change restrictions already settled, pause allocation and settle safe releases; unused central-purchase funds become due for refund when that funded demand is withdrawn from central purchase. The event lifecycle decision owns the action's detailed permissions and UI.

Refund state and evidence

  • Main path: due -> approved -> in progress -> sent. Due means an amount is established and held; approval records the authorized person, amount, and approved destination. In progress means a bank attempt has started. Sent completes prevouch's refund record only with execution evidence, amount, time, and transaction reference; a recipient acknowledgment is unnecessary.
  • An uncertain bank outcome keeps its hold and enters review; elapsed time alone does not authorize a retry. Verified failure/return reopens the outstanding amount. Link retry attempts to the same refund and allow no two live attempts for the same amount.
  • Changes, split refunds, corrections, cancellations of unpaid refunds, and retries preserve actor/time/reason history and cannot return the same money twice. Refund details cannot be edited underneath an already started/uncertain transfer. Expected and actual seller repayments are separate from participant refund attempts.

Participant and organizer views; notification handoff

  • Requester view: payment instructions/reference, accepted tier and required details for every holder, requested total, confirmed receipts, funding shortfall, per-request funding/eligibility and purchase/delivery status, purchase holds, seller spending, refunds due/in progress/sent, remaining held amount, and corrections affecting that requester. Explain when money is held for investigation; offer surplus-refund requests and collection of private refund details. Participants cannot self-confirm receipt or refund completion.
  • Finance view: per-requester and event totals, bank reconciliation/unmatched receipts, transaction evidence, outstanding purchase/refund holds, deficits, refund work, and actor/time/reason history. Event totals distinguish unmatched money from credited balances. Purchasing organizers see holder/tier details, funding eligibility/reservations, agreed spending limits, and purchase outcomes needed for their work; finance permission controls bank/refund details and financial mutations. No member-wide financial or bank-data listing.
  • Pass required notification facts to Define delivery addresses, email templates, and notification preferences: payment instructions; receipt confirmation/correction/reversal; changed amount/details or funding shortfall; purchase/recovery progress; refund due/details needed/in progress/sent/failed-or-returned; finance alerts for unmatched money, deficits, and uncertain transfers. That decision still owns channels, templates, preferences, and suppression/coalescing. Do not put full bank details, member numbers, or sensitive bank evidence into push previews.

Worked amounts

Illustrative prices only: three accepted requests at EUR 150 each; all actual spending includes agreed seller fees.

Case Net receipts Net seller spending Purchase hold Refund hold/due Net refunds sent Held balance
All three fulfilled at EUR 150 450 450 0 0 0 0
All three fulfilled for EUR 430; surplus refund requested 450 430 0 20 0 20
Two fulfilled, third unserved after finalization 450 300 0 150 0 150
No tickets bought; finalized unserved 450 0 0 450 0 450
One accepted order, unpaid; other two finalized unserved 450 0 150 300 0 450
Two bought from EUR 300 received; third still active 300 300 0 0 0 0
Partial-service refund of EUR 150 sent 450 300 0 0 150 0

The active third request in the EUR 300 case needs a EUR 150 top-up and retains its place. In the accepted-order case, EUR 150 is committed despite no seller spending or delivered ticket yet; only EUR 300 is established as refundable. After sending any listed refund, its hold and held balance reduce by the sent amount. A confirmed returned refund restores the outstanding amount exactly once. If a hypothetical canceled EUR 150 seller payment returns only EUR 140, net seller spending remains EUR 10 and at most EUR 140 becomes available for the participant; do not assume any particular seller cancellation policy.

Existing decision handoffs and scope

Link this resolution from the existing allocation/fulfillment, recovery, authority/lifecycle, notification, and four-design prototype decisions. Prototype dynamic per-holder tiers, a tier-required member number, partial funding, skipped/restored group priority, purchase holds, full/partial/no service, refund retries, and correction history. Existing tickets cover these followups; no new child decision is required by the agreed manual banking scope.

Statement import, bank integration, organizer reimbursements, production implementation, actual purchasing, and real money transfers are outside this decision's implementation scope. This resolution selects the domain behavior; it makes no bank transfer or ticket purchase.

Discussion and interactive worked examples: Funding and refund review.

## Resolution: upfront funding and refunds for central purchase Agreed with the requester in the live wayfinder discussion, including the accounting model, worked amounts, visibility rules, and confirmation that the decision is complete. This resolution is the canonical decision and supersedes the earlier checkpoints. ### Responsibility and ticket tiers - Keep one requester balance per requester and event, covering their own and all companion ticket requests. Companions need no separate balance or account. Several transfers and identifiable third-party payers are allowed. Each event uses one currency; balances do not fund another requester or event. - Give each requester balance a unique payment reference and display the designated account, event currency, required amount, and reference in payment instructions. No receipt is established by a participant saying they paid. - Organizers define dynamic ticket tiers, their prices including known seller fees, and tier-required holder details before participants select and pay. Examples are Standard, Family & Friends, and CCC e.V. Member Ticket requiring a CCC e.V. member number. These are configurable examples, not built-in products. Each holder can select a different tier. - Preserve each request's accepted tier and agreed amount. Organizer edits do not silently change existing requests. Require requester acceptance and enough additional confirmed funding before buying above that amount. Lower actual costs remain in the requester balance. Organizers absorb their own banking and administrative costs. - Before assignment, an accepted tier change preserves the request's position and recalculates required funding. After assignment, the responsible organizer establishes a safe checkout state before changing or releasing anything. Binding orders follow their actual seller change/cancellation outcome. No automatic tier substitution. Missing or rejected required details make the affected request ineligible without automatic expiry. ### Manual bank records and authority - Initial scope is manual reconciliation and manual external bank transfers. Someone with separate finance permission verifies bank evidence, matches money to the requester/event, and confirms or corrects receipts and refund records. Do not build statement import, direct bank integration, personal advances, or organizer reimbursement into this workflow. Seller purchases use the designated account or its payment method. - Record transaction identity/reference, amount, currency, bank evidence, matching target, actor, time, and reason. A bank transaction must not be credited twice, including across requester balances. Multiple distinct real transfers all count. Use linked corrections/reversals; retain the original history. - Unmatched or wrong-currency money stays outside spendable requester credit until manually resolved. Do not guess a match or perform implicit currency conversion. Recording bank facts and changing a purchase/fulfillment outcome are distinct actions with their own evidence. - Missing/partial payment leaves demand waiting. Late confirmed money funds still-active demand under its existing order; money arriving after withdrawal/finalization becomes refundable, not a new queue entry. A reversed receipt removes available funding. A deficit affecting reservations or binding purchases requires finance review and a top-up; it does not create a negative refund or erase a seller obligation. - One finance-authorized person can approve and record a refund; second-person approval is optional. Keep requester-confirmed, finance-approved refund details privately for the event, visible to that requester and finance staff. Suggest the original sending account without assuming a third-party payer is the intended refund recipient. A changed destination invalidates the old approval before execution; an uncertain attempt retains its recorded destination until resolved. ### Funding eligibility and queue order - Upfront receipt, funding eligibility, voucher assignment, organizer purchase claim, binding seller order, seller payment, seller-confirmed sending of ticket access, and refund are separate facts. A funded or assigned request is not yet a purchased/fulfilled ticket. Preserve the fulfillment contract in [Define central-purchase workflow and fulfillment](https://git.s1q.dev/MISChaufen/prevouch/issues/15). - Include unpaid requests in the initial shuffle. FCFS and both shuffled modes preserve their established order while temporarily skipping ineligible requests. A request needs its full agreed amount and all required holder/tier details before purchase eligibility. Being unpaid or lacking details does not by itself expire the request. Confirmed funding or corrected details restore eligibility at the existing position, never revoking an existing assignment or purchase for someone else. - Fund individual requests in their existing allocation order, not whole self +n groups. Within one requester balance, an earlier unfunded expensive request cannot be bypassed to fund a cheaper later request. Retain partial money toward that earlier request. In shuffled modes, establish the actual order at the initial shuffle before determining the funded prefix; pre-shuffle totals do not promise a particular holder's place. - Reserve the full agreed amount at voucher assignment, alongside the request/voucher reservation, before another assignment or refund can consume it. Existing reservations/commitments take priority over funding additional waiting requests. Multiple usable vouchers and organizers cannot spend the same money twice. Funding changes trigger eligibility reevaluation, but automatic allocation still requires distribution to have started. - In Shuffled (grouped), the active group continues while its next original request is eligible. If that request becomes unfunded or otherwise ineligible, skip the group rather than blocking others or bypassing its next member. The skipped group retains its original group position. If it becomes eligible while another group has an active turn, finish that active turn while its next original request remains eligible; then resume the earlier group ahead of later groups. Later additions never extend a turn. This explicitly qualifies group continuity in [Define allocation policies and organizer-triggered shuffling](https://git.s1q.dev/MISChaufen/prevouch/issues/14). ### Accounting model Use amounts in the event currency at that currency's monetary precision. These are domain balances and transitions, not a storage-technology choice. - **Net receipts:** confirmed upfront money minus reversed/returned incoming payments, as amended by linked corrections. - **Net seller spending:** confirmed seller payments minus seller repayments actually received and confirmed. Expected seller refunds do not count as cash. - **Net refunds sent:** bank-confirmed participant refunds minus transfers confirmed failed/returned after being recorded as sent. Reopening a refund must account for returned cash exactly once. - **Held balance = net receipts - net seller spending - net refunds sent.** It can be negative after a reversal/correction; display that deficit and require finance review rather than clamping away the discrepancy. - **Purchase holds:** funds for assigned/uncertain purchases or the unpaid part of a binding seller order. When actual committed cost is known, use that amount; while uncertain retain the approved exposure. Seller payment moves an amount from hold to spending, not into both. Failed checkout releases a hold only after confirming no binding order or outstanding charge remains. - **Refund holds:** amounts allocated to due/approved/in-progress refunds and uncertain attempts. Hold them when a specific refund is created so neither a new purchase nor another refund can spend them. Approval/execution rechecks available funds and destination; sent moves the amount from hold to net refunds sent exactly once. A canceled unpaid refund releases its hold with a recorded reason. A failed attempt retains the amount for the same refund until safely retried or canceled. - **Unheld funds = held balance - purchase holds - refund holds.** Retain the amount needed for active waiting demand, including partial funding of its next request. Any positive excess is surplus that the requester may ask to have returned. Do not auto-refund partial funding needed for an active request. - After safe withdrawal or explicit finalization, create refunds due from released, unused unheld funds. An unresolved purchase/seller repayment can coexist with a refund of a separately established unused amount. Recompute when new bank or seller evidence arrives; never promise expected seller recovery as available money. - A deficit or shortage against existing holds blocks additional assignments and new/refreshed refund execution from that balance until finance resolves it. Existing purchase facts and liabilities stay recorded; the responsible organizer handles them through recovery. No borrowing from another requester/event balance. - Keep per-order actual costs and fees allocated to the linked requests; request amounts must sum to the order total so shared fees are not duplicated. Financial settlement does not change the seller-payment/ticket-delivery fulfillment evidence. ### Cancellation, supply exhaustion, and mode changes - For withdrawal or canceled events, stop new purchasing for the affected demand. Release an unstarted assignment only when checkout cannot still succeed. Uncertain work remains in recovery. A binding seller order retains its cost/exposure until its cancellation outcome is known. There is no automatic full refund of already spent/committed money merely because the participant or event canceled. - Supply exhaustion becomes financial finalization through an explicit organizer action, not a temporary absence of vouchers. Finalize remaining waiting demand as unserved; refund its unused funds. Pending purchases and recoveries remain separately visible until settled. Preserve individually successful purchases in partially served groups. - For failed purchases, safely released funds can fund a retry under the established queue order while the request stays active. On withdrawal/finalization they instead become due for refund. - A purchase-mode change cannot erase, relabel, or move upfront money. Under the pre-order mode-change restrictions already settled, pause allocation and settle safe releases; unused central-purchase funds become due for refund when that funded demand is withdrawn from central purchase. The event lifecycle decision owns the action's detailed permissions and UI. ### Refund state and evidence - Main path: **due -> approved -> in progress -> sent**. Due means an amount is established and held; approval records the authorized person, amount, and approved destination. In progress means a bank attempt has started. Sent completes prevouch's refund record only with execution evidence, amount, time, and transaction reference; a recipient acknowledgment is unnecessary. - An uncertain bank outcome keeps its hold and enters review; elapsed time alone does not authorize a retry. Verified failure/return reopens the outstanding amount. Link retry attempts to the same refund and allow no two live attempts for the same amount. - Changes, split refunds, corrections, cancellations of unpaid refunds, and retries preserve actor/time/reason history and cannot return the same money twice. Refund details cannot be edited underneath an already started/uncertain transfer. Expected and actual seller repayments are separate from participant refund attempts. ### Participant and organizer views; notification handoff - Requester view: payment instructions/reference, accepted tier and required details for every holder, requested total, confirmed receipts, funding shortfall, per-request funding/eligibility and purchase/delivery status, purchase holds, seller spending, refunds due/in progress/sent, remaining held amount, and corrections affecting that requester. Explain when money is held for investigation; offer surplus-refund requests and collection of private refund details. Participants cannot self-confirm receipt or refund completion. - Finance view: per-requester and event totals, bank reconciliation/unmatched receipts, transaction evidence, outstanding purchase/refund holds, deficits, refund work, and actor/time/reason history. Event totals distinguish unmatched money from credited balances. Purchasing organizers see holder/tier details, funding eligibility/reservations, agreed spending limits, and purchase outcomes needed for their work; finance permission controls bank/refund details and financial mutations. No member-wide financial or bank-data listing. - Pass required notification facts to [Define delivery addresses, email templates, and notification preferences](https://git.s1q.dev/MISChaufen/prevouch/issues/9): payment instructions; receipt confirmation/correction/reversal; changed amount/details or funding shortfall; purchase/recovery progress; refund due/details needed/in progress/sent/failed-or-returned; finance alerts for unmatched money, deficits, and uncertain transfers. That decision still owns channels, templates, preferences, and suppression/coalescing. Do not put full bank details, member numbers, or sensitive bank evidence into push previews. ### Worked amounts Illustrative prices only: three accepted requests at EUR 150 each; all actual spending includes agreed seller fees. | Case | Net receipts | Net seller spending | Purchase hold | Refund hold/due | Net refunds sent | Held balance | | --- | ---: | ---: | ---: | ---: | ---: | ---: | | All three fulfilled at EUR 150 | 450 | 450 | 0 | 0 | 0 | 0 | | All three fulfilled for EUR 430; surplus refund requested | 450 | 430 | 0 | 20 | 0 | 20 | | Two fulfilled, third unserved after finalization | 450 | 300 | 0 | 150 | 0 | 150 | | No tickets bought; finalized unserved | 450 | 0 | 0 | 450 | 0 | 450 | | One accepted order, unpaid; other two finalized unserved | 450 | 0 | 150 | 300 | 0 | 450 | | Two bought from EUR 300 received; third still active | 300 | 300 | 0 | 0 | 0 | 0 | | Partial-service refund of EUR 150 sent | 450 | 300 | 0 | 0 | 150 | 0 | The active third request in the EUR 300 case needs a EUR 150 top-up and retains its place. In the accepted-order case, EUR 150 is committed despite no seller spending or delivered ticket yet; only EUR 300 is established as refundable. After sending any listed refund, its hold and held balance reduce by the sent amount. A confirmed returned refund restores the outstanding amount exactly once. If a hypothetical canceled EUR 150 seller payment returns only EUR 140, net seller spending remains EUR 10 and at most EUR 140 becomes available for the participant; do not assume any particular seller cancellation policy. ### Existing decision handoffs and scope Link this resolution from the existing allocation/fulfillment, recovery, authority/lifecycle, notification, and four-design prototype decisions. Prototype dynamic per-holder tiers, a tier-required member number, partial funding, skipped/restored group priority, purchase holds, full/partial/no service, refund retries, and correction history. Existing tickets cover these followups; no new child decision is required by the agreed manual banking scope. Statement import, bank integration, organizer reimbursements, production implementation, actual purchasing, and real money transfers are outside this decision's implementation scope. This resolution selects the domain behavior; it makes no bank transfer or ticket purchase. Discussion and interactive worked examples: [Funding and refund review](t3-thread://v1/165be165-e3cf-49e4-937b-cbbb0128ca3c).
phg 2026-10-22 13:26:35 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
research/design-references
research/voucher-replication
research/apple-web-push
No results found.
Labels
Clear labels   
needs-info

   
needs-triage

   
ready-for-agent

   
ready-for-human

   
wayfinder:grilling

   
wayfinder:map

   
wayfinder:prototype

   
wayfinder:research

   
wayfinder:task

   
wontfix
No labels
needs-info
needs-triage
ready-for-agent
ready-for-human
wayfinder:grilling
wayfinder:map
wayfinder:prototype
wayfinder:research
wayfinder:task
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
phg
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
#5 Define ticket-request allocation and fulfillment
MISChaufen/prevouch
#10 Define administrator authority, queue visibility, and event lifecycle
MISChaufen/prevouch
Depends on
#14 Define allocation policies and organizer-triggered shuffling
MISChaufen/prevouch
#15 Define central-purchase workflow and fulfillment
MISChaufen/prevouch
Reference
MISChaufen/prevouch#16
No description provided.