UNHOLD

Predicts which PayPal payments will get held, before they do, and fixes the cause while it is still cheap.
One Render Blueprint, two services: the Unhold web app and the Render Workflows service.
Code decides the scores and allowed fixes, the AI explains them, and the seller approves anything that moves money.
preventionScan fans out scoreShop, rootCauseForSku and forecastGrowth as parallel tasks with automatic retries.
Every open order gets a transparent hold-risk score, with the factors behind it and the money at risk.
The deep prevention scan tests every combination of fixes against 1x to 3x sales and finds the product behind refunds.
Each risk factor shows its source, verified PayPal data or simulated history, next to the raw PayPal order.
The agent uploads tracking to PayPal and queues refunds for late orders. Refunds run only after the seller approves.

Inspiration

Read PayPal's community forums, Shopify's forums or Hacker News and one complaint keeps coming back: "my funds are on hold and PayPal tells me nothing except I have to wait." For a small seller, a hold can mean not restocking or not paying rent. Tools that explain a hold after it happens are useful, but by then the money is already stuck. We asked a different question: can an agent see the hold coming, and remove its cause first?

What it does

Unhold is a seller-side agent for PayPal merchants.

Prevent. Every open order gets a transparent hold-risk score (0 to 100) with its top factors: no tracking on PayPal, unshipped for 9 days, a sales spike, a high-ticket order, a product with a refund rate 3.6 times the shop average. An account-level forecast warns when the refund pace will cross a limitation-risk line.
Plan. A deep prevention scan tests every combination of fixes against sales growth (1x to 3x) and shows which fixes keep the shop out of the high-risk zone. It runs as parallel tasks on Render Workflows.
Diagnose. The model explains each score in plain English and finds the product behind rising refunds from buyers' own notes. Every quote is checked word for word against the stored notes.
Fix. The agent uploads the seller's tracking to PayPal through the Orders v2 tracking API, which PayPal says releases holds about a day after confirmed delivery. It proposes refunds on late orders before they become disputes, but money only moves after the seller's one-click approval.
Prove. The score is recomputed after the fixes (66 to 43 in the demo shop, money at high risk $1,180 to $0), and every proposal, approval and PayPal response lands in an append-only audit log.

How we built it

Code decides, the model explains. A deterministic rules engine (risk.js) computes every score and the only fix allowed per order. The model (gpt-oss-120b on Groq, using tool calling) reads the assessment, the shipping export, the refund notes and the disputes, then explains scores, finds root causes, drafts buyer messages and calls the fixes. It cannot invent a tracking number, change a refund amount, or act on an order the rules did not flag: the server rejects those calls.
PayPal REST APIs (sandbox): OAuth 2.0, Orders v2 (create, capture, get), Order Tracking (POST /v2/checkout/orders/{id}/track), Payments v2 refunds (POST /v2/payments/captures/{id}/refund) and Disputes.
Safety: each refund approval is bound to a SHA-256 of {order, capture, amount}, is single-use, and is re-checked before PayPal is called. Refunds carry a PayPal-Request-Id for idempotency.
Render and Render Workflows: the web app runs on Render. The deep scan is a Render Workflow: preventionScan fans out scoreShop, one rootCauseForSku per problem product (model calls retried with exponential backoff, which absorbs rate limits) and one forecastGrowth per growth level, each on its own instance. Both services are defined in one render.yaml Blueprint.
Frontend: plain HTML, CSS and JavaScript with hand-drawn SVG charts, streamed live over Server-Sent Events.

Challenges we ran into

PayPal's hold reasons are not exposed by any API, and the sandbox never withholds money. We made the score a transparent heuristic grounded in PayPal's public guidance, labelled simulated holds and history clearly, and kept every PayPal action a real API call.
Deciding what the model may decide. We moved every number and every money decision into code, and gave the model the jobs it is good at: explaining, clustering complaints, and writing.
Open models sometimes skip a step or mistype an ID. The server-side policy gate turned those into harmless rejected calls, and the agent retries correctly.
Creating a PayPal developer account from our region was difficult, so Unhold also ships a clearly labelled offline mock of the PayPal endpoints it uses. Adding sandbox keys switches every call to the real sandbox.

Accomplishments that we're proud of

An agent that changes state in PayPal (tracking, refunds) inside hard guardrails, with an audit trail of every step.
A forecast that answers a real planning question: if sales double, which fixes keep me safe?
Policy guardrails proven in testing: invented tracking numbers, wrong order IDs and made-up evidence quotes are all rejected.

What we learned

Agentic commerce is not only about agents that buy things. A big opportunity is agents that do the unglamorous work that keeps sellers paid, as long as the money decisions are made in code and the human holds the keys.

What's next for Unhold

Webhook-driven live scoring (PAYMENT.CAPTURE.COMPLETED, CUSTOMER.DISPUTE.CREATED) and a nightly prevention scan.
Shopify, Etsy and eBay fulfillment connectors, and calibrating the heuristic against real hold outcomes.
For PayPal: a "Seller Health" agent inside the PayPal Business app, to cut support contacts, reduce surprise holds and keep small sellers.

Honest notes

Unhold infers likely hold risk from the seller's own order, refund and dispute data using a transparent heuristic. It does not know or influence PayPal's internal risk decisions. Holds and the 30-day history in the demo are simulated because the PayPal sandbox does not withhold funds. Every action that moves money needs the seller's approval.