Quiet Check

Before PayPal takes the money for an AI agent's purchase, merchants privately check the buyer against each other's fraud lists, without sharing them.

Comment

Inspiration

AI agents are starting to shop for us, and their purchases arrive without most of what fraud tools read: no mouse movement, no typing rhythm, no browsing path. Over half of US and UK consumers (55%) are uncomfortable letting an agent buy for them (Riskified, Q1 2026).

What still identifies a repeat abuser is the plain stuff: email, shipping address, device. Another merchant may already have this buyer on its chargeback list. But merchants can't hand customer lists to competitors: privacy law limits sharing personal data, a list is a commercial asset, and hashing doesn't help because emails and addresses are guessable.

AP3, an open protocol from Silence Laboratories (now at LF Decentralized Trust), lets agents from different companies compute on private data without revealing it. That made a different design possible: ask "is this buyer on your list?" and learn only yes or no.

What it does

  1. Shop. A buyer tells the shopping agent "buy the blue backpack in medium". It finds the item, builds the cart and creates a PayPal order with intent AUTHORIZE, priced by the backend, never the agent. The buyer approves in the PayPal pop-up.
  2. Check. Before any money moves, the merchant's risk agent asks three consortium merchants whether they hold the buyer's email, shipping address or device ID: 3 x 3 = 9 AP3 private set intersection (PSI) sessions, run at once. No list leaves its owner, and every session is stored as a signed, verified receipt.
  3. Decide. A fixed rule decides: 0 hits, authorise and capture; 1 hit, authorise only and hold for a person; 2 or more, never authorise. Claude explains each decision in 2-3 sentences. It never makes it.
  4. Review. In the merchant console a reviewer sees the 3x3 hit grid, the 9 receipts and a "who saw what" panel, asks the review copilot why an order is on hold, and on their instruction plus one Approve click the copilot captures or voids the held payment in PayPal. PayPal's signed webhook confirms it.
  5. Dispute. If a buyer later disputes a payment, the verified webhook brings it in, Claude drafts an audit-trail summary of the evidence from the receipts and the payment timeline (without the buyer's identifiers), and a reviewer edits it and submits it to PayPal.

Three demo buyers, same shop, same item, three outcomes: Ana's payment is captured, Ben's is held for review, Cy is never charged.

How we built it

  • PayPal (sandbox, all live): JS SDK v6 for the buyer's approval; Orders v2 (intent AUTHORIZE, then authorise); Payments v2 (capture, or void a held payment); webhooks with signature verification and de-duplication; Disputes (read, provide evidence); PayPal-Request-Id on every money-moving call.
  • AP3: the open-source SDK (ap3 1.2.2). Members A, B and C are separate A2A agents, each holding only its own list and publishing a signed commitment to it on its AgentCard. Each order runs 9 PSI sessions; signed intents are verified before receipts are stored.
  • AI (Claude, behind a swap layer): Haiku 5.5 runs the shopping agent and the review copilot (Vercel AI SDK v7, with tool approval for capture and void) and writes each decision's rationale (LangChain); Sonnet 5.5 drafts dispute evidence. The backend recomputes the policy from the stored receipts and rejects any decision the policy didn't make.
  • Render: seven services on one private network: web (Next.js 16), backend (FastAPI), Postgres, three private member services and a Render Workflow that runs each order's check, decision and PayPal action with retries and durable runs.
  • Quality: 134 automated tests on SQLite and Postgres in CI, hosted persona runs that drive the real PayPal pop-up, and an hourly synthetic check (including one AI call) that emails on failure.

The code, tests and docs were written with Claude Code (Claude Opus 5.5) under my direction.

Challenges we ran into

  • PayPal's dispute stages. A new "item not received" dispute starts as an inquiry that accepts only tracking information, so PayPal refused our first evidence note. The console now reads what PayPal is asking for and explains when a note can't be sent, instead of sending something PayPal will reject. After escalation to a claim, PayPal accepted the reviewer's note.
  • A cut-off AI draft. The first live dispute draft stopped mid-word. We raised the output limit and made any draft that hits the limit fall back to a template; the next live dispute produced a complete draft.
  • PSI speed. The SDK's PSI is pure Python and grows with list size (about 2.7 ms per entry per session, measured), so the demo lists hold about 300 entries each and we run the 9 sessions at once.
  • A silent outage. When the demo's AI budget ran out, every health check stayed green while the shop's chat failed. The hourly check now asks the shopping agent one question and fails if it doesn't answer.

Accomplishments that we're proud of

  • Every PayPal call on screen is real sandbox traffic, end to end: approve, authorise, capture or void, webhooks and dispute evidence.
  • Privacy claims are specific: each order shows exactly what each party sent, learned and never saw.
  • In six hosted runs over two days, all 18 persona orders came out right, each with 9 of 9 receipts verified (measured).
  • The AI is useful but never in charge of money: a fixed policy decides, and the copilot moves funds only after a person approves a signed card.

What we learned

We learned that privacy-preserving fraud signals still need careful interpretation: matches indicate risk, not proof of fraud. PayPal's separate approval, authorisation and capture stages let us demonstrate a fixed policy (proceed with no matches, hold one match for human review, and decline two or more) with AI explaining the results rather than choosing the outcome.

What's next for Quiet Check

  • Count-only results, so the checking merchant learns how many members matched rather than which ones.
  • Member-signed PSI replies and real proofs as AP3 adds them (its proof fields are placeholders in the research preview today).
  • Plug in external buying agents through PayPal Agent Ready, ACP or UCP once access opens; the merchant side stays the same.
  • Larger lists, as faster PSI implementations arrive.

Built With

  • a2a
  • anthropic
  • ap3
  • claude
  • elevenlabs
  • fastapi
  • github-actions
  • langchain
  • next.js
  • paypal
  • paypal-disputes-api
  • paypal-js-sdk
  • paypal-orders-api
  • paypal-payments-api
  • paypal-webhooks
  • playwright
  • postgresql
  • python
  • react
  • render
  • render-workflows
  • sqlalchemy
  • tailwind-css
  • typescript
  • vercel-ai-sdk
Share this project:

Updates

Submission history