MiSFY DropCard

An AI venue scout finds artists the venues with the busiest calendars and sends the proposal; PayPal takes the deposit and ticket sales, and one Payouts batch pays everyone.

Comment

Inspiration

Live music still runs on DMs and spreadsheets. An artist planning a tour hunts for venues on Instagram, sends proposals by email, chases the deposit by bank transfer and waits to be paid by hand after the show. Every step is a place where a deal can die, and cross-border payments are the worst of them.

We asked: what if an AI agent could find the right venue and send the proposal, while PayPal moved the money from the deposit to the final payout, with every cent accounted for?

What it does

  1. Ask. An artist tells the AI venue scout what they want: "The busiest venues in Tokyo for a synthwave show, about 200 people."
  2. Find. The scout searches a directory of 300 venues in 20 cities, ranks them by activity (how many shows MiSFY's discovery data has on record for each), checks open dates at the best fit and proposes up to three slots.
  3. Propose. When the artist says so, the scout writes the proposal letter and sends it; the date becomes a hold. The venue owner approves it in the owner console, where the letter arrives.
  4. Pay. The artist pays the 30% deposit with PayPal on the venue's card. The booking turns green only when PayPal's verified webhook arrives — never because the browser said so. Tickets go on sale.
  5. Settle. At 09:00 venue time on the day after the show, one PayPal Payouts batch pays the venue, the artist and the promoter their shares; fees are deducted at settlement.
  6. See. The owner dashboard (AG Grid + AG Charts) shows sales, buyer countries, fees and payouts — all computed from one double-entry ledger.

Promoters who already know the venue can book on its card with a booking form instead; the money flow is the same.

How we built it

  • Server: Rust (axum, sqlx, tokio) and PostgreSQL. Small REST clients for PayPal and the Claude API (there is no official Rust SDK for either).
  • PayPal: Orders v2 with PayPal-Request-Id idempotency for deposits and tickets, the JavaScript SDK buttons for checkout, webhook signature verification (the raw event is forwarded byte for byte), Payouts for settlement, and a reconciliation job that asks PayPal directly when a webhook is late.
  • AI: Claude Opus 5.5 through the Anthropic Messages API runs the AI venue scout with six tools: search venues, check availability, propose slots, send the proposal (the agent writes the letter), read booking status, and create the deposit order. Guardrails live in the server: every tool runs inside the visitor's own session, the agent cannot approve bookings, and the payment tool is refused until the venue has approved. Every message and tool call is recorded and shown in the venue console.
  • Venue data: a pseudonymized slice of MiSFY's discovery data — 300 venues in 20 cities with their city, genre category and number of shows on record (names replaced, counts rounded). Activity is a percentile of shows on record: it shows a busy calendar, not live popularity, and the agent says so. Rooms and prices are made up for the demo because the data has none.
  • Money correctness: idempotency keys at every layer, unique constraints on orders, captures, webhook events and payout batches, and a double-entry ledger where every transaction sums to zero.
  • Frontend: React + TypeScript, Bryntum Scheduler Pro for the venue schedule, AG Grid and AG Charts for the dashboard, the PayPal JS SDK for checkout. Designed in MiSFY's style with the MiSFY logo; venue and artist photos are CC0 stock images, never the real venues or artists.
  • Hosting: Render (Docker web service, a nightly cron job that rebuilds sample data around "today", Render Postgres), described in render.yaml.
  • Hackathon partners: Bryntum Scheduler Pro draws each venue's availability timeline (AI proposals, holds, paid shows); AG Grid and AG Charts power the owner console's payments table and dashboard; Render hosts the demo (web service, Postgres, nightly cron); a Postman collection walks through the whole flow.
  • Testing: unit tests for the settlement arithmetic and the venue directory, an end-to-end test that runs the whole flow against local stand-ins for the PayPal sandbox and the Claude API (20 checks), and a Postman collection for judges.

Challenges we ran into

  • Making "paid" mean paid. The browser's PayPal callback is not proof of payment. We made the verified webhook the only source of truth, with a reconciliation job as the fallback, and verification depends on sending PayPal the event exactly as received.
  • Waiting for "the day after the show" in a 3-minute demo. Each visitor gets an isolated demo session with its own demo clock, so a judge can fast-forward to settlement without affecting anyone else — while every PayPal call stays real (sandbox).
  • Keeping an agent away from money. Prompt instructions are not a guardrail. The server decides which tools may run: before approval, the payment tool is blocked, and the block itself is logged.
  • Recommending honestly from thin data. Our venue data says how many shows a venue has on record, not how popular it is today. The scout ranks by that activity and tells the artist what it means instead of calling a venue "the hottest".
  • No double booking, no double payout. A database exclusion constraint and per-space locks for bookings; one payout batch per show whose sender_batch_id is also the request id.

Accomplishments that we're proud of

  • One flow from a chat message to a three-way PayPal payout, with a ledger that balances to the cent.
  • An agent that writes a real proposal letter the venue owner reads in their inbox, and that cannot touch money until the venue says yes.
  • A test that proves the money rules: repeated clicks create one order, forged webhooks are rejected, redelivered webhooks are ignored, settling twice never pays twice.

What we learned

  • Treat the payment provider's verified events as the source of truth and design every write to be safely repeatable.
  • Put an agent's limits in code, and make what it did visible to the people it works for.
  • Say exactly what the data means; an agent that explains its ranking is easier to trust.

What's next for MiSFY DropCard

Bring the scout into MiSFY's venue cards with the full discovery data, let venues share their real calendars and room prices, and add the promoter side (lineup search). Whether PayPal is used in production is a separate decision after the hackathon.

MiSFY DropCard is a new, standalone service built for MiSFY's venue cards; it shares no code, keys or infrastructure with the existing MiSFY app, and it only talks to the PayPal sandbox. Its venue directory is a pseudonymized slice of MiSFY's discovery data.

Built With

Share this project:

Updates

Submission history