Inspiration
We focused on a small but concrete merchant question: which orders need attention before the day ends? A checkout status, an amount in a shop record and a completed payment are different facts. Putting them into a calm, understandable review can make discrepancies easier to spot.
What it does
OrderNest compares expected amounts with normalized payment records. It separates matching amounts, waiting orders, exceptions and missing evidence. It holds refunds, different currencies, duplicate references, nonfinal captures and stale reads for review rather than guessing a result. The person can edit expected amounts, enter their own order records and prepare a checklist.
An optional local AI agent selects a bounded sequence of application tools: compare the records, summarize exceptions and draft the checklist. The application calculates the amounts and creates the actual report. The model receives verified aggregate counts rather than customer information or individual order amounts. It cannot create, capture or refund payments, contact customers or authorize fulfilment.
The interface is available in Polish and English. Readable text and JSON reports include source labels and timestamps. Editing input clears the previous result and report links. Unconfirmed refund or currency amounts are explicitly shown as unconfirmed, not as a verified zero.
How we built it
The application uses JavaScript, Node.js and a small local HTTP server, with no installed npm dependencies. Money comparisons use exact minor units for PLN, EUR and USD. Its server-only PayPal Sandbox Orders and Payments API adapter has a fixed Sandbox origin, bounded responses and sanitized errors. It drops payer names, emails, addresses and provider links. Actual authentication and one unpaid-order read were verified. A separate opt-in helper creates the unpaid Sandbox test order; it is not part of the application's read-only review path.
The local AI uses the already available Qwen3-1.7B-Q8_0 model through llama.cpp. A constrained JSON action format, allowed-tool list, cancellation and bounded steps keep the model's role separate from the verified payment facts. The current source package has an MIT licence.
What is verified now
Local model/HTTP cases and the actual Chrome workflow have been verified using illustrative records. The six-order example produces one match, one waiting order and four exceptions. After changing an expected amount from 89 to 60, the old result disappears; the next real AI run produces two matches, one waiting order and three exceptions. Local HTTP downloads of Polish and English reports and JSON have also been verified. A narrow browser viewport was inspected without horizontal overflow. Completion of a download triggered by the automated Chrome control remains unconfirmed.
Actual PayPal Sandbox authentication, a real unpaid 1.00 PLN order read, and the same local-AI workflow in Chrome were also verified. Editing the expected amount cleared the old result; a fresh actual read still showed a waiting order with zero completed captures. Source-labelled actual Sandbox PL/EN/JSON report contents were saved.
October 15 improvement: current capture evidence
Version 0.4 reads each current Payments v2 capture resource before classification, instead of relying only on the capture embedded in the order. It verifies capture identity, currency, gross amount and any related order ID; contradictions or failed reads stop the review. Current refunded or partially refunded statuses stay review cases. It still has no capture, refund or live-money write endpoint. All 48 offline/injected checks passed, including four new capture tests and three checks of a separate read-only acceptance runner. These checks are not actual completed/refunded PayPal transactions. The optional Sprawdz-Scenariusze-Sandbox.cmd runner reads supplied actual order IDs, tests a completed 1.00 PLN capture against both a matching 1.00 PLN and incorrect 2.00 PLN shop record, and leaves unprovided scenarios marked not_run. It does not create or change payments and needs no credentials of its own. The existing video shows the earlier genuine waiting-order workflow, not this update.
A further October 15 startup improvement was verified with the participant: a single Windows console now accepts the Sandbox credentials once, validates OAuth before startup, launches the local server/model, creates or reuses one unpaid 1.00 PLN order and verifies its actual read and AI checklist. An independent HTTP check confirmed the new order as waiting with zero captures. Failed OAuth is distinguished from order creation and does not mark a creation attempt; unclear creation outcomes remain blocked. Keys and private test records are not published.
Current limitations
Actual PayPal Sandbox checks so far cover unpaid waiting orders and the real local model, with zero completed captures. Completed, mismatched and refunded provider cases remain unverified. Source code and complete setup instructions are public under MIT. The English demonstration is a visibly labelled edited montage of genuine application captures with synthetic narration, rather than continuous screen recording. There is no production merchant integration, background order synchronization, refund net calculation, exchange-rate conversion or automatic fulfilment.
What is next
Expand actual Sandbox validation to completed, mismatched and refunded cases, while retaining the clear source and payment-evidence boundaries. Add broader merchant workflows only after confirming their behaviour; no production rollout is claimed.
Running the project
Complete instructions are in the public README. Install Node.js 22.19 or newer, start the local Qwen/llama.cpp runtime, and enter your own Sandbox credentials privately. A separate optional helper creates one unpaid Sandbox order and verifies the review workflow; credentials and tokens are not distributed. The preview HTML contains labelled fixtures, while the actual provider and AI workflow requires the local server.
AI assistance
Built with AI coding assistance. The participant supplied design preferences, feedback and app testing. The runtime model selects bounded tools; exact amounts, reasons and checklist content are generated by deterministic application code.
Log in or sign up for Devpost to join the conversation.