-
-
Proofie: answer a PayPal dispute with checked evidence. You decide.
-
A receipt that disagrees with PayPal's record is shown with both values, before anything is sent.
-
You approve one exact package, bound to its fingerprint. Sending is a separate click, and Proofie sends it once.
-
"Received by PayPal" appears after Proofie reads the dispute back from PayPal's own record.
-
Your AI assistant can read and draft through Proofie's MCP server. It has no tool to approve or to accept a claim.
-
Open a sandbox dispute from the seller side with one command. No buyer account or login needed.
Watch: the video, under 3 minutes · Run it: github.com/Josanoforo/Proofie, then docs/JUDGE-RUN.md · Hosted copy (optional): address and access code are in the testing instructions.
The screens in the video were captured from Proofie by an AI session; the illustrations are drawn in code, and the narration and music are AI-generated.
Built and tested in the PayPal sandbox. Independent project, not affiliated with or endorsed by PayPal.
A small seller gets an "item not received" dispute and a deadline. Proofie lines up her documents against PayPal's record, shows the source of every statement, and sends the version she approves, then reads the dispute back from PayPal to show what its record lists.
A seller answers a dispute by hand, with her evidence scattered
PayPal's US merchant guide says a seller has 10 days to respond to a claim, and that a claim without a response closes in the buyer's favor. PayPal's US fee page lists a standard dispute fee of 15 USD (300 MXN for peso transactions), and its Mexico page lists a chargeback fee of 110 MXN that does not apply when Seller Protection covers the sale.
Public seller posts describe holding tracking and still losing, or not knowing what to send (1, 2, 3). They are anecdotes, not interviews, and they do not tell us how often it happens.
We found no published figure for how often small sellers lose these disputes, so we measured our own case: in the PayPal sandbox on 2026-10-28, one provide-evidence request returned HTTP 200 and PayPal's read-back listed the dispute as UNDER_REVIEW.
Marisol is a composite seller we wrote for this story. She sells handmade ceramics from home in Mexico, and a buyer says the coffee set never arrived. She knows she shipped it, but the tracking number is in one email, the receipt she finds may belong to another order, and she is not sure which documents PayPal will accept.
PayPal's US help centre says PayPal holds the disputed amount while it reviews, and a dispute that is not escalated closes after 20 days and cannot be reopened. Proofie shows the due date PayPal returns for the case, and says "No verified deadline available" when PayPal gives none.
Proofie checks her documents and shows every source
Each statement in the package names its source: a document, a PayPal field, or her own words, labelled as hers.
- A document that disagrees is shown with both values. The page says "Does not match" beside the two values.
- Her documents are checked before anything is sent, against what PayPal's Mexico program publishes (tracking number, delivered status, matching address, signed proof of delivery above a limit) and a few checks of Proofie's own; each check shows which it is.
- A claim without a source is blocked. A delivery statement with no source cannot be asserted, and a conflict must be resolved before approval.
Proofie calls four PayPal sandbox APIs
| PayPal API (sandbox) | What Proofie does with it | Seen in |
|---|---|---|
| Customer Disputes | List and read disputes; provide evidence; send an approved offer or message; accept the claim as the seller's last option; the appeal call (below) | Video 0:30 (the checks), 1:27 (send), 1:38 (read-back), 2:13 (inbox), 2:17 (offer and message), 2:27 (accept-claim page); gallery images 2, 3 and 5 |
| Add Tracking | Register a tracking number after the seller approves the exact request | Video 1:58 (tracking at the sale). Code and test: copilot/features/fulfilment/register.py:23 (POST /v1/shipping/trackers, then a GET read-back of /v1/shipping/trackers?transaction_id=...), the "Tracking at the sale" register route copilot/features/fulfilment/routes.py:425, and tests/features/fulfilment/test_register.py:38-41 |
| Transaction Search | Account counts for the account page, no writes | App: the account page |
| Orders | Create the test purchases behind the demo disputes | Gallery image 5 (the case command creates the sale) |
The PayPal host is fixed to the sandbox in code. Dispute and payment state come from PayPal's responses, never from model text. The appeal call is on; it appears only when PayPal's fresh read offers an appeal, it is sent once after the seller approves the exact request, and it has not been exercised against PayPal.
She approves one package, bound to its exact content
She reads every statement in full beside its source, then gives one approval that names how many statements it covers.
- The approval is bound to a fingerprint (a SHA-256 hash) of that exact package. Change one word and the approval clears.
- There is no approve-all. Approving sends nothing; sending is a separate click.
- The fingerprint shows that the package did not change after approval, not that the documents are authentic.
PayPal's record shows what was sent
Proofie sends once, writes the approval's fingerprint into the request, and reads the dispute back from PayPal with a GET. The page says "Received by PayPal (confirmed by reading the dispute back)", with the time, when PayPal's record lists the same evidence type, tracking number and file names. A name match is not a byte match, and the page says so.
- If the result is uncertain, the case stays pending with a "Check again" button that reads and changes nothing. Proofie never re-sends on its own.
The assistant drafts and the seller decides
A design choice to notice: the assistant has no approve tool.
- The local model drafts; it does not decide. A local model (Ollama) drafts statements from documents. It has no tools, so it cannot call PayPal, approve or send; code checks every number, date and ID, and manual mode works without a model.
- The seller's own AI assistant can read and draft through Proofie's MCP server. The server has read and draft tools, and no approve or accept-claim tool in any configuration. An optional send tool, off by default, sends a package a person already approved and refuses when its fingerprint no longer matches.
- The MCP server was tested with injected orders. A test puts orders to approve, send and accept the claim into buyer messages, documents and drafts: 8 payloads across 6 tools, 0 PayPal writes, 0 approvals, 0 send attempts. The test uses a stand-in model that obeys the text, so it shows what the server allows, not how a real model reacts.
- Proofie helps the seller make their case. If they decide to accept the claim and refund the buyer, they do it themselves, on a check page of its own; Proofie's role is to help them make an informed decision.
Built during the submission period
Proofie was started on October 3, 2026, inside the submission period; the research and all of Proofie's own code were written during the hackathon (third-party packages and PayPal's schema extracts are listed in THIRD-PARTY.md).
Proofie is built with two AI coding agents, Claude Code (Anthropic) and Codex (OpenAI), working from frozen briefs with independent verification steps. Release v1.1.1 (public commit 783cf87b); the video's screens were captured from v1.1.1. Run the tests with the README's command, .\.venv\Scripts\python.exe -m pytest (the offline tests, the default); more than 8,700 automated tests pass. Proofie is open source under the Apache-2.0 licence.
Limits we kept in view
- PayPal sandbox build, synthetic documents. There are no production results of any kind, and we make no claim of win rates, recovered money or time saved. PayPal decides the case; the evidence check is a rule check on the seller's documents, not a prediction of its decision.
- The model is not the judge. On 24 frozen synthetic cases across 3 seeds (2026-10-21), the local model passed every scored check in 52 of 72 runs, and 1 of 9 on contradictory documents. The same sessions wrote the cases and the rules. We make no reliability claim, and a person reviews every send; all failures are published in
docs/AI-USAGE.md. - Accepting a claim is real. On a sandbox case, PayPal showed the refund at once, moved the case to its review and resolved it in the buyer's favour within minutes. That is why the page asks the seller to type the amount and approve the exact request.
- A repeated message is not deduplicated. In the sandbox on 2026-10-16 PayPal did not deduplicate a repeated "send message" call with the same
PayPal-Request-Id, so Proofie checks PayPal's listed messages and its own records before sending. - The judge case is a card-funded sale with a chargeback, a dispute type PayPal's Mexico Seller Protection program excludes. Proofie shows that rule and says nothing about whether protection applies.
- One automated check fails by decision. 10 of 22 pages are three clicks from the case overview; we accepted that trade-off.
- The optional hosted copy is a shared demo: manual mode, an access code, one shared sandbox account, data reset on restart.
- The Mexico rules are context, not legal advice.
What we learned
- Literal validation is not sufficiency: a package can contain nothing false and still show nothing.
- "Absent", "illegible", "not verifiable" and "conflicting" are four different states, and the seller needs to see the difference.
- A local 9B model is useful for extracting and drafting, and not safe to trust without a validator and a person.
What's next
Proofie runs in the PayPal sandbox today. Going live would need a registered PayPal app, each seller's own grant of access and whatever review PayPal asks for; real sellers would come after. Seller Protection rules already live in one dated file per country, each check quoting PayPal's published page: Mexico and the United States ship today, and the installation picks one by setting. Another country is a new rule file, with its quotes and tests, plus one line in the registry. Next we want more of those countries, and dispute reasons beyond "item not received". For PayPal, our aim is that each case arrives organised and checked against its own record; we have not measured the effect on PayPal's review or on the number of disputes. Because a dispute has two sides, we want buyers to follow it too: Proofie already offers an optional status page the seller approves, and next we hope to help buyers see what was sent. We want a better local model, its quality measured and its failures published. Proofie prepares - you decide.
