CashCha’s MVP runs without a conventional origin server. Astro renders the application for Cloudflare Workers, while persistent and short-lived state are split across Cloudflare services according to their lifecycle.
Runtime and storage
Cloudflare Workers handle the website and API routes. D1 stores durable application data, including users, companies, transactions, payouts, marketplace jobs, and email-outbox records. Browser sessions use signed JWTs in HTTP-only cookies; KV stores short-lived QR state and rate-limit counters. Static Assets delivers the built frontend, and runtime secrets remain in encrypted Worker configuration rather than the repository.
This architecture keeps the application boundary explicit: the Worker validates requests, applies authorization and rate limits, and performs database operations through bound services.
Two authentication paths
Browser clients use protected cookie sessions. Programmatic clients can use Bearer authorization instead, avoiding assumptions that depend on browser origins or cookie behavior.
Cookie-authenticated state-changing requests retain application-level CSRF checks. Session versions support account-wide invalidation, including invalidating sessions minted before a password reset. QR login uses short-lived generation, scan, approval, and status transitions rather than treating a scanned code as immediate authentication.
OAuth providers are shown only when their runtime configuration is complete. The interface does not advertise inactive providers as available.
Exact micropayment accounting
CashCha stores money as integer micro-dollars rather than floating-point values. That representation lets sub-cent charges add, compare, refund, and settle without binary rounding drift.
Bypass processing applies conditional debits and idempotency controls. Concurrent requests cannot jointly spend beyond the available balance or configured daily limit, and repeated requests using the same operation key return the original result instead of charging twice.
For completed bypasses, the participating website receives 85% and CashCha retains a 15% platform share. The interface presents that split directly rather than relying on projected revenue examples.
Current MVP boundaries
The deployed MVP is suitable for product demonstrations and integration testing. Stripe remains in simulator mode until production payment credentials and behavior are explicitly configured. Transactional email records are persisted to the D1 outbox while native outbound delivery remains dependent on external service entitlement.
Those boundaries are intentional and visible. The product should communicate what is operational today, what is simulated, and what still requires production configuration.