Raysto – AI-Powered Restaurant OS

Raysto is an AI-powered restaurant operating system unifying dine-in, QR ordering, delivery, staff, and payments—with PayPal-powered checkout and intelligent automation.

Comment

About the project

Inspiration

A snack bar or small café runs on a till, paper tickets, a card terminal and a shoebox of supplier bills that never talk to each other. Every evening the owner closes the till by hand, works out tips, wonders whether the croissant complaint deserves a refund, and never quite knows what a supplier's price rise did to the margin on the lunch bowl.

We wanted one product where AI prepares the work, a person approves it, and PayPal moves the money. Not a chatbot next to a payment button: AI coworkers that read bills, hear orders, price catering and trace costs into dishes, and then stop at the line where money moves, so the owner stays in control.

What it does

Raysto is the AI operating system for restaurants: an Android app for diners and staff, and an owner console built on AG Grid and AG Studio, both on one Serverpod + PostgreSQL backend with PayPal as the payment rail.

For diners (Android)

  • Ask Raysto: "Two vegetarian lunches under $25, ready as soon as you can." Gemini reads the real menu, keeps the budget, picks a pickup time the kitchen can keep, and proposes a priced basket. One tap places the order and opens PayPal; only the diner's approval on PayPal's own page pays.
  • Table service with a shared room and exact split bills: one PayPal order per diner's share, settled to the cent.
  • A tip step before PayPal and a "Something was wrong?" sheet that reaches the complaints agent.

For the counter and the kitchen (Android tablet)

  • A till with a PayPal QR code: the customer pays the counter sale on their own phone; the paid ticket goes straight to the kitchen board. Cash works too.
  • Voice ordering: the cashier says the order, Gemini fills the ticket from the menu and flags anything that is not on it.

For the owner (console at ops.rays.to, AG Grid + AG Studio)

  • The decision studio: one supplier bill changes a cost; Raysto follows that cost into every recipe and shows, in an AG Grid evidence grid, which dishes lost margin. The owner compares keeping the price with a capped increase ("limit the increase to 5%", "assume 10% fewer sales"); the backend recalculates inside the owner's policy. An AI financial analyst explains the result and configures AG Studio widgets (evidence, pricing and payment) side by side. Layout undo can never undo a business action.
  • Fourteen AI coworkers in an inbox, each with its reasons, its evidence and whether it moves money: the close agent reconciles the day against PayPal's transactions; the payroll agent turns clocked shifts into wages and tips and sends them with PayPal Payouts; the accountant reads a photographed bill and proposes paying it by Payouts or issuing a pay link (a standalone PayPal checkout); the catering agent quotes "lunch for 12 on Friday, budget $150" and sends a PayPal invoice through the PayPal MCP server; the complaints agent reads the ticket and PayPal's capture (via MCP) and proposes a full, partial or no refund, acting alone only inside the owner's limit; the disputes agent assembles evidence through MCP; the payments agent notices an abandoned checkout, asks PayPal itself and prepares the release; plus supplies, expenses, loyalty, menu reading, copilot and an image studio.
  • An Accountant section (bills, pay links, profit and loss, cash flow, payables, VAT) on AG Studio, a Group view for two cafés under one owner, Dispatch with drivers and a labelled delivery-partner simulator, Team, Money and Floor.

Every money change asks the approver to confirm their identity again. Payouts, invoice sends and refunds above the limit are never automatic.

How we built it

  • Backend: Serverpod 4 (Dart) and PostgreSQL on AWS (api.rays.to), a durable job queue, and a separate lane for AI work so a slow model never delays a payment. Exact integer money; every proposal stores its evidence and a fingerprint of the records it saw, so a stale approval is refused.
  • PayPal: Orders v2 (create, buyer approval, one server-side capture with a capture lease so nothing is captured twice), verified webhooks processed exactly once, Payouts batches polled to completion, Invoicing, Transaction Search, Disputes and Refunds, Partner Referrals for per-restaurant accounts, counter QR, pay links at /pay/{token}, and the official PayPal MCP server (@paypal/mcp over stdio) started with exactly twelve tools: seven reads the model may call and five executes that only an approved action can run.
  • AI: Google Gemini 3.6 Flash with function calling, vision and audio, one narrow tool set per coworker; gemini-3.1-flash-image for dish photos. Agents run as a service identity that can read and propose but never pass a role check. The model never sees a PayPal write tool. AI spend has a hard budget per feature and per restaurant per day, and each agent has a kill switch.
  • Console: Next.js 16, React 19, AG Grid 36 and AG Studio 3 with custom evidence, pricing and payment widgets, cross-filtering, typed analytical configuration and private owner layouts; GSAP motion; Firebase Authentication.
  • App: Flutter (Android), phone and tablet layouts, English, French and Arabic, light and dark, with an explicit offline demo kept apart from connected accounts.
  • Tests: backend 90 unit + 181 integration tests on an isolated database; console 197 unit + 68 browser tests; app 241 widget tests. Built from scratch during the hackathon: first commit 26 October 2026.

