PayHealth

Evidence prepared before any dispute: PayHealth tells small merchants which evidence to keep for every PayPal sale, then drafts the dispute reply from it for the merchant to approve.

Comment

Inspiration

You shouldn't be unable to collect on a sale simply because your documentation was unavailable. My own PayPal account was permanently restricted following a review, and I received no reason for it. This prompted me to examine why sellers lose money in PayPal disputes. When selling through PayPal, "the item never arrived" is one of the most likely disputes sellers face. A public r/Watches thread notes that a lot of sellers don't document their sales, leaving them defenseless in case of a buyer dispute.

A winning reply is built as the transaction happens, and by the time the dispute arises, this information may no longer be there.

What it does

For every PayPal sale, PayHealth shows a proof checklist, including details like the order tracking number, proof of postage, photos, communications between the buyer and the seller and your shop terms. All seller proofs will be stored, and the tracking number can be submitted directly to PayPal. If a dispute starts, PayHealth gives:

  • An AI summary of the case, clear and simple, with the time remaining.
  • A response based only on the proofs stored by the seller, written by an AI. Without proofs, the code blocks it from being approved or sent.
  • Nothing will be submitted before the seller agrees to do so.
  • Every single step will be logged in the audit trail.

How we built it

PayHealth: A Cloudflare Workers and D1 application developed in TypeScript that leverages the PayPal sandbox to perform actions such as webhook signature verification, Orders v2 (with add tracking), and Disputes v1 (submit evidence). Explanations, risk and evidence scores, and response drafts are created using Claude Haiku 5.5. The application features an event table powered by AG Grid with a "Proof ready" column and includes 47 automated tests. Code development and testing were also performed with the assistance of Claude Code.

Challenges we ran into

PayPal has a webhook simulator, but the events from it cannot be verified. We therefore tag unsigned events as "Simulated" in PayHealth. We were not able to test payment on a Nigerian sandbox business account, so we used a US sandbox account.

The hardest part of the process was understanding that a dispute is not a one-time action. In our real scenario, the dispute turned into a claim, PayPal asked us for evidence again, and the deadline moved earlier. We had to modify our flow to allow PayHealth to write one draft per stage and display the new date.

Accomplishments that we're proud of

On the PayPal sandbox, PayPal accepted our tracking number (HTTP 201), and PayHealth's evidence was accepted both at the time of the first complaint and when the case became a claim (HTTP 200). All of our real PayPal communications passed PayPal's signature validation.

What we learned

Since a dispute can move to a new stage and time, the software must be able to process the second claim too. Moreover, the AI should rely solely on the data the seller has previously provided, and the money security rules should be implemented at the program level.

What's next for PayHealth

Photo and PDF uploads, multiple seller accounts with unique credentials rather than a single demo password, easy-to-understand support on account restrictions, and the ability to test with actual sellers.

Built With

  • 5.5
  • ag
  • anthropic
  • claude
  • cloudflare
  • community
  • d1
  • disputes
  • grid
  • haiku
  • orders-v2
  • paypal-rest-apis-(webhooks
  • sdk
  • typescript
  • v1)
  • vitest
  • workers
  • zod
Share this project:

Updates

Submission history