Inspiration
Freelancers and small sellers constantly receive "I paid you" claims — screenshots, emails, confident messages. Screenshots can be faked, and checking each claim by hand inside PayPal is slow and error-prone. We wanted an agent that checks the claim against PayPal itself and answers with evidence, not vibes.
What it does
PaidCheck takes a pasted payment claim ("Paid $180 for the logo design, transaction from John"), parses it into structured fields (amount, currency, payer, date window, item, transaction reference), then verifies it against the seller's PayPal account through the PayPal APIs. It issues a verification memo with one of five verdicts:
- MATCHED — a real PayPal transaction matches the claim.
- PARTIAL — a transaction exists but amount, currency, or payer differs (including digit-transposition suspicion).
- NOT FOUND — the search succeeded and no matching transaction exists.
- DUPLICATE — the same transaction was already claimed before (tracked in a local claims ledger).
- UNCONFIRMED — the PayPal API could not be checked (error recorded in the memo), which is never silently reported as "not found".
How we built it
Python, standard library first. A PayPal client (OAuth client-credentials with token caching, Orders v2, Payments/captures, Payouts, Transaction Search) feeds a deterministic claim parser (rules/regex; an optional LLM parser can be enabled to fill gaps, off by default) and a matching engine that renders an HTML/Markdown memo. Duplicate detection uses a small SQLite ledger. The demo runs against the PayPal sandbox with the default sandbox test accounts; a seeded $180.00 USD order was approved and captured end-to-end and PaidCheck verified it as MATCHED.
Two real engineering findings along the way: (1) PayPal's token endpoint returns a cached general token WITHOUT the reporting scope unless the token request explicitly carries the scope parameter — the client now requests a separately-scoped token for Transaction Search; (2) in the sandbox, Transaction Search v1 works while v2 returns 404, so the client uses v1. Both are documented in the repo (SEEDING.md).
Challenges we ran into
Sandbox sessions expire quickly, capture requires a buyer-approved checkout (a created order is not a payment), and fresh captures are not indexed by Transaction Search immediately — the direct capture lookup covers that gap. Each failure mode is surfaced honestly in the memo rather than hidden.
Accomplishments that we're proud of
A working end-to-end verification on a real (sandbox) completed payment, five honest verdicts including UNCONFIRMED, 50 automated tests, and a repo a judge can run in minutes with the sandbox test accounts.
What we learned
Payment "proof" is a data problem, not a screenshot problem — and API platforms have sharp edges (token caching, version behaviour, indexing lag) that only appear when you integrate for real.
What's next for PaidCheck
Disputes API integration, hosted demo with per-merchant connections, and batch claim checking for seller inboxes.
Tools and disclosure
PaidCheck was designed and built with an AI agent (MOSE, powered by Muse Spark by Meta) working under the direction of the entrant, ledger-scout1, who owns the accounts, performed the live sandbox steps, and reviewed the results. In the product itself, claim parsing is deterministic by default; AI assistance is an optional, clearly-flagged parser fallback.
Log in or sign up for Devpost to join the conversation.