Verified live in PayPal Sandbox

Between 31 October and 6 November 2026 we recorded fifteen captures, six refunds and nine PayPal Payouts batches on production, all confirmed in the café's journal: pickup orders paid from Ask Raysto baskets, counter sales by QR, a $27.00 table bill split into two $13.50 shares, partial and complaint refunds with PayPal's refund ids, wage and tip batches sent by the payroll agent after the owner's identity check, a supplier bill paid by Payouts, and an abandoned checkout read through the PayPal MCP server (PAYER_ACTION_REQUIRED) and released. The latest run (6 November) traced a supplier cost from $3.50 to $3.85, published a reviewed price of $9.70 while an open checkout kept its frozen $9.00, captured the new order (capture 9PP6471265636910M) and paid the $11.00 supplier bill in a separate approval (Payouts batch 7Q7ZS39C8WAXJ). Model evaluation on the decision workflow: 12 of 14 first attempts, 13 of 14 with read-only recovery; earlier evaluation of menus, spoken orders and takeaway requests: 12 of 12.

Challenges we ran into

  • Settling once. A payment can be settled by the webhook, a background job or the buyer's return, in any order. The capture lease and a single settle step took the most testing.
  • AI that can be trusted near money. The coworkers had to be useful without being able to act. The answer was a service identity that can only propose, evidence stored with each proposal, a stale check at approval time, and a fresh identity check for every money change.
  • Letting the AI use PayPal's own tools without trusting it with them. The PayPal MCP server offers invoice, dispute and refund writes next to its reads. We expose only the reads to the model and route the writes through the same approval path as every other money change, so a judge sees the AI do real PayPal work and still sees a person's approval in front of it.
  • Explaining a margin without inventing one. Contribution before shared overhead is not profit; a collection is not earned revenue; a payout batch submitted is not a recipient paid. The AG Studio workspace had to show each of those as a different thing, and refuse a recommendation when a dish's cost evidence is incomplete.
  • Real-world timing. Live runs found what tests had not: a 30-second limit too short for a basket, sessions refused after 100 sign-ins, a comparison approved after its inputs had changed. Each became a fix and a test.

Accomplishments that we're proud of

  • Every PayPal journey above was run live against PayPal Sandbox, with ids recorded: Orders, captures, refunds, Payouts batches and MCP reads.
  • An owner can challenge an AI pricing recommendation inside AG Studio ("cap it at 5%") and watch the backend recalculate inside their own policy, with the evidence grid beside it.
  • A judge can try it in two minutes with nothing to install: rays.to → Enter the live demo.
  • One backend serves the counter, the kitchen, pickup, table service, shifts, stock, bills, dispatch and the owner console, in three languages.

What we learned

PayPal's order states map naturally onto a restaurant: approved is not paid, and capture is the moment that counts. Giving each AI coworker a narrow set of tools and nothing it can execute made it both more useful and easier to trust, and that stayed true as the coworkers grew from reading menus to sending payouts, invoices and refunds. And a grid is the right place to argue with an AI: AG Studio let the owner see the evidence, the assumption and the outcome in one view instead of trusting a sentence.

What's next

  • A pilot with one café, on a real menu photo, a real counter voice and a real supplier bill. No owner has used Raysto yet, and we say so.
  • Invoicing and Transaction Search enabled on the Sandbox app, then a real Sandbox invoice and dispute recorded end to end.
  • PayPal partner onboarding so each restaurant connects its own live account.
  • iOS, translated menus and marketing posts drafted by the same coworkers.

Built With

Share this project:

Updates

Submission history