Inspiration

AI agents are starting to buy things for us: finding vendors, negotiating prices, and checking out. But a payment provider processes the payment request it receives; it doesn't independently know what the user originally agreed to.

Imagine an agent agrees to a service for USD 400, but the amount becomes USD 800 at checkout. Or two agents spend from the same budget simultaneously. Or the same deal gets paid twice.

I wanted to build the missing layer between an agent's decision and the payment:

AI agents negotiate. SpendMesh enforces. PayPal processes.

What it does

SpendMesh AI is a policy enforcement layer for autonomous AI purchasing.

  • Plain-English requests: Users describe what they need and their budget. Google Gemini converts the request into structured requirements.
  • Competing offers: Three simulated seller agents submit bids. Gemini compares the offers and explains its recommendation.
  • Five server-side security gates: Every deal is checked for a valid amount, an allowed service category, available budget, duplicate payment, and the auto-approval threshold.
  • Human approval: Deals above the configured threshold enter an approval queue. No PayPal order is created until a person approves the deal.
  • PayPal Orders v2 Sandbox: The server creates orders using the agreed amount stored in the database, never a browser-supplied amount. After buyer approval, the server captures the payment and verifies the result.
  • Deliverable unlock: Gemini generates the deliverable, which is unlocked only after successful payment capture is verified.
  • Audit trail and Policy Center: Decisions, approvals, blocked attempts, and payment activity are logged. The approval threshold and category whitelist can be adjusted.
  • Security Guide: An optional voice and text assistant explains the workflow and helps users navigate the application. It cannot approve deals or bypass security gates.

The application includes four live attack scenarios: a normal purchase, a price-tampering attempt, an over-threshold deal requiring approval, and a duplicate-payment replay.

How PayPal and AI are used

PayPal is central to the payment workflow. The backend calls the PayPal Orders v2 API to create an order using the agreed amount stored in the database. The buyer approves the order on the PayPal Sandbox page, after which the server captures the payment and verifies the capture status, amount, and currency before marking the transaction complete.

Failed, pending, or cancelled payments are never reported as successful, and reserved budget is released when the payment workflow fails.

Google Gemini powers three parts of the application: request parsing, offer comparison, and deliverable generation. Model output is schema-validated before use. If Gemini is unavailable, a clearly labelled fallback is used and recorded. The AI recommends; the policy engine decides.

How I built it

The frontend uses React 18, Vite, and Tailwind CSS, deployed on Vercel. The backend uses Node.js and Express 5, deployed on Render, with MongoDB Atlas and Mongoose for data persistence.

PayPal API calls use Axios from the backend, keeping payment credentials out of the browser.

Budget safety relies on atomic MongoDB operations using findOneAndUpdate, $expr, and $inc to reserve, spend, and release funds. This prevents concurrent checkouts from independently passing a non-atomic budget check and overspending the available budget.

Offers are stored server-side and verified by ID and price, preventing clients from substituting their own prices. Payment capture uses an atomic status transition to prevent duplicate processing, returning HTTP 409 for replayed capture attempts.

The voice assistant uses the browser's Web Speech API without a paid speech service. A Jest and Supertest test suite covers the policy engine, agents, deals, and payments, with Gemini and PayPal mocked during testing.

The project was built from scratch during the hackathon submission period.

Challenges I ran into

  • Concurrency: A simple “check the budget, then charge” approach creates a race condition. I implemented atomic budget reservation to prevent competing checkouts from independently spending the same available funds.
  • Not trusting the browser: Checkout ignores client-supplied amounts and logs detected price-tampering attempts.
  • Duplicate capture: PayPal redirects and repeated requests can trigger replay attempts. An atomic status transition prevents duplicate capture processing and returns HTTP 409 for replays.
  • Reliable AI output: Model responses needed validation, with an explicit fallback rather than a misleading success result.
  • Voice without weakened security: The assistant is an explanation and navigation layer, never an authorization mechanism.

Accomplishments that I'm proud of

  • Building an end-to-end flow from a natural-language purchasing request to a verified PayPal Sandbox capture and unlocked deliverable.
  • Implementing four attack scenarios against the actual backend rather than relying on scripted animations.
  • Creating a policy engine that remains authoritative even when the AI or browser submits an untrusted request.

What I learned

Agent payments are a trust problem as much as a model problem. The most important design decision was to let AI propose actions while requiring every payment to pass deterministic server-side checks.

I also learned how much care reliable payment handling requires, particularly around idempotency, capture verification, concurrent spending, and releasing reserved funds after failures.

What's next for SpendMesh AI

  • Real authentication and per-user spending policies
  • Integration with real seller services instead of simulated agents
  • PayPal webhooks for asynchronous payment events
  • Multi-currency support and team budgets

Honest scope

All payments use PayPal Sandbox test funds. Seller agents are simulated, and the application currently uses a single demo user without login. SpendMesh AI is a working prototype of an autonomous spending control layer, not a production-ready payment system.

Built With

Share this project:

Updates

Submission history