MichilisandClaude Opus 5
e296e80e48
Most attendees arrive without their QR open, and taking money at the door meant leaving the scanner for the event dashboard, where the Add Ticket modal demanded an email and recorded no payment method. The screen now leads with manual name search, keeps the camera one tap away behind a fullscreen overlay, and creates and charges walk-ins inline. Check-in and payment are one action: anything done here is born confirmed, paid (or comp) and checked in through a single endpoint, POST /api/events/:eventId/door-checkin. There are no confirm dialogs anywhere, because they stall the queue; a ten-second Undo replaces them, reversing exactly what the action changed via the undo state recorded alongside its idempotency key. Writes fire in the background with retries, so venue wifi never blocks the person at the door, and a capacity limit only warns, since staff at the door are the authority. Every write carries a client-generated idempotency key, inserted in the same transaction as the writes it guards, so a double tap or a retry after a timeout cannot produce a second ticket, payment or check-in. Search runs entirely in memory over one preloaded list: names are matched accent- and case-insensitively in both directions, per word, prefix before substring, with a mostly-numeric query searching phone digits so two people with the same name can be told apart. Door money is recorded as payments.source 'door' plus payments.method (cash, bitcoin, transfer or guest) while provider keeps its existing value, so capacity counting, the stale-booking sweeps and the admin payment lists are unaffected and revenue can still be split pre-sale versus door. Bitcoin records the payment as made, on the same trust model as cash, with no invoice generated; lib/doorPayments.ts is where a real Lightning flow slots in later. Also fixes the SQLite tickets DDL, which still created the pre-split attendee_name column with NOT NULL email and phone. Only fresh databases were affected -- existing ones were relaxed by later ALTERs -- but on those, door walk-ins (and any other ticket) could not be inserted at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
52 lines
2.2 KiB
TypeScript
52 lines
2.2 KiB
TypeScript
// Door payment tenders.
|
|
//
|
|
// The door check-in screen offers four one-tap tenders. Each maps onto an
|
|
// existing payments.provider so the rest of the app (capacity, sweeps, admin
|
|
// payment lists, receipts) keeps working unchanged, while payments.method
|
|
// records which tender was actually used for the end-of-night cash-up.
|
|
//
|
|
// Bitcoin currently maps to the 'lightning' provider but records the payment as
|
|
// already made — the same trust model as cash, no invoice generated. When a real
|
|
// Lightning flow lands it slots in here: the tender keeps its name and provider,
|
|
// only the settlement path in routes/door.ts changes.
|
|
|
|
export const DOOR_PAYMENT_METHODS = ['cash', 'bitcoin', 'transfer', 'guest'] as const;
|
|
|
|
export type DoorPaymentMethod = (typeof DOOR_PAYMENT_METHODS)[number];
|
|
|
|
interface DoorTender {
|
|
/** Existing payments.provider this tender is stored as. */
|
|
provider: 'cash' | 'lightning' | 'bank_transfer';
|
|
/** Human label used in payment references and toasts. */
|
|
label: string;
|
|
/** Comp tenders carry no revenue and always record a zero amount. */
|
|
isComp: boolean;
|
|
}
|
|
|
|
export const DOOR_TENDERS: Record<DoorPaymentMethod, DoorTender> = {
|
|
cash: { provider: 'cash', label: 'cash', isComp: false },
|
|
bitcoin: { provider: 'lightning', label: 'bitcoin', isComp: false },
|
|
transfer: { provider: 'bank_transfer', label: 'transfer', isComp: false },
|
|
guest: { provider: 'cash', label: 'guest', isComp: true },
|
|
};
|
|
|
|
export function isDoorPaymentMethod(value: unknown): value is DoorPaymentMethod {
|
|
return typeof value === 'string' && (DOOR_PAYMENT_METHODS as readonly string[]).includes(value);
|
|
}
|
|
|
|
/** Ticket paymentStatus a tender settles to: comps are 'comp', everything else 'paid'. */
|
|
export function paymentStatusForMethod(method: DoorPaymentMethod): 'paid' | 'comp' {
|
|
return DOOR_TENDERS[method].isComp ? 'comp' : 'paid';
|
|
}
|
|
|
|
/** Amount actually recorded: comps are always zero regardless of what was requested. */
|
|
export function amountForMethod(method: DoorPaymentMethod, requested: number): number {
|
|
return DOOR_TENDERS[method].isComp ? 0 : Math.max(0, requested);
|
|
}
|
|
|
|
export function doorReference(method: DoorPaymentMethod): string {
|
|
return DOOR_TENDERS[method].isComp
|
|
? 'Door — guest (comp)'
|
|
: `Door — paid by ${DOOR_TENDERS[method].label}`;
|
|
}
|