When an AI agent buys on someone's behalf, the merchant's own agent privately checks the buyer against other merchants' fraud lists, then uses PayPal to capture, hold or decline the payment. No merchant ever shares its list.
9private checks per order: 3 identifiers × 3 merchants
14–18 sbuyer approval to final decision, hosted
0list entries that ever leave their owner
134automated tests, plus live sandbox runs
Basis tags: measured we ran it and timed it · documented from a cited source · our assessment reasoned, not yet proven.
The problem
Agents buy with fewer signals, and merchants fight fraud alone
A purchase made by an AI agent arrives without most of what fraud tools read: no mouse movement, no typing rhythm, no browsing path. Industry reporting from MPE 2026 says agentic transactions strip away the behavioural markers current tools rely on documented[1], and that fraud liability for agent pilots is still unclear documented[2].
What still identifies a repeat abuser is the plain stuff: email, shipping address, device. The merchant down the road may already have this buyer on its chargeback list. But merchants can't hand customer lists to competitors. Privacy law limits sharing personal data to what is necessary and proportionate documented[3], and a list is a commercial asset.
Why it isn't possible today
Sharing means pooling, and pooling means trusting a third party
Fraud networks work by pooling. Today's shared fraud intelligence runs through a vendor that receives every member's data and sees all of it. Merchants who won't or can't send customer data to a central party are left out. our assessment
Hashing the lists doesn't fix it. Emails and addresses are guessable, so a hashed list can be reversed by hashing candidate values and comparing. Swapping hashed lists still leaks the list. our assessment
Agent-to-agent private computation is brand new. AP3, the open protocol that lets agents from different companies compute on private data without revealing it, was contributed by Silence Laboratories to LF Decentralized Trust and is in research preview documented[4][5].
PayPal's agent checkout is gated. Agent Ready brings PayPal's fraud tools to agent-initiated payments, but access is by request and runs through Braintree, with no public sandbox documented[6][7]. Nothing gives a merchant its own pre-authorisation check that draws on other merchants' data.
What we built
One order, start to finish
1 · Shop
An agent buys
The 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. The buyer approves in the PayPal pop-up.
2 · Check
Nine private questions
The merchant's risk agent asks three consortium merchants whether they hold the buyer's email, address or device. Each answer is a yes or no from AP3 private set intersection. Each merchant learns nothing about the query, and every session is recorded as a signed receipt.
3 · Decide
A fixed rule, explained by AI
0 hits: authorise and capture. 1 hit: authorise only and hold for review. 2 or more: don't authorise. Claude writes a 2–3 sentence explanation. It can explain the decision but never change it.
4 · Review
A human closes the hold
In the merchant console the reviewer sees the receipts, a 3×3 hit grid and a "who saw what" panel. They ask the copilot about the hold, and on their instruction plus one Approve click it captures or voids the payment in PayPal.
The three demo buyers
Same shop, same item, three outcomes
All data is synthetic: each member merchant holds about 300 entries, with the personas seeded on purpose. Results below are from three back-to-back hosted runs on 2026-10-14; all 9 orders came out right measured.
Ana
Captured
A
B
C
email
·
·
·
address
·
·
·
device
·
·
·
0 hits. Paid in one step. Buyer sees "Paid".
Ben
Held
A
B
C
email
·
hit
·
address
·
·
·
device
·
·
·
1 hit. Funds authorised and held, not taken. A reviewer decides. Buyer sees "Payment on hold for review".
Cy
Blocked
A
B
C
email
hit
·
hit
address
·
·
·
device
hit
·
hit
4 hits. Never authorised, so no money moves. Buyer sees "We couldn't complete this order".
Who it's for
Who uses it, and what each gets
The merchant
Users: the merchant's risk agent runs every order automatically. A fraud reviewer works the console.
A fraud signal drawn from other merchants' experience, before any money moves.
When a buyer disputes a payment, a drafted evidence note citing the signed receipts, ready to edit and send to PayPal.
Three graded outcomes instead of pass/fail, so a single weak signal costs a review, not a lost sale.
A signed receipt for every check, ready as evidence if the order is disputed.
our assessment
Consortium members
Users: other merchants who run a member agent next to their own abuse list.
They help stop fraud without giving up their list, and never learn who was asked about.
Each publishes a signed commitment to its list (size, format, digest), so the checking merchant knows which list answered.
The same fraud protection comes back to them as initiators.
our assessment
PayPal
PayPal's role: the payment rail that carries out the decision.
PayPal's stated stance in agentic commerce is to be the trusted execution layer whichever agent protocol wins documented[8]. Quiet Check gives merchants a reason to trust agent orders on PayPal.
Authorise-then-capture puts PayPal's hold, capture and void at the centre of the merchant's risk flow.
Fewer fraudulent captures should mean fewer disputes and chargebacks to handle. our assessment
PayPal could host the consortium directory as a service for its merchants. our assessment
The consumer
The buyer, or the person whose agent is buying.
Honest buyers pay at once. Ana's order is captured in seconds with no extra step measured.
One stray signal holds the payment for a human instead of declining it outright.
Their email, address and device are never sent in readable form to other merchants. Only blinded values cross the wire.
A stolen account used by someone else's agent is more likely to be stopped. our assessment
What it's worth
Trust, cost and conversion, where agent commerce is weakest
Industry numbers show where the pain is. Quiet Check is built to move each one; how much it moves them in production is not yet measured.
Trust
55% of US and UK consumers are uncomfortable letting an AI agent buy for them, and 54% think AI could raise fraud risk documented[9].
Quiet Check: every agent order gets a peer fraud check before money moves, and every decision has a signed, verifiable receipt. Buyers' details never reach other merchants in readable form. Trust in agent checkout is what PayPal needs for agent volume to grow our assessment.
Cost
$4.61 is what each $1 of fraud costs a US retail or ecommerce merchant once chargebacks, fees, labour and replacement goods are counted documented[10].
Quiet Check: a blocked order is never authorised, so no capture, refund or chargeback follows. Manual review is spent only on single-hit orders, and when a buyer disputes, the AI drafts evidence from the signed receipts for a person to send to PayPal. Whether that wins more disputes is our assessment, not yet measured.
Conversion
32% of US consumers say they stop shopping with a merchant after being declined documented[11]. False declines cost US merchants more than card fraud itself, by Javelin's estimate documented[11].
Quiet Check: one weak signal holds the funds for a human instead of declining. Clean buyers are captured in seconds with no extra step measured. Fewer false declines should keep more good customers coming back our assessment.
Network effect for PayPal
PayPal aims to be the trusted execution layer for agent payments, whichever protocol wins documented[8].
Quiet Check: each merchant that joins makes the check better for every other, and the action at the end is always a PayPal authorise, capture or void. PayPal could run the consortium directory without ever holding a member's list our assessment.
PayPal integration
Real sandbox calls, end to end
Every PayPal call in the demo hits the live sandbox. Nothing on screen is mocked.
PayPal piece
What we use it for
JS SDK v6
Buyer approval in the PayPal pop-up, started from the agent's order
Orders v2
Create with intent AUTHORIZE (priced by our backend, never the agent); read payer email and shipping after approval; authorise
Payments v2
Capture a clean order; capture or void a held one on the reviewer's instruction
Webhooks
CHECKOUT.ORDER.APPROVED starts the risk agent; signatures verified, events deduped
Idempotency
PayPal-Request-Id on every money-moving call, so retries can't double-charge
Honour period
The console counts down PayPal's 3-day window for capturing a hold
Disputes v1
A buyer's dispute arrives by webhook; the AI drafts evidence from the signed receipts and decision log; a reviewer edits and submits it with provide-evidence
Silence Laboratories integration
AP3 private set intersection
The consortium runs on the open-source AP3 SDK (ap3[a2a], ap3-functions 1.2.2), Silence Laboratories' protocol for privacy-preserving work between agents documented[4].
AP3 piece
What we use it for
A2A agents
Members A, B and C are separate A2A servers, each holding only its own list
AgentCards
Roles (initiator, receiver) and each member's signed commitment to its list
PSI
9 sessions per order, run at once: "is this value in your set?", answered yes or no
Directives
Each session's signed intents are captured; receipts are verified before they are stored
Who saw what
The console states plainly what each party learned
Where the AI works
AI does the talking, a rule moves the money
Shopping agent (Claude Haiku 5.5, Vercel AI SDK): turns a sentence into a search, a cart and a PayPal order in one turn.
Risk rationale (Claude Haiku 5.5, LangChain): explains each decision in 2–3 sentences from the hit summary only, never from raw lists. If the model fails, a template stands in.
Review copilot (Claude Haiku 5.5): answers "why is this on hold?" and captures or voids, but only after the reviewer clicks Approve on a card showing the order, amount and action.
Dispute evidence (Claude Sonnet 5.5): when a buyer disputes a payment, it drafts the merchant's evidence from the receipts, the decision and the PayPal timeline, without seeing the buyer's email, address or device. A person edits and submits it.
Guardrail: the backend recomputes the policy from the stored receipts and rejects any decision the policy didn't make. Models sit behind a swap layer; a swap to Sonnet was tested live measured.
Unique selling propositionFraud intelligence from your peers, before you take the money, without anyone handing over a list.
What's new is the combination: cryptographic privacy between competing merchants, an agent-native protocol (AP3 over A2A), PayPal's authorise-hold-capture turned into graded outcomes, and a signed audit trail for every decision. The AI explains and assists but can't move money on its own. We know of no shipping product that does this for agent-initiated payments our assessment.
Architecture
Seven pieces on Render, one private network
Only the shop and the backend are public. The backend accepts unauthenticated calls only for health, PayPal's signed webhooks and the order status; everything else needs a token. Members are private services that answer only the backend's AP3 initiator.
flowchart LR
buyer([Buyer]) --> web
reviewer([Fraud reviewer]) --> web
subgraph render [Render · private network · oregon]
web["Web · Next.js shop + shopping agent console + review copilot"]
backend["Backend · FastAPI risk agent · policy · payments AP3 initiator :8100"]
wf["Render Workflow process_order task retries, durable runs"]
db[("Postgres orders · checks · receipts decisions · events")]
a["Member A own list"]
b["Member B own list"]
c["Member C own list"]
web -->|token| backend
backend -->|start run| wf
wf -->|/merchant/process| backend
backend --- db
backend <-->|AP3 PSI| a
backend <-->|AP3 PSI| b
backend <-->|AP3 PSI| c
end
web -.->|JS SDK v6 pop-up| paypal
backend <-->|Orders v2 · Payments v2| paypal[(PayPal sandbox)]
paypal -->|signed webhooks| backend
web -->|AI SDK| claude[(Claude API)]
backend -->|LangChain| claude
Layer
Choice
Backend
Python 3.12, FastAPI, SQLAlchemy Core; SQLite locally, Postgres on Render
Consortium
AP3 SDK 1.2.2; three member agents as Render private services
Web
Next.js 16, React 19, Tailwind 4, Vercel AI SDK v7
Orchestration
Render Workflows runs each order's check → decide → PayPal action, with retries; an in-process fallback takes over within 45 s if a run stalls
Operations
Deep health check (database, each member's list digest, workflow); a sweep reruns orders stuck mid-check; hourly synthetic check with failure email
Evidence it works
Tested on the hosted build, including when things break
Persona runs: Ana, Ben and Cy through the real shop and PayPal pop-up, driven by a browser script. Every order had 9 of 9 receipts verified and an AI rationale measured.
Speed: about 9–11 s from the start of the risk run to the decision; 14–18 s from the buyer's approval measured.
Failure drills, all passed: a member taken offline (order fails safe, then reruns to the right answer), a broken workflow token (fallback decides), a bad AI key (template rationale), PayPal webhooks rejected (the pop-up path alone decides), a redeploy mid-order (no order lost), and the chat rate limit measured.
Privacy check in CI: every test run's logs are scanned and the build fails if any list entry or test identifier appears measured.
Limits
What this demo doesn't claim
AP3 is a research preview: its proof fields are placeholders, and PSI is the only operation in the public SDK.
PSI tells the checking merchant which member matched which field. The console says so; "count only" is future work.
PSI alone doesn't prove a member used the list it committed to.
Receipts are signed by the checking merchant. In AP3 1.2.2 members sign only their commitment.
Agent Ready, ACP and UCP are gated, so our shopping agent stands in for them. The merchant side would be the same.
Sandbox only, USD only, synthetic data. Several judges approving at the same moment can each wait up to about 40 s, because members' PSI is CPU-bound measured.
Sources
The Paypers, "Key takeaways from MPE 2026": thepaypers.com
LexisNexis Risk Solutions, True Cost of Fraud: Ecommerce and Retail, 2025 (survey of 569 executives): risk.lexisnexis.com
Javelin research on false declines (older study; 3,200 US consumers), summarised by PYMNTS and ClearSale
PayPal authorisation rules (29-day hold, 3-day honour period): developer.paypal.com. Measurements come from the project's test log, 2026-10-13 and 2026-10-14.