Inspiration
A purchase keeps creating decisions long after checkout: a price drops, a refund takes longer than expected, or a return deadline approaches. Keeping track of everything means searching through receipts, emails, bank transactions, and retailer policies.
We built MoneybackOS around a simple idea: help people find savings hiding in purchases they’ve already made. We wanted to turn scattered purchase records into useful evidence that helps users understand their options and take action.
What it does
MoneybackOS brings purchases, receipts, and recovery opportunities into one dashboard.
Our prototype can:
- Extract purchase details from receipt photos, PDFs, and email text using Gemini.
- Match receipts to Nessie sandbox transactions and identify duplicate evidence.
- Compare product offers using product identity, condition, availability, and shipping costs.
- Flag potential missing refunds, subscription price increases, and billing differences.
- Track return, warranty, and other purchase-related deadlines.
- Create recovery cases with supporting evidence and explicit user approval.
The financial demonstration uses simulated Nessie deposits. It does not initiate real merchant refunds or automatically submit claims.
How we built it
We built a TypeScript monorepo with shared Zod schemas to keep purchase, receipt, offer, and recovery data consistent across modules.
Our Fastify backend and monitoring worker run on Railway, with Tiger Data/PostgreSQL storing financial records, evidence references, and price history. The Next.js and React dashboard is available through a GoDaddy-hosted preview.
We integrated Capital One Nessie for sandbox banking data, Google Gemini for document extraction, and SerpApi and Bright Data for retail evidence. AI interprets documents, while application code validates outputs, calculates amounts in integer cents, and enforces recovery rules.
Our current development scope also includes completing live Auth0 and Gmail verification, adding case and notification history, improving pagination, and introducing opt-in background Gmail monitoring. We are extending receipt evaluation and working toward a complete live retail-to-simulated-refund demonstration.
Challenges we ran into
Connecting a transaction to an exact product was harder than comparing prices. Bank records lack itemized receipts, and similar listings can differ in model, seller, condition, or shipping cost.
We also had to distinguish a possible opportunity from a verified outcome. An equal-value deposit does not prove a refund, and a lower advertised price does not establish eligibility.
Duplicate receipts, repeated imports, and retried jobs made it essential to prevent the same evidence from creating duplicate recoveries.
Deployment introduced another challenge: OAuth callbacks, session cookies, hosting variables, and preview access must align before authentication works reliably.
Accomplishments that we're proud of
We deployed the API and worker, built a responsive dashboard, and verified that private receipt evidence survives backend redeployment.
Our synthetic receipt, duplicate, and policy evaluation passed 15 out of 15 regression expectations.
We also reconciled a $10 simulated Nessie deposit against a controlled billing case through the deployed backend. Repeating reconciliation preserved a single allocation, demonstrating that the recovery was not counted twice.
Our retail checks also rejected incomplete evidence rather than presenting uncertain offers as confirmed savings.
What we learned
We learned that reliable financial automation depends on preserving evidence, representing uncertainty, and making repeated operations safe.
A useful recommendation must explain why an opportunity exists, what remains unverified, and where the user needs to decide.
We also learned to distinguish synthetic tests, live provider checks, and complete workflow verification. Each establishes a different level of confidence.
What's next for MoneybackOS
We want to make MoneybackOS a daily purchase companion through mobile receipt capture and a browser extension for user-approved purchase evidence.
We plan to expand support across retailers and banking providers, then explore merchant integrations that let users submit approved recovery requests directly from their dashboard.
Finally, we want to run a user pilot and measure practical outcomes: verified savings, successful recoveries, time saved, and fewer missed deadlines. Those results will guide which features we build next.
Built With
- auth0
- docker
- fastify
- gemini
- godaddy
- nessie
- next.js
- node.js
- pnpm
- postgresql
- railway
- react
- tiger
- typescript
- vitest
- zod
Log in or sign up for Devpost to join the conversation.