Security & privacy
Written to be checkable. Every statement below describes something that exists in the running system, not an intention.
Every record that belongs to a shop carries that shop’s identifier, even where it could be worked out from a parent record. The database layer refuses any read or write that does not say which shop it is for.
That last part matters more than the first. Scoping every query correctly is something people intend to do; a query that cannot run unscoped is something the system enforces. A mistake becomes a loud failure instead of a quiet leak.
Staff sign in with an email and password. Passwords are stored as scrypt hashes, never in a form that can be read back.
Sessions are held server-side and can be revoked. Only a hash of the session cookie is stored, so a copy of the database does not hand anyone a live session.
Three roles: owner, manager and counter staff. Adding a stamp does not require the access needed to change the program, correct history, or read the whole customer list.
Every action is checked against the role of the person doing it, on the server, using the session — never using a value sent by the browser.
The code in a customer’s wallet identifies them. It authorises nothing. Someone who copies it cannot add a stamp, redeem a reward, or learn anything about the person.
Codes are stored only as hashes, and can be rotated without the customer doing anything.
Stamps, rewards, redemptions and corrections are appended, never edited or deleted. A mistake is fixed by recording the correction beside the original.
A disputed stamp can be traced to the minute, the till it came from and the person who added it. Sensitive actions are recorded separately again, with what changed and who changed it.
Traffic is served over HTTPS. Certificates are issued by Let’s Encrypt and renewed automatically.
Data at rest is encrypted by our database provider. We do not operate our own disks.
The database is managed by our provider, which keeps continuous backups and can restore to a point in time. The window depends on the plan we are on.
We will not claim a tested restore procedure until we have run one. When we have, this paragraph will say so and give the date.
What we send to a wallet provider is the shop, the stamp count and the card number. The customer’s name, email address and phone number are not sent and never leave our system.
This is deliberate: a pass needs to show progress, and it does not need to know who is holding the phone.
Joining a loyalty card is not consent to be messaged. Consent is asked for separately, per channel, and is recorded with the moment it was given.
It can be withdrawn. The change is kept in the audit history, because the question that matters later is not whether someone consented but whether we were allowed to send a particular message on a particular day.
A shop can ask for its customers and their history to be exported, or deleted, and we will do it.
A customer can ask the shop, or write to us directly. Deleting a customer removes their stamps and any unredeemed rewards, so we say so before doing it.
If you believe you have found a security problem, write to support@custback.com with enough detail to reproduce it.
We will confirm we received it, and we will not pursue anyone who reports something in good faith without going looking for customer data.