Agent Proceed

AI agents pay with PayPal, but nothing checks they bought what the shopper asked for. Agent Proceed build verifies agent orders before they ship, and turns the receipt into PayPal dispute evidence.

Comment

Inspiration

I spent 13 years in Trust and Safety at a major e-commerce marketplace, including owning the US Refunds program, where I decided which refunds were instant-approved, held, or investigated. I kept coming back to the same gap: agents can now pay with PayPal, but nothing checks whether they bought what the shopper actually asked for. The payment rails — Visa's Trusted Agent Protocol, Mastercard Agent Pay, Google AP2, OpenAI and Stripe's ACP, Google UCP, PayPal Agent Ready — all solve how the agent pays. None of them checks whether the order is right, and none of them helps the merchant when it isn't. The merchant pays for the mistake, in chargebacks, and is blind to it until the dispute arrives. That is the product I built.

What it does

Agent Proceed is a trust layer for merchants, built around two highlights and two add-ons. Agent Receipt - Every agent order is verified against the shopper's own rules before it ships, and the verdict is Pass, Review Required, or Hold for Suspicion. The verification is sealed into a hash-chained, Ed25519-signed receipt, and the receipt's seal is written into the PayPal order's custom_id, so the proof travels with the payment itself. Anyone can verify a receipt against the published public key, and the receipt can be exported as a signed AP2 mandate.

*Dispute Evidence * - When a bad order becomes a dispute, the receipt becomes the evidence. One click builds the evidence packet from the sealed receipt and submits it to PayPal through the provide-evidence API. I proved this live in the PayPal sandbox: for order 15016, a $370.83 SNAD dispute, the packet (receipt AR-2026-0059, evidence type ITEM_DESCRIPTION) was accepted on the first try, and the dispute moved to under review. A webhook intake is built for CUSTOMER.DISPUTE.CREATED, UPDATED, and RESOLVED; it verifies each event's signature and auto-creates or updates the dispute record, so the merchant's view stays current as PayPal updates the case.

Activity Map (add-on) - A live view of every agent order, so the merchant can see agent activity as it happens instead of discovering it in a chargeback report.

Listing Optimizer (add-on) - It reads a listing the way an agent reads it, scores it on a five-factor framework, and rewrites the parts that mislead agents, so the same mistake doesn't recur. Misleading listings put the wrong product in front of agents 8 times out of 10.

How I built it

The stack is React 18 and Vite on the front end, Supabase (Postgres plus edge functions) on the back end, TypeScript throughout, Tailwind for styling, and Vitest for tests — 383 tests passing. Muse Spark is the LLM across the solution. It powers the verifying agent, the auditor that reads the shopper's rules and the order and returns the verdict. It powers the Listing Optimizer, which reads a listing as an agent would. The shopper agent in the demo is a simulation; the verifying agent is the real product. For the evaluation, I deliberately did not use the production model: the eval runner drives the real auditor through a deterministic rules reader, so the results are reproducible.

The PayPal work is all live in the sandbox. Orders and captures are created through the PayPal API, disputes are filed by the buyer in the Resolution Center (PayPal does not let disputes be created by API), and my edge function submits evidence through the provide-evidence API, reading the available actions from each dispute's HATEOAS links so it only offers what PayPal actually allows. The receipt seal is an Ed25519 signature over the receipt hash, written into the order's custom_id as ap1:sha256:; the private key lives only in a Supabase secret, and the public key is published for anyone to verify. The AP2 export maps the receipt to a v0.2 mandate and signs it as a compact JWS with EdDSA, reusing the same merchant key.

The build draws on the protocols I studied, Visa's Trusted Agent Protocol, Mastercard Agent Pay, Google AP2, OpenAI and Stripe's ACP, Google UCP, and PayPal Agent Ready, and on the standards the agent web already runs on, including Schema.org markup for the listings the Optimizer reads.

I evaluated the verdict on 15 labeled cases drawn from the live Northwind catalog: 5 Pass, 6 Review Required, 4 Hold for Suspicion. The verdict caught all 10 bad orders (miss rate 0.0%, versus 100% for a baseline that ships everything), prevented 10 chargebacks, flagged none of the 5 good orders (false-hold rate 0.0%), and got the exact verdict right on 12 of 15 (80.0% accuracy, versus 33.3% baseline). Receipt integrity held on 14 of 15; the one failure is by design, a case where the record was edited after sealing, which the hash chain correctly caught and which the verdict correctly held.

Challenges

Three product decisions were hard. First, the verdict may only use parameters the shopper actually specified; anything unspecified is skipped, never counted as a mismatch, because penalizing a merchant for a rule the shopper never set would be wrong. Second, separating decision-grade attributes (budget, category, seller, returns) from noise in a listing. Third, there is no agent-experience-optimization standard, so I built my own framework for how an agent reads and ranks a listing.

The PayPal work had its own honest lesson. For order 15010, an INR dispute over a $509.95 Burton order that was flagged Review Required and never shipped, PayPal rejected the evidence eight times: an INR dispute only accepts shipment tracking or proof of refund, and the receipt is neither. The system correctly refused to send the receipt as proof of fulfillment for an order that was never fulfilled. That case is still open, and it stays in the demo as the honest limit.

The eval also surfaced a calibration question I have not settled: three cases that should have been Hold (far over budget, wrong category, unknown seller) came back Review Required. They were still stopped before shipping, so the outcome is the same and only the severity differs. Whether those should escalate to Hold is an open product decision.

What I learned

Payment rails alone will not drive adoption. The blocker is trust: 65% of people trust AI to compare prices, only 14% trust it to place an order. The merchant will not adopt agentic commerce until someone can prove, before shipping, that the order is right, and prove, at dispute time, what was agreed. That proof has to be built at order time, not reconstructed after the fact, which is why the receipt is sealed into the payment itself.

What's next for Agent Proceed

  1. A free pilot with selected merchants to test Agent Optimize.
  2. User sessions with Shopify merchants who have received agent orders, to fine-tune Agent Receipt before building a Shopify app. The goal is all four tools as a Shopify app, plus a public API for Agent Receipt for merchants outside Shopify.
  3. Expose the four tools as an MCP server, so any Claude commerce agent can verify orders, read agent activity, audit listings, and build dispute evidence through one connection.
  4. Applying to Techstars Finance 2027.

Built With

Share this project:

Updates

Submission history