-
-
PayPal Sandbox payment captured. The receipt links the order and capture to the review it was based on.
-
After the seller clarifies, the terms become eligible. The buyer acknowledges them, and only then does the PayPal button appear.
-
A listing hides an instruction to the AI reviewer. Claude ignores it and pauses payment, quoting the exact sentences.
-
Vague terms ("I'll send it when I can") produce focused questions for the seller instead of a payment button.
-
Claude flags the hidden instruction, and a separate TrustPay rule catches the gift-card fee in code. Rules can pause, never approve.
-
TrustPay AI reviews a seller's terms with Claude before PayPal checkout opens.
Inspiration
People pay strangers online for small digital services all the time: a logo, an avatar, a quick edit. The seller's promise usually lives in a chat message or a listing, and buyers often discover it was vague ("I'll send it when I can"), or a setup for account theft ("send me your verification code"), only after they have paid. I wanted the moment before the PayPal button to do more than show a price. It should help the buyer understand what they are agreeing to.
What it does
TrustPay AI puts a review step in front of PayPal checkout for a USD 5.00 custom logo avatar.
- Review. The buyer pastes the seller's terms, plus any clarification the seller sent. Claude returns a structured review. Every finding quotes the exact sentence it is based on and is labelled as a stated term, something that needs clarification, or a payment concern.
- Decide in code. The model advises; TypeScript decides. Reviews that quote text not in the evidence are discarded. Deterministic TrustPay rules add findings for password or verification-code requests, payment outside the displayed checkout, and prices that don't match the order. Rules can pause checkout but can never approve it.
- Clarify. When essential terms are missing (delivery window, delivery channel, remedy if it fails), the buyer gets focused questions to ask the seller. They add the seller's answer, review again, and the decision updates.
- Approve and pay. For eligible terms, the buyer ticks an explicit acknowledgement, and only then does the PayPal button appear. The server creates a PayPal Orders v2 order whose
custom_idis the review ID, and captures it after the buyer approves in PayPal Sandbox. - Receipt. The capture, the review it was based on, and the time the buyer approved the terms are saved together and can be reopened later.
Five built-in synthetic scenarios show each outcome: clear terms, a missing delivery promise, a seller clarification, an account-credential request, and a listing that hides an instruction telling the AI reviewer to report no concerns.
How I built it
- Next.js 16 (App Router), React 19, TypeScript. All credentialed work happens in Server Actions.
- PayPal JavaScript SDK v6 (
@paypal/react-paypal-js) renders the one-time payment button and runs the approval flow in Sandbox. - PayPal Orders v2 through
@paypal/paypal-server-sdk: OAuth client credentials, server-side create and capture,PayPal-Request-Ididempotency (the review ID for create, a stable ID per order for capture), andcustom_idto link each order to its review. The amount is owned by the server, and a capture is accepted only if it isCOMPLETEDfor exactly USD 5.00. - Claude Sonnet 5.5 through the AI SDK (
ai+@ai-sdk/anthropic) with a Zod output schema. The system prompt treats seller text as untrusted evidence, defines which terms are essential for this purchase, and forbids claims about seller identity or fraud probability. - Checkout policy in plain TypeScript: quote validation, stricter-only rule checks, and an eligibility decision the server re-checks before it will create or capture an order. Each review is bound to an HTTP-only browser session, expires after 30 minutes, and is invalidated by a newer review.
- Vitest: 43 unit tests (order construction, capture validation, policy, rules, session binding, receipt storage) and four opt-in live tests against the real model.
Challenges I ran into
- Letting an AI gate a payment without trusting it blindly. Free-text model output can't safely decide checkout, so the review is schema-validated, every finding must quote the evidence, and code makes the final call.
- Prompt injection from the seller. The seller writes the text being reviewed, so a listing can try to talk the reviewer into approving. Claude is instructed to treat it as evidence, and independent rules run afterwards that can only make the decision stricter. The "hidden instruction" scenario demonstrates both.
- Avoiding endless clarification loops. A cautious reviewer can always find one more question (revision turnaround, file specs), which would keep a clear purchase from ever becoming payable. A bounded materiality rubric in the prompt limits questions to essential terms, and a live test checks that clarified terms become eligible with no further questions.
- Binding the decision to the money. The approved review has to be the one that gets paid for. The server ties each order to this browser's latest eligible review, reuses one order for repeated clicks, and refuses to capture an order that doesn't belong to that review.
Accomplishments that I'm proud of
- A complete review → clarify → approve → capture flow running against PayPal Sandbox, with the review saved next to the PayPal receipt.
- The model can recommend, but cannot unlock checkout by itself, even when the seller's text instructs it to.
- Failure paths that behave honestly. A model error keeps checkout paused. An expired review asks the buyer to review again instead of retrying a payment that can't succeed. A payment that was captured is never reported as failed.
What I learned
- Grounding every AI finding in a quote from the evidence makes the result easier to check, both for the buyer and for code.
- In payments, the useful split is "AI explains, code enforces." It keeps the experience helpful without handing money movement to a model.
- PayPal's
custom_idandPayPal-Request-Idare simple, effective ways to tie an external decision to an order and to make retries safe.
Scope
TrustPay judges the terms a buyer is shown, not the seller behind them. It doesn't verify identity, score fraud risk, or hold funds, and it isn't financial or legal advice. Sticking to what the text actually says is what lets every finding point to an exact quote. This build runs on PayPal Sandbox, so no real money moves.
What's next
- A hosted demo with rate limiting, so anyone can try it without their own API keys.
- Durable storage and PayPal webhook reconciliation (with signature verification) instead of local files and single-process memory.
- A seller-side view, where sellers fix flagged terms before a buyer ever sees them.
- More purchase types than a single fixed-price item.
Built With
- ai-sdk
- anthropic
- claude
- nextjs
- node.js
- paypal
- paypal-javascript-sdk
- paypal-orders-api
- react
- typescript
- zod
Log in or sign up for Devpost to join the conversation.