paypilot-ai

AI shopping assistant with budget checking and PayPal Sandbox checkout. Order status and transaction IDs come from PayPal's Orders v2 API and are shown in order history and the admin dashboard.

Comment

Inspiration

Online shopping has two disconnected halves. First you research: dozens of tabs, comparing specs, worrying about whether the total will fit your budget. Then you pay, in a separate step that knows nothing about the advice you just collected. I wanted to close that gap, so that going from "I need a gift under \$50" to a confirmed payment happens in one flow, and the payment layer is part of the experience instead of a button added at the end.

What it does

PayPilot AI is a full-stack shopping assistant with PayPal Sandbox checkout.

  • AI shopping assistant: describe what you want and your budget in plain language. It recommends products, explains the choice, and keeps the combined price within your limit.
  • Budget assistant: at checkout, it compares your cart total against your budget and suggests cheaper alternatives with a similar rating, with one-click swaps.
  • PayPal checkout: payments run through the PayPal Orders v2 API (create, approve, capture).
  • Order history: each order shows its real PayPal status and transaction ID, taken from PayPal's capture response.
  • Admin dashboard: completed orders, revenue, pending orders, and top products by units sold.

How we built it

  • Backend: Node.js and Express, with a small JSON-file store for orders, so there are no native modules to install.
  • Frontend: plain HTML, CSS, and JavaScript served by the same Express process, so judges run one command with no build step.
  • Payments: the server talks to PayPal's REST API directly (OAuth token, create order, capture order). The browser uses the PayPal JS SDK only for the approval popup. The secret key never reaches the browser.
  • AI layer: an LLM call recommends products from the catalog, with a rule-based fallback (keyword matching plus budget filtering) so the app still works if the API is slow or unavailable.
  • Budget logic: deterministic code, not the model. For cart items with price $p_i$ and quantity $q_i$, and budget $B$, the app checks

$$T = \sum_{i} p_i\, q_i \le B$$

and, when it is over budget, looks for a swap $i \to j$ in the same category with

$$p_j < p_i \quad \text{and} \quad r_j \ge r_i - 0.5$$

where $r$ is the product rating. The saving from each swap is $s_i = (p_i - p_j)\,q_i$, so the maximum reachable total is $T - \sum_i s_i$.

Challenges we ran into

  • Making PayPal central, not decorative. A PayPal button on top of an AI chatbot is easy. The harder design question was making payment data drive the product, so order status, transaction IDs, and admin revenue all come from PayPal's real capture response.
  • Never trusting the browser with money. The cart lives in the browser, so a user could edit prices. The server therefore recalculates the total from catalog prices before creating the PayPal order.
  • Keeping the AI honest about numbers. Language models can get arithmetic and budget limits wrong. I moved all the math into deterministic code, validated the model's picks against the catalog and the budget, and fall back to the rule-based recommender if they fail.
  • Setup failures. My first version used a native SQLite module, which failed to install on some Node versions and operating systems. I replaced it with a JSON-file store so the project needs only express and dotenv.
  • Configuration errors that look like bugs. A missing or misnamed .env file produced confusing failures, so the app now detects missing keys at startup and shows clear messages on the page.

Accomplishments that we're proud of

  • A complete flow from natural-language request to a captured sandbox payment and a saved order, using PayPal's Orders API end to end.
  • A server-side total that cannot be tampered with from the browser.
  • A demo that still works when the LLM is unavailable, because of the fallback recommender.
  • A repo that runs with npm install and npm start, with readable errors when something is misconfigured.

What we learned

  • How the PayPal Orders v2 flow works in practice: OAuth, creating an order, buyer approval, and server-side capture, and why the capture response is the source of truth for payment status.
  • Why money logic belongs in deterministic code, with the LLM limited to explaining and choosing among valid options.
  • How much setup friction matters. Removing a native dependency made the project far more likely to run on a stranger's machine.
  • Designing fallbacks and error messages early saves more time than debugging later.

What's next for paypilot-ai

  • Saved payment methods with PayPal Vault for repeat purchases
  • Refunds and order management from the admin dashboard
  • Webhook-based payment status updates, so orders update even if the buyer closes the tab
  • Multi-currency support and a larger, real product catalog
  • A conversational cart: "swap the headphones for something cheaper" handled directly in chat
Share this project:

Updates

Submission history