Inspiration
We started with an obvious question, PayPal sees the product, the merchant, price, delivery, promise the dispute history and what other buyers paid for the same item at different stores. Whereas any card network sees a dollar amount, the bank sees a payment charge.
This creates an interesting problem. When we built our dataset we calibrated the anomaly rates to realistic e commerce patterns and landed on roughly 8% overcharges 15% price drops within a week of purchase and about 5% of requested refunds that never actually come through. These are real numbers that you would see across a network of 50 merchants with varying quality. The thing that made us want to build this is that every one of those is catchable. Introducing Nexus.
What it does
Nexus has two divisions. A buyer side that watches your money before, during, and after every purchase, and a merchant side that turns all of that activity into actionable intelligence.
Buyer side: Better Deal Before You Pay finds a cheaper option for something you are already about to buy. Amy is looking at running insoles for $24 at FootFirst. Nexus finds the same insoles at StrideShop for $18 with a better merchant rating and creates the PayPal order for her automatically.
Save For It lets you set a savings goal and the agent does the rest. Amy wants a $1,200 laptop, saves $100 a week, and the agent watches the price the whole time. When it drops to $1,011 with a coupon code, Nexus surfaces it with Pay in 4 and Pay Monthly options so she does not have to wait.
Post Purchase Guardian scans your recent transactions and catches what nobody else is watching. Amy bought an Instant Pot for $99 and the price dropped to $81 six days later, that is $18 recovered. A $60 jacket was charged at $72.40, flagged and disputed. A refund she requested ten days ago never came through, escalated.
Savings Dashboard is the running total of everything Nexus recovered. Amy recovered $882 across price drops, overcharges, and refunds, all computed from real model output. That number only goes up and it is the reason you open PayPal every day instead of just at checkout.
Merchant side Churn Risk Dashboard shows TechHaven that 97 of their customers are at risk of not coming back, ranked by probability in a sortable and filterable AG Grid table. The merchant sees who is slipping away and how long it has been since their last purchase.
One Click Win Back lets the merchant hit a single button. The AI writes a personalized offer, something like “15% off your next order, Sarah” and PayPal sends it as an invoice.
Cross Sell Intelligence surfaces which products get bought together by the same customers within 30 days. Monitors and HDMI cables at 41%, laptops and laptop bags at 34% each with a suggested bundle discount based on the co purchase rate.
Therefore every buyer transaction feeds the merchant side and every merchant action feeds back into the buyer experience. That is the loop that makes both sides smarter over time.
How we built it
We wrote the API contract before anyone opened an IDE. Three lanes: I took data and models, Koushik handled backend and PayPal integration, Hetav built the frontend.
PayPal Sandbox handles live payments but not the historical dataset we need to train a churn model. So I built a synthetic data generator that produces 50 merchants, 10,000 transactions, 520 products, and 200 coupons with seeded randomness so regenerating gives identical output every time.
I split the models into two categories and was deliberate about labeling them honestly. Price drop detection, overcharge detection, and refund tracking are rules and they compare values to thresholds. The delivery delay predictor and churn predictor are actual trained GradientBoosting models. Delay hits AUC 0.80, churn hits 0.76, both on synthetic data with proper holdout splits. Getting the churn right took the most work because the traditional approach of using days since last purchase as both feature and label gives you AUC 1.0 which means the model learned nothing. We built a tiered churn simulation into the data and trained on a time split where features come from before a cutoff and the label comes from after.
The backend is FastAPI with 20 endpoints. Gemini Flash Lite powers the agent through direct function calling. We planned on 2.0 Flash originally, caught it was retired, moved to 3.8 Flash which timed out, and landed on Flash Lite which has been stable. The frontend is React with Vite, TypeScript, and Tailwind. AG Grid runs the merchant churn table with custom cell renderers, row grouping, filtering, a pinned summary row, and CSV export.
Challenges we ran into
The hardest part was keeping the ML models accurate and honest all times. On synthetic data where you planted the anomalies yourself, you can report any AUC you want. We went the other direction where we added noise, used real splits, removed features that leaked the label, and accepted that the final numbers would be lower than what we could have gamed. The delay model at 0.80 and churn at 0.76 are not flashy but they reflect something the model actually learned.
Coordination across three people building against one API contract caught us a few times. We found early that the same merchant showed up as M001 in one endpoint and M007 in another. If that had gone unnoticed the frontend would have been querying a merchant the backend was not serving and the demo would have broken with no error message to explain why.
Lastly LLM migration was unexpected. Planning around a model that gets retired mid hackathon, switching, having the replacement that time out and switching again is not something you account for on a task board. We lost a few hours to it but caught it before it blocked anyone else.
Accomplishments that we're proud of
What we learned
How to build a pipeline where every number the user sees traces back to a model output and not a hardcoded value. How PayPal Sandbox works for live order and dispute flows. How to wire an AI agent with function calling instead of prompt chains. The difference between a model that learned something and a rule pretending to be one. Also, that writing the API contract first saves more time than any framework choice.
What's next for Nexus by PayPal
With real PayPal transaction data these models train on millions of purchases instead of 10,000 synthetic ones. The Save For It flow integrates Pay in 4 naturally since the agent spotting a deal mid-savings goal is the right moment to offer installments. PayPal gets payment volume and a credit card lead. On the merchant side every win-back outcome feeds the churn model so predictions sharpens over time. The architecture supports all of it so what Nexus needs now is real data with scalability.
Built With
- ag-grid
- faker
- fastapi
- gemini
- mlxtend
- numpy
- pandas
- paypal-sandbox
- pytest
- python
- react
- recharts
- render
- scikit-learn
- tailwind-css
- typescript
- vite
