YalEat Platform Architecture

Real audit of what works, what is simulated, and what is missing

Working Partial / Simulated Not Implemented

Working

Auth, Orders, Pricing, Stripe, Menus, Multi-role Users, P2P Delivery, Driver Dispatch, Push Notifications, POS push (all providers), Two-leg traffic ETA, Dynamic prep time, Real-time stock depletion, Saved card (PM attach), Apple/Google Pay, Scheduled order auto-dispatch

Partial / Simulated

Code complete, not end-to-end validated: saved card reuse flow, Apple/Google Pay (device/browser), scheduled order dispatch window crossing, stock depletion → customer-side unavailability display

Not Implemented

None — code complete. Pending E2E validation: saved card reuse, Apple/Google Pay on device. Two design decisions to monitor: (1) All transfers, payouts, stock depletion, and POS push depend on payment_intent.succeeded webhook — idempotency is in place but webhook failure causes state drift; monitor + replay capability needed. (2) Alcohol compliance is operational (enforced at delivery), not pre-authorization — driver gating must be strict and refund path must be clean.

Authentication & User Management
✅ What Works
OTP via Twilio SMS (mobileAuth_v3)
Self-signed JWT issued on login (30-day expiry)
RorkUser created/found on verify
Multi-role: customer + driver on same phone
active_roles[] + driver_account_status tracked separately
driver_profile_id linked on signup or role-switch
account_status (customer) vs driver_account_status are independent
Token refresh endpoint
Merchant OTP + magic link flow
⚠️ Known Gaps
JWT is self-signed — no Base44 session; admin pages use separate Base44 auth
Token expiry is 30 days — no short-lived + refresh-token pattern
No device binding or token revocation
Merchant login via email OTP uses a synthetic RorkUser (not in DB)
Biometric / Face ID integration
Social login (Google, Apple)

Flow: mobileAuth_v3

sendOTP → OTPCode record → verifyOTP → JWT signed with JWT_SECRET → access_token returned
Stripe Payment Integration
✅ Working
PaymentIntent (separate charges model)
transfer_group per order
Stripe customer created on first order
stripeWebhook: payment_intent.succeeded → creates merchant + driver transfers
Merchant Stripe Connect onboarding (Express)
Driver Stripe Connect (for payouts)
Refund via processStripeRefund
⚠️ Partial
Transfers only fire if webhook is live + STRIPE_WEBHOOK_SECRET is set
Driver payout triggered by payment_intent.succeeded — driver must have Stripe Connect active
Refund flow: admin must approve manually, then processStripeRefund is called
⚠️ Code Complete / Unvalidated
Saved card reuse — paymentMethodsAPI has full SetupIntent→attach flow; reuse on next PI not E2E tested
Apple Pay / Google Pay — automatic_payment_methods enabled in createOrder; not tested on real device/browser
❌ Not Implemented
Subscription billing
Automatic weekly/monthly driver payout batching
Key Backend Functions Reference
mobileAuth_v3

OTP auth + JWT signing

mobileAPI_v3

Central mobile API (all actions)

createOrder

Full pricing + Stripe PaymentIntent

calculateDeliveryFee

Distance + surge + traffic cap (Google Maps)

calculateDynamicETA

Two-leg traffic ETA: driver→merchant + merchant→customer

pushOrderToPos

Real POS push: Clover/Square/Toast/Olo/Deliverect/HungerRush + webhook fallback

calculateOrderMarkup

Markup policy engine

calculateCommission

Platform commission engine

autoAssignDriver

Production-ready: weighted 6-factor scoring (proximity+rating+acceptance+completion+ETA+freshness), score persisted to DriverStatus, stale location filter, push notifications sent to candidates

merchantOrderFlow

Dynamic prep time: IQR-filtered historical median + complexity blend

stripeWebhook

Payment → merchant/driver transfers

handleOrderCancellation

Refund + goodwill credit

handleDriverIncident

Incident → reassign/refund flow

getMerchantMenu

Menu via service role (web UI)

processStripeRefund

Admin-triggered Stripe refund

scrubAlcoholFlags

One-time cleanup utility

autoDispatchScheduled

Scheduler live — every 5 min: inline expiry marking, immediate re-dispatch on expiry, scheduled orders, batch dissolution (Fix 4)

acceptOrder

Production-safe: atomic assignment guard (Fix 1), offer expiry enforcement (Fix 2), state machine validation (Fix 6)

syncPosMenu

POS sync — Clover/Square credentials needed