Inspiration
A small studio buying a website package needs to know what a payment actually covers. Are two landing pages included? Who supplies the copy? Has the quote expired? If checkout times out, did the payment fail—or did only the response disappear?
ScopePay turns that purchase into an explicit, reviewable chain: brief → selected work → fixed quote → approval → PayPal payment → recoverable receipt. This audience and value proposition are hypotheses; real customer validation is still ahead.
What it does
The application asks a configured local AI model to suggest deliverables from a brief, with exact quotations from the source. Suggestions start unselected and unpriced. The reviewer selects the work, checks quantities, enters prices, sets a budget and approval deadline, and approves the fixed quote.
AI cannot price, approve or pay. The server calculates integer cents and binds the approval to the quote, amount and currency. A scope or amount change needs fresh approval. Revocation and expiry block capture before dispatch.
When a capture may already have reached PayPal, a timeout remains Unknown. ScopePay checks the same order rather than treating uncertainty as permission to charge again. A completed payment produces one stored receipt, reused on later checks.
How it was built
Python, FastAPI and Pydantic provide the application and typed contracts. Native JavaScript supplies an English/Chinese browser workspace. SQLite supports a standalone local build; PostgreSQL supports the separately tested shared-storage configuration. Qwen3.5-4B provides optional local suggestions through an OpenAI-compatible endpoint.
PayPal Sandbox OAuth and Orders v2 are central to checkout. Before accepting a payment receipt, the server checks the order, recipient merchant, quote identity, currency, amount and completed capture. Durable operation IDs and short database transactions preserve recovery across retries.
The seller is the configured Sandbox merchant. This is not a system for paying arbitrary vendors, and a typed reviewer name is not an authenticated third-party signature.
Challenges and validation
The actual Sandbox returned optional monetary metadata that an overly strict comparison rejected. The fix checks authoritative monetary fields while retaining recipient and quote checks. Recovery reused the saved remote order.
One authorized official Sandbox run completed a USD 1.00 virtual payment: buyer approval, one capture and an independent server query. Repeated checks returned the same receipt. Its scope was entered manually. The demonstration's USD 250 workflow is a separate simulation; it is not the official transaction.
Actual local-model checks and an application request exercised source-grounded suggestions. Earlier interpretation failures are retained: valid JSON and an exact quotation do not prove that a model understood the request. Human review remains part of the product.
What was learned and what's next
A matching total does not prove the right recipient. A timeout does not prove that a side effect failed. A quotation does not prove correct interpretation. These require separate checks.
Next steps are real-user validation and complete judge access. Production payments, live webhooks, refunds, authenticated multiuser hosting and real-provider timeout experiments are not established by this build. The supported application runs locally; deployment is not claimed.
AI assistance
Codex substantially assisted implementation, tests, debugging and documentation. Runtime suggestions use a separate local Qwen model. The demonstration uses MiniMax-generated narration and edited application footage. No unaided authorship, customer adoption or unverified team contribution is claimed.
Built With
- fastapi
- javascript
- paypal
- python
- sqlite
