Failed-dispatch retries and venue health monitoring

Resale dispatches don't always succeed on the first try — the venue's API might be down, your credentials might have rotated, or the customer's contact details might fail validation upstream. The platform has automatic retry + monitoring built in.

Automatic retries:
• If a dispatch fails, the sale is queued for retry
• An hourly cron retries pending dispatches with a 15-minute back-off between attempts
• Up to 3 attempts per sale; after the 3rd failure the sale is marked permanently_failed and an alert lands in Admin → Alerts
• Every retry is logged on the resale block's ledger with the exact error message returned by the vendor

Manual retries:
• Open the resale block, find the failed sale in the ledger, and click Retry now
• Useful when you've just rotated credentials or the vendor confirms an outage is over
• Manual retries don't count against the 3-attempt cap — admin can retry indefinitely

Weekly venue health check:
• A weekly scheduler verifies every connected venue (platform + per-org) by hitting a low-cost API endpoint (e.g. List Events for that vendor)
• If the vendor's status changes (Active → Warning, Active → Failed), a row is written to the platform_alerts collection
• Org admins see these in Admin → Alerts → Venues; a banner also appears at the top of the Resale page if your active vendor is degraded

What customers see when dispatch is delayed:
• The buy confirmation still succeeds — payment is captured by Stripe, the customer gets a receipt
• The confirmation email mentions "Your venue tickets will be delivered shortly" rather than a specific delivery time
• Once dispatch succeeds (immediate or after retries), the venue takes over and emails the customer their actual entry credentials
• If a sale ends up permanently_failed, admins are responsible for either issuing a refund (Stripe → Refund) or hand-delivering tickets via Manual CSV — the platform doesn't auto-refund