Security
No badges and no adjectives. Each claim below is a description of how the platform is built, including the one that is not flattering, which is at the end where you can still see it.
Row-level security is enforced by the database itself, per store, on every table that holds merchant or shopper data. Application code cannot forget to filter, because the filtering is not its job. One store reading another’s data is the failure the whole architecture is arranged to make structurally impossible, and the isolation suite that proves it runs with every build.
The platform takes no card payments, so it never sees, transmits or stores a card number. Shoppers pay cash at the door or by Whish and OMT; merchants settle invoices the same way. What we hold about a payment is the record that it happened, with its evidence.
Passwords are stored only as Argon2id hashes and are unreadable by anyone, including us. Sessions live in HttpOnly cookies, so the session token is never readable by browser scripts. Sensitive actions inside the admin, like changing delivery zones, require the password again even inside a signed-in session.
Every operation that moves money or stock carries an idempotency key. A retried request, a dropped connection, or the same event arriving twice through two routes applies exactly once. This is checked in code review and enforced by database constraints, not by hoping networks behave.
Merchant actions in the admin are recorded with who did what and when, and every request carries a correlation identifier from edge to database, so an incident can be reconstructed rather than guessed at.
Connections to storefronts, the admin, and this site are encrypted with TLS.
A merchant can export their store’s data at any time, on the first day and on the last. After cancellation it stays exportable for sixty days and is then deleted from the live systems. Nothing about leaving is designed to be hard.