ProofPay

The problem

Cross-border freelance work runs on misplaced trust. Freelancers deliver first and then wait, sometimes for weeks, sometimes forever, because the client holds the money and faces no cost for paying late. Clients have the mirror problem: they pay first, or release a milestone on a screenshot and a confident message, and discover afterwards that half the requirements were never met. Marketplace platforms sit in the middle of this, but they charge heavily for it and their dispute processes are slow, opaque, and usually decided from chat logs rather than from the work itself.

The solution

ProofPay is an escrow agent that settles each milestone by reading the work. A client describes a job in plain words. An AI drafter converts the brief into a contract: milestones, and for each milestone a short list of measurable acceptance criteria with weights. The client funds a milestone through PayPal as an authorization hold, so the money is committed but not yet paid. The freelancer submits the deliverable inside ProofPay. An AI verifier then grades the deliverable against every criterion, and it may only mark a criterion as passed when it can cite concrete evidence from the deliverable itself. The weighted verdicts decide the money: the earned share is captured and paid out to the freelancer, the unearned remainder is refunded to the client, and if nothing passes, the funds stay held and the freelancer revises against written reasons.

How it works

1. The client writes a brief, for example a landing page with a hero section, three pricing tiers, and a working contact form.
2. The drafter returns 1 to 4 milestones, each with 2 to 5 weighted criteria. Both parties see the exact criteria before any money moves.
3. The client funds the milestone with PayPal Checkout (Orders v2, authorize intent). The authorization id is stored on the milestone.
4. The freelancer submits the deliverable as text, a link, or a file reference.
5. The verifier returns a verdict per criterion (pass, partial, fail), each with a reason and quoted evidence. A separate post-check downgrades any pass that rests on generic praise instead of evidence, and a criterion the model does not answer counts as a fail, so silence can never release money.
6. ProofPay captures the authorized amount, pays the earned fraction to the freelancer through PayPal Payouts, and refunds the rest. PayPal webhooks reconcile the payment state, and every event is written to a ledger that both sides can open. The ledger is the dispute evidence pack: contract, criteria, deliverable, verdicts, and money movements in one timeline.

What makes it different

Most payment demos stop at checkout. ProofPay uses the part of PayPal that checkout demos skip: holding money with an authorization, capturing it later in a proportion decided by evidence, refunding the unearned part, and paying out to a second party. The AI is not a chatbot bolted onto a payment form. It writes the contract terms and it grades against them, and its grading is constrained: structured JSON output, hard validation, and an evidence rule enforced outside the model. Verification quality is also decided at drafting time, because vague criteria cannot be graded, so the drafter is required to produce measurable ones.

How we built it

The backend is Node.js and TypeScript on Fastify, with TypeScript running through Node's native type stripping so there is no build step. The PayPal integration is a hand-written REST client using built-in fetch: OAuth2 client credentials with a cached token, Orders v2 create and authorize, capture with full or partial amounts, capture refunds, Payouts, and a webhook endpoint that verifies signatures before recording an event. The AI layer is provider-agnostic: any OpenAI-compatible chat endpoint can be configured, the drafter and verifier prompts live in one file as the single source of truth, and model output is parsed against strict JSON contracts. A malformed draft gets one repair attempt carrying the validation error, and then the request fails with a clean error instead of an invented contract. State is kept in a small JSON store behind one module. The front end is a single page with client and freelancer views and an AG Grid Community table for the ledger. Credentials are supplied at runtime through a /connect page (or environment variables, which take precedence), stored in a local file with 0600 permissions, and never rendered back; the settings API reports only whether a value is configured and the last four characters of the client id.

Challenges we ran into

The hardest problem was making verification strict without making it brittle. Left alone, a model grades generously and writes plausible reasons for work that is not there. The fix was to move the standard out of the prompt and into code: a pass requires quoted evidence, a post-check downgrades evidence-free passes, and unanswered criteria default to fail. The second challenge was the money flow. Escrow maps onto PayPal as authorize now and capture later, but partial success needs care: capture the full authorized amount, pay out only the earned share, and refund the remainder, so the three movements always sum back to the milestone amount. The third was credentials. A public demo needs real sandbox credentials, but secrets cannot sit in a repo or be pasted into a submission form, so the runtime settings file and the status view that never exposes values came out of that constraint.

What we learned

Authorization holds are a natural fit for escrow, and most of the design falls out of taking that seriously: once money is held rather than paid, the release rule becomes the product. We also learned that an AI verifier is only as good as the criteria written before the work started, which is why drafting and verifying are one system rather than two features. Finally, structured output is a contract, not a hope: validation and a repair path mattered more than prompt wording.

AI tools and models used

A large language model accessed through an OpenAI-compatible chat API, used in two roles: contract drafting (brief to milestones and weighted criteria) and deliverable verification (per-criterion verdicts with cited evidence). The integration is provider-agnostic by design: any compatible endpoint and model can be configured at runtime. Model used for the submitted demo: Gemini 3.8 Flash (Google AI Studio), called through its OpenAI-compatible endpoint. In the final end-to-end sandbox run (contract ct_3e86782b, a wedding photography studio website), the same model drafted the contract, the client funded the $250 first milestone in PayPal sandbox checkout (authorization 08413488AT325521Y), and the model verified the design delivery as partial with a release fraction of 0.85: the mockups and clickable prototype passed in full, while the style guide was partial because it documented the colour palette but not the font hierarchy or button states. ProofPay captured the $250 (capture 9YW53158V3301540E), paid $212.50 to the freelancer (payout batch FTT44H8732SPJ), and refunded the unearned $37.50 to the client (refund 9CW71170H4739574J). Muse (an AI coding assistant) was used during development to help write and review the codebase. All design decisions, testing, and the submission itself are the entrant's. Deterministic stub implementations of the drafter and verifier are included so judges can run the complete flow offline with no API key; the app reports honestly in its health endpoint and ledger whether a live model or a stub produced each result.

PayPal APIs and tools used

Orders v2 (create order with AUTHORIZE intent, authorize payment, capture full and partial amounts), Payments refunds for the unearned remainder, Payouts for the earned share, Webhooks with signature verification for reconciliation, and the PayPal Developer Dashboard sandbox app and sandbox accounts for all testing.

Built With

• ag
• api
• fastify
• gemini
• grid
• node.js
• orders
• payouts
• paypal
• svelte
• typescript