Dealflow

Get paid by brands without chasing: AI turns a sponsor's email into a PayPal invoice with proof, and marks it paid automatically.

Comment

Inspiration

Indian creators who make sponsored content for brands in the US and Europe often wait weeks to get paid. The video takes a week to make; getting paid means writing an invoice, proving the post is live, waiting for approval, and following up again and again.

Deal terms, invoices and payments end up scattered across email threads and PayPal, so it's hard to answer simple questions: How much am I owed? Who is late? What's coming in this month? Most of these creators have no manager or accountant, so this admin work comes straight out of their creative time.

PayPal in India only supports cross-border payments, which is exactly this situation: a foreign brand paying an Indian creator. That made PayPal the natural foundation.

What it does

Dealflow is an AI payment assistant for creators:

  1. Paste the brand's email. Claude extracts the brand, deliverables, price, payment terms and deadline. If the email has no price, Dealflow says so instead of guessing.
  2. Mark the post live. Paste the link to the published video or reel. It becomes the proof of delivery.
  3. Send the invoice. One click creates and sends a real PayPal invoice, with the live post linked in the invoice note, so the brand never has to ask for proof.
  4. Get paid. When the brand pays, PayPal notifies Dealflow by webhook and the deal turns Paid. A Check payment button asks PayPal directly as a backup.
  5. See everything. A dashboard shows what you're owed, what's overdue, what's paid and what needs attention, plus a history of every action and who took it: the AI, the creator, or PayPal.

How I built it

  • Next.js + TypeScript, deployed on Render, password-protected.
  • Claude (Haiku 5.5) turns a messy brand email into a structured deal. Its JSON output is validated with a zod schema before anything uses it; on an invalid reply it retries once, telling the model exactly which field was wrong.
  • PayPal REST APIs: OAuth (cached tokens), Invoicing v2 (create, send, get) and Webhooks (INVOICING.INVOICE.PAID) with signature verification.
  • Supabase (Postgres) stores deals, webhook events and an audit log, with row level security so only the server can read or write.
  • Test-driven development: every module started with a failing test. External services (PayPal, Claude, the database, even the clock) are passed in, so all the logic is unit tested with fakes. 149 tests run before every deploy; if one fails, the new version never goes live.

The code is layered so business rules never touch the network: pure domain logic (deal states, money, reminder rules), adapters for PayPal, Claude and Supabase, and one use-case function per user action.

A deal's due date is simply

$$ \text{dueAt} = \text{sentAt} + \text{termDays} \times 24\,\text{h} $$

and money is always stored as integer cents, never floating point.

Challenges I ran into

  • Making payments safe to process twice. PayPal can deliver the same webhook more than once. Each event ID is stored with a unique key, and an event is only skipped once it has finished processing, so retries are safe and a payment can never count twice.
  • Trusting the webhook. The webhook URL has to be public, so anyone could send a fake "paid" event. Every event is verified with PayPal's signature-verification API before it's trusted.
  • Keeping the AI away from money. Models can invent numbers. Strict schema validation plus a rule that missing prices are reported, not guessed solved this, and code, not the model, decides every status change.
  • PayPal sandbox setup. Getting Invoicing permissions, the right sandbox accounts (a US business as the creator, a US personal account as the brand) and matching credentials took real debugging.
  • Small infrastructure surprises, like the Supabase client needing a WebSocket library on Node 20.

Accomplishments that I'm proud of

  • It works end to end on a live URL, with real PayPal sandbox invoices and payments.
  • Fake webhooks are rejected, and duplicate events can't double-pay.
  • The AI is useful but never touches money directly; every rule is enforced in tested code.
  • A clean, layered codebase with 149 automated tests gating every deploy.

What I learned

  • How to design for money: integer cents, state machines, idempotent webhooks, optimistic concurrency and audit logs.
  • How to use AI safely in a payment flow: treat model output as untrusted input, validate it, and keep decisions in code.
  • How valuable test-first development is when integrating several external services under time pressure.

What's next for Dealflow

  • Let each creator connect their own PayPal account.
  • Verify posts automatically (YouTube Data API first).
  • AI-drafted reminders for overdue invoices, sent only with the creator's approval (the reminder rules are already built and tested).
  • Deposits, expected-payment dates based on each brand's history, and an INR view for creators' accountants.
  • Talking to more creators to shape what comes next.

Built With

Share this project:

Updates

Submission history