Ticket resale module using refund-and-rebuy and inventory-neutral transfers

[dutz-ro]

Problem

Ticket holders currently have no native, auditable way to return and transfer an individual paid ticket while preserving event capacity and invalidating the old QR code. External resale channels increase fraud risk and can bypass organizer policy.

Proposed v1

I would like to contribute a native ticket resale module in staged pull requests. The seller lists one attendee ticket, a buyer pays through the existing organizer checkout, the old attendee becomes CANCELLED, and a new attendee with fresh identifiers is issued. Primary inventory and capacity counters remain unchanged during the transfer.

Funds flow

The proposal uses refund-and-rebuy, not seller payouts:

1. The buyer creates and pays a normal order on the organizer connected Stripe account.
2. After the transfer commits, the seller receives a partial refund against the original Stripe payment.
3. The platform never holds or transfers funds between consumers.
4. The refund amount is calculated server-side from the original order item allocation and cannot exceed the original charge.

This intentionally limits resale to the original paid amount and excludes offline payments in v1.

Safety properties

• The seller ticket remains valid while merely listed or claimed; it is cancelled only after successful buyer payment.
• The transfer is inventory-neutral: quantity_sold, capacity assignments, occurrence capacity, promo usage, affiliate counters, and primary-sale statistics do not move.
• A PostgreSQL transaction and advisory lock serialize claim and transfer operations.
• Stripe refund I/O runs after commit in an idempotent retryable job.
• A failed seller refund leaves the ticket transfer valid and creates an actionable REFUND_FAILED state.
• Listing mutations require the existing expiring My Tickets lookup token, not only public short IDs.

Proposed delivery slices

1. Foundation and listing lifecycle: schema, event/product policy, eligibility and price allocation, list/withdraw/moderate APIs and UI.
2. Claim and checkout: atomic claim, reserved resale order, expiry, existing checkout reuse, inventory-neutral completion.
3. Seller refund and ledger: immutable transfer record, idempotent Stripe refund, retries and remediation.
4. Protections and operations: waitlist priority, rate limiting, audit logs, webhooks, organizer management UI.
5. Closure: Feature and Playwright E2E tests, OpenAPI, documentation, translations and migration notes.

Questions for maintainers

1. Is refund-and-rebuy acceptable as the v1 funds flow for Hi.Events?
2. Is reusing a normal order with an explicit resale source/listing link preferable to a separate resale payment aggregate?
3. Should public marketplace browsing ship together with paid claim/transfer, while the first PR keeps listings private to sellers and organizers?
4. Do you prefer one feature branch/PR or the staged PRs above?
5. Are there accounting/invoice constraints that should block or reshape this proposal before implementation?

I have an implementation plan and an initial local foundation, but will align the payment and order integration with maintainer feedback before submitting the contribution. This work uses AI assistance, so any PR and commits will carry the project-required 🤖 marker.