Inspiration

Most bad spending isn't fraud. It's the annual plan you didn't need, the second tool that does what your first one already does, or the "offer ends tonight" course. These payments take one click, and nobody argues the other side before the money leaves.

ArbiterAI grew out of The Verdict Chamber, an earlier project where a five-agent AI jury stress-tested stock trades before capital was committed. We asked a simple question: what if every payment got that same cross-examination, and the payment rail itself enforced the verdict?

What it does

You describe a money decision: what it is, who gets paid, the amount, how it bills (one-time, monthly or yearly), why you want it, your monthly budget and your current subscriptions.

  1. Evidence first. ArbiterAI computes the facts from your inputs, without AI: amount due now, first-year cost, budget share, money left afterwards, overlap with existing subscriptions, and pressure wording like "limited-time".
  2. Adversarial jury. Four AI counsel argue in order, each seeing the arguments before it: the Advocate (case for), Skeptic (case against), Budget Officer (affordability and lock-in) and Analyst (the numbers).
  3. A structured verdict. A Presiding Judge rules PROCEED, MODIFY or REJECT, with the approved amount, required change, key risks and a "reconsider if" condition.
  4. PayPal enforces it. You confirm the exact amount and payee, and PayPal charges only the approved amount. A rejected payment never gets a PayPal button.
  5. Audit trail. Every review keeps the full debate, the verdict and the PayPal order and capture IDs, plus a running total of dollars requested but not approved.

Example: a \$1,188 yearly design-app plan that overlaps a tool you already pay for. Its budget share is

$$ \text{share} = \frac{\text{due now}}{\text{monthly budget}} = \frac{1188}{1500} \approx 79\% $$

The jury rules MODIFY: start monthly, and PayPal charges \$99 instead of \$1,188.

Try it: https://arbiter-ai-seven.vercel.app

How we built it

  • Stack: Next.js 15, React 19 and TypeScript, styled with Tailwind CSS. Zod validates data at every API boundary, and Vitest runs the test suite (45 tests).
  • AI: Google Gemini via the Vercel AI SDK. The four counsel stream their arguments with streamText; the judge returns a typed verdict with generateObject and a Zod schema, so the app never scrapes JSON out of prose. Prompts require every agent to cite the computed evidence and to treat user-typed text as untrusted data.
  • PayPal: the Orders v2 REST API (OAuth, create order, capture) and the PayPal JavaScript SDK buttons, in the sandbox. Both calls send a PayPal-Request-Id, so retries and double clicks can't create duplicate orders or captures.
  • Verdict-gated payments: verdicts live in the browser, so the server signs each approval (HMAC-SHA256, 30-minute expiry) with the decision, approved amount, outcome and payee. The order endpoint creates a PayPal order only from a valid signature and only for the signed amount.
  • Money rules outside the model: whatever the model returns, PROCEED pays exactly the requested amount, MODIFY can never exceed it, and REJECT pays nothing.
  • Honest fallback: if Gemini is missing or a call fails, a deterministic demo jury stands in, and the UI labels it (DEMO JUROR) so it never passes as live AI.
  • Hosting: Vercel, deployed from the hackathon branch.

Challenges we ran into

  • Trusting an LLM with money. A model can return any number. We moved every money rule into server code, capped the approved amount at the request, and made the payment endpoint accept only server-signed approvals.
  • Payment integrity without a database. Signed, expiring approvals plus PayPal idempotency keys gave us tamper-proof, double-click-safe payments without adding a backend database.
  • Silent AI failures. Our streaming setup was quietly swallowing provider errors, which produced blank juror cards labelled as live AI. We switched to reading the full event stream, treat errors and empty answers as failures, and fall back to the labelled demo jury.
  • Incomplete payments. We made sure only a COMPLETED PayPal capture is recorded as paid. A pending or declined capture shows its status and order ID instead of a false receipt.
  • Re-pointing a stock-research product at everyday payments without losing what made it work: the sequential, adversarial jury.

Accomplishments that we're proud of

  • The AI's verdict changes what PayPal does: whether an order can exist at all, and for how much.
  • MODIFY is a real outcome, not a soft "maybe": you pay a different, smaller amount.
  • The whole flow runs end to end: decision → evidence → debate → verdict → confirmation → PayPal capture → audit trail. It also runs with no keys at all, in a clearly labelled demo mode.
  • The payment and jury routes are covered by tests that we verified actually fail when the code is broken.

What we learned

  • Agentic payments need a contract between the AI layer and the payment layer: signed, scoped, expiring permissions, not "the model said so".
  • Structured output plus deterministic guard rails beats prompt engineering alone for anything that touches money.
  • Honesty is a feature: labelling demo output and refusing to record incomplete payments builds more trust than a slick demo that hides its edges.

What's next for ArbiterAI

  • PayPal Subscriptions for approved recurring plans, and refunds for reversed decisions
  • Webhooks for server-side payment reconciliation
  • Using PayPal transaction history as evidence, to spot recurring spend automatically
  • An API so AI shopping agents can ask ArbiterAI for a verdict before they spend

Built With

Share this project:

Updates

Submission history