I'm building an online store for a client using Next.js and Supabase, and they want customers to place cash-on-delivery orders without creating an account or signing in. How are guest carts and orders usually handled? Are orders saved directly to the database with a session or cookie, and what protections should be added to prevent bots or people from spamming the order endpoint?
3 Answers
A common setup is to keep the guest cart in a cookie or session, then create an order row in the database when the customer submits checkout. The order can include the products, delivery details, phone number, total, payment method, and an initial status such as “pending.” You don’t need an account for this, but the checkout endpoint should validate everything on the server before inserting the order.
Treat the checkout route like any other public API endpoint. Add rate limiting based on IP and, where practical, device or session identifiers. A honeypot field and CAPTCHA after repeated attempts can help reduce automated submissions. Also validate product IDs and prices against your database instead of trusting values sent by the browser, and don’t expose unrestricted database inserts directly to the client.
For cash on delivery, it’s also useful to collect and verify a phone number before considering the order valid. Store suspicious or repeated submissions separately, add unique request or idempotency keys to avoid duplicate orders, and use server-side authorization policies so users can’t read or modify other customers’ orders. Rate limiting can be implemented with an edge provider, middleware, or a Redis-backed library depending on where the app is hosted.
That makes sense. Is there a package or standard approach for adding rate limiting to the checkout endpoint?