In short
- Store isolation is enforced in the database, not just in application code — an application bug does not expose another merchant.
- Money movements go through controlled server-side operations with idempotency keys and locks, so a retry cannot double-charge or double-refund.
- We would rather hear about a vulnerability from you than from an attacker. Reporting one in good faith will not get you sued.
This summary is written to be understood. The clauses below are what actually applies — where the two differ, the clauses govern.
Store isolation
Every record belongs to exactly one store. That boundary is enforced by row-level security in the database, so a query that forgets to filter by store returns nothing rather than everything.
This is deliberately belt-and-braces. Application code also checks ownership, but the database is the layer that has to be right, because it is the one an application bug cannot bypass.
Money handling
Order totals, tax, and shipping are computed on the server from stored configuration. Amounts sent by a browser are never trusted.
Every money movement runs through a controlled database operation that takes a lock and requires an idempotency key, so a retried request cannot charge twice or refund twice.
Gift-card balances are derived from a ledger of entries rather than stored as a mutable number, so a balance cannot silently drift and cannot go negative.
Payment confirmations from the provider are verified by signature on our servers before any order is marked paid.
Authentication
Merchant sessions and shopper sessions are issued by separate systems with separate signing keys, so a token from one can never be accepted by the other.
Passwords are stored hashed. Registration and login are protected by bot challenges and rate limiting.
Refunds and payout-destination changes require step-up verification beyond the session — the two operations most worth attacking are the two that ask again.
Data in transit and at rest
All traffic is served over TLS, including custom domains, for which certificates are provisioned and renewed automatically.
Data at rest is encrypted by the storage layer. Credentials for third-party services are held as secrets in the deployment platform and are not present in the codebase.
Webhooks and background jobs
Inbound webhooks are verified by signature using constant-time comparison before the payload is acted on, and replayed deliveries are rejected.
Messages passed to background workers carry a signed tenant envelope, so a job cannot be forged to act against a store it does not belong to.
Internal access
Access to production data is individually authenticated, limited to those who need it, and logged.
Automated checks run on every change to catch a class of mistakes before they merge — including direct writes to money tables, which are structurally forbidden rather than merely discouraged.
Reporting a vulnerability
Email the security address below with enough detail to reproduce. You will get an acknowledgement, and we will tell you when it is fixed.
Please give us reasonable time to fix an issue before disclosing it publicly, do not access or modify data belonging to anyone other than yourself, and stop at proof rather than pivoting further.
We will not pursue legal action against a researcher who follows those three things in good faith.
NoteDo not test against a live merchant's store. If you need an environment to test in, ask us for one.
If something goes wrong
If a breach affects merchant or shopper data, we will notify affected merchants without undue delay with what happened, what data is involved, and what we are doing about it.
Where a merchant must in turn notify their shoppers or the Data Protection Board, we will give them what they need to do that within their own deadline.
Questions about this document
Write to support@letbuyy.com and quote the clause number. For a complaint rather than a question, use the grievance process.