Security you can check, not just read
How we protect your store and your customers' information. Every point here describes how the product works today, and the last section says plainly what we have not done yet.
Your data is separate
Stores are isolated by the database
Every record belongs to one store, and the database itself refuses to return it to another. It is not left to application code alone.
Isolation is tested
Our tests fail if a table that holds store data is missing its isolation rule, and they try to read one store's data from another.
Admin and storefronts are apart
The admin runs on its own address, separate from every store, so a problem on a storefront cannot reach a signed in admin session.
Secrets stay out of code
Keys and credentials are supplied to the running service and never written into the product's code.
Sign in and access
Strong passwords, safely kept
Passwords are hashed, never stored as written, and sign in attempts are limited to stop guessing.
Two step verification
Store owners can turn on an authenticator app and get recovery codes in case a phone is lost.
Devices you control
See where you are signed in and end any session. Sensitive changes ask for your password again first.
Roles that match the job
Admin, staff and viewer roles with only the access each person needs, and a record of who did what.
An audit log
Important actions such as publishing a theme or changing a payment setting are written to a log with who did them and when.
Payments and customer details
Card numbers never reach us
Cards are entered on the payment provider's own page. We never see or store them.
Sealed wallet numbers and keys
Saved wallet numbers and payment provider keys are encrypted with AES-256-GCM, with keys derived separately for each store.
Payments are confirmed with the provider
A payment is marked paid only after we check it with the provider, not because a browser said so.
Signed webhooks
Events we send to your systems are signed so you can verify them, and your signing secret is shown once.
Custom code stays fenced in
Checked before it goes live
Custom CSS, JavaScript and Liquid are validated when you publish, and unsafe code is refused.
Never on the money pages
Merchant code does not run on checkout, sign in or account pages, which blocks card skimming through a bad script.
A switch for the whole store
Scripts can be turned off for a store at once, and marketplace themes that contain code are reviewed before they are listed.
How the service is run
Encrypted connections
Every page is served over HTTPS, and a domain you connect gets a certificate that renews itself.
Limits on abuse
Rate limits protect sign in, checkout and the public endpoints, and outgoing webhook addresses are checked so they cannot be pointed at our own network.
Dependencies are watched
We audit the libraries the service depends on and fix known vulnerabilities before releasing.
What we have not done yet
Trust comes from being clear about the gaps as well as the strengths.
- We have not yet had an independent security audit or a certification such as SOC 2 or ISO 27001.
- We do not run a public bug bounty. We do read and act on every report we receive.
- Passkeys and security alert emails for shoppers are still on our list.
Found a problem?
Tell us how to reproduce it and we will look at it first. Use the support option inside your admin, or reply to any email we send you.
Open your store this week
Set up in an afternoon: add your products, connect your page and take your first order. Try any plan free, no card needed.