Inspiration
Small merchants get suspicious orders all the time and face a bad choice: ship it and risk a chargeback, or cancel it and lose a real customer. Most tools give them a bare risk score with no explanation and no way to act on it. I come from an accounting background and have worked on tools for small businesses, so I wanted something a shop owner could read and act on in seconds.
What it does
CashGuard scores each incoming order, explains the score in plain English, and lets the merchant capture or void the payment with one click. Orders are created in the PayPal sandbox with the AUTHORIZE intent, so the money is held but not taken. A logistic regression model estimates fraud risk from five signals: amount, account age, billing/shipping mismatch, hour of day and orders in the last hour. Below 30% it suggests CAPTURE, 30-70% REVIEW, and 70% or more VOID. Gemini turns the model's top risk factors into two short sentences, and the prompt only allows factors the model actually found. The merchant decides: the buttons call PayPal's capture and void APIs and show the real response. In REVIEW cases the payment simply stays on hold until the merchant chooses.
How I built it
- Python and Streamlit for the dashboard
- PayPal Orders v2 (create, authorize) and Payments v2 (capture, void) in the sandbox
- scikit-learn logistic regression on 3,000 synthetic orders (accuracy 0.83, AUC 0.81 on a held-out split, which shows the model learned the rules built into the synthetic data, not real-world fraud detection)
- Gemini API for explanations, with a model fallback list, saved explanations, and a template fallback if no model responds
- A setup script that creates three held orders so anyone can run the demo with their own sandbox account
Challenges
- Gemini availability: some models returned 404 for my key and another returned 503 during high demand. I built a fallback list, saved each explanation after the first success, and added a template fallback so the demo never breaks.
- Explanations that were technically true but misleading: the model's hour-of-day effect is weak, so it flagged an 11am order as "unusual time". I fixed it by only listing factors with a meaningful contribution.
- PayPal's flow needs the buyer to approve each order, so I wrote a setup script that creates the orders, waits for approval, authorizes them and saves the results.
What I learned
The authorize, capture and void lifecycle, how to keep an LLM honest by giving it only the model's real factors, and how much of a good demo is reliability.
What's next
Invoice late-payment prediction with reminders sent through PayPal, and a cash-flow forecast combining captured orders with expected invoice payments. I planned these but cut them to ship a complete fraud workflow.
