Paid Right

You did the work. But did you get paid everything you're owed? Paid Right is an AI agent that finds missed payments and forgotten fees in global brand deals, then helps creators collect through PayPal

Comment

Inspiration

Indian creators increasingly do paid work for US and UK brands. One deal can include a Reel, a set of Stories, cutdowns, paid-usage rights and revision limits, each with its own payment terms. The information that decides what a creator is owed is scattered: the agreement is in a PDF, the approval is in an email, and the payment is in PayPal. When a brand pays only part of what it owes, the creator has to piece it together alone, and chasing a client is awkward.

We wanted an agent that answers one question with evidence: "Did I get paid in full, and if not, what exactly is missing?"

What it does

PaidRight is an AI payment agent for creators working with global brands, built on PayPal.

  1. Reads the agreement. Claude turns the contract into deliverables, amounts, instalment schedules and rights clauses, each linked to a verbatim source quote. Unknown terms stay unknown, and ambiguous ones are flagged with a suggested clause.
  2. Bills through PayPal. Each approved deliverable, or each agreed instalment, becomes a real PayPal invoice (Invoicing API v2, Sandbox).
  3. Checks the money against PayPal. Invoice status, amount paid and due date are read live from PayPal. Nothing is entered by hand.
  4. Finds the gap and proves it. In the demo, GlowLab approved Aanya's Stories ($300, payable in two $150 instalments). The first invoice is paid and the second is past due. PaidRight shows "$150 is overdue. Here is how we know." with the contract clause, the approval, the PayPal record, and a clear note that PayPal fees are not part of what the brand owes.
  5. Acts only with approval. The agent drafts a reminder. The creator reviews it and clicks Approve and send via PayPal. The server re-checks the invoice with PayPal first, and if it is already paid, no reminder is sent.
  6. Finds money that hasn't been invoiced. When a paid-usage window ends, PaidRight asks whether the brand requested an extension. Only after the creator confirms does it draft the $200 extension invoice the contract allows.

How we built it

  • Next.js 16 + TypeScript + Tailwind, deployed on Vercel.
  • PayPal Invoicing REST API v2 (Sandbox), called only from the server. The calls are OAuth client credentials, generate invoice number, create invoice, send, get status and remind.
  • Claude (claude-sonnet-5-5) handles three jobs, all with strict tool schemas:
    1. agreement extraction with source quotes;
    2. a grounded explanation and reminder draft;
    3. change-order wording.
  • A deterministic money engine. The model never does arithmetic. Amounts are integer cents, and each instalment belongs to exactly one bucket: paid, overdue, awaiting payment, not invoiced, or not yet billable.

For the demo deal the buckets always reconcile:

$$ \underbrace{\$1{,}200}{\text{agreed}} = \underbrace{\$650}{\text{verified paid}} + \underbrace{\$150}{\text{overdue}} + \underbrace{\$400}{\text{not yet billable}} $$

and the overdue amount for a deliverable is

$$ \text{overdue} = \sum_{i \,:\, \text{unpaid},\ t > \text{due}_i} a_i , \qquad \text{PayPal fees} \notin \text{overdue} $$

  • Judge demo mode at /demo opens a fictional campaign backed by real Sandbox invoices, with no signup. A four-step guided path (The deal → The payment → AI finding → Take action) leads through it, and a Reset demo button restores it.

Challenges we ran into

  • Partial payments aren't available for India-based PayPal merchants. Our first design had the brand paying $150 of a $300 invoice. The Sandbox replied "Partial payments are not available in your country." We redesigned around how creator contracts actually split payment: agreed instalments, each on its own PayPal invoice. That turned out more honest, and it still shows exactly what the brand hasn't paid.
  • Fees vs underpayment. PayPal fees and currency conversion reduce what the creator receives, but they aren't money the brand owes. Keeping contract receivable, PayPal proceeds and bank settlement separate shaped the whole data model.
  • Not letting the AI overclaim. A usage window passing doesn't by itself mean a fee is owed, so the agent asks first. Change-order amounts come from code, never from the model.
  • A shared demo. Every judge uses the same Sandbox invoices. We hide pay links on unpaid demo invoices, re-check status before each reminder, and explain PayPal's reminder limits honestly when they apply.
  • Dates. "Overdue" depends on today's date. Before the real due date, the demo opens on a clearly labelled simulated date. After it, the demo uses the real date.

What we learned

  • The most useful job for AI here is connecting evidence (clause, approval, payment record). The arithmetic and money decisions belong in deterministic code and behind a human click.
  • PayPal capabilities vary by country. Testing the Sandbox before promising a feature changed our design for the better.
  • In a payments product, trust comes from small things: showing the real invoice ID, saying when status was last checked, and never showing success unless PayPal returned it.

What's next

  • A no-signup brand review link for approving deliverables or requesting changes.
  • PayPal webhooks with signature verification, for real-time status (today, status is read on demand).
  • The agent choosing PayPal actions itself through the PayPal Agent Toolkit, still behind creator approval.
  • More contract clocks: approval silence, exclusivity, kill fees.
  • Automated tests for the money engine and the judge path, and isolated Sandbox invoices per judge.

All people, brands and amounts in the demo are fictional. PayPal operations run in Sandbox; no real money moves.

Built With

Share this project:

Updates

Submission history