Safe for the customer ordering.
Safe for the business serving them.
Security here isn't one feature bolted on. It's the same discipline applied everywhere: on the storefront, in the dashboard, and in the database underneath both.
See how it's builtAllowed.
You're signed in as yourself.
A customer trusts a business with an order, a payment, and sometimes a name and a photo.
A business trusts Drip & Bake with everything that keeps it running — its money, its customers, its team.
Two kinds of trust. One platform built to keep both.
01 / One boundary, everywhere
Every business is its own room.
A café's orders, customers, staff and records live in their own space — never visible to another business on the platform, whatever plan either one is on.
This isn't a setting a merchant turns on. It's enforced by the database itself, on every single request, the same way for every business.
It's been verified the honest way: not assumed, but checked against real data — one business's records fully visible to itself, and exactly zero rows of anyone else's.
02 / Theirs, and only theirs
A customer's account belongs to them, and only them.
Signing up checks a password against records of passwords already known to be compromised, and refuses it if it's on that list — the same protection used well beyond cafés and bakeries.
Nobody is forced to create an account just to place an order. Guest ordering stays available for someone who only wants to walk through the door digitally.
What a customer shares — their name on a comment, their photo, their order history — stays exactly where they chose to share it, and nowhere they didn't.
03 / Extra proof, for hard-to-undo actions
Two-step verification, for the moments that matter.
Some actions are hard to undo — connecting or disconnecting a payment provider, handing a business over to someone else.
For those, if a merchant has turned on two-step sign-in, Drip & Bake asks for the authenticator code again before the action goes through — not just a password.
Connecting Stripe · confirm with your authenticator
That check happens in the database itself, not only on the screen. A step can't be skipped by skipping past a screen, including by anyone on our own team.
04 / Your own session, your own role
Your team, signed in as themselves.
Staff sign in at the counter with their own short code, not a shared password everyone remembers or a manager's login typed in for them.
An owner, a manager and staff each see and can do only what their role allows.
An owner working in the dashboard and a staff member signed in at the counter, on the very same computer, never sign each other out. Each keeps their own session.
How it's built
How it's protected, underneath.
01Nothing reaches the database without a check.
A customer's device — or a merchant's — never writes directly to an order, a balance, a comment or a setting. Every one of those goes through a function that checks who's asking and what they're allowed to do, first.
02A business's boundary is enforced below the app, not inside it.
The rule that keeps one business's data from another isn't a filter the app remembers to apply. It's attached to the data itself, so a mistake in one screen can't accidentally expose what belongs to a different business.
03A public page gives out exactly one business's information, never more.
The parts of a storefront anyone can see — a menu, a public profile — are built so that asking for one shop's page can only ever return that shop's information, checked directly against the real, running system rather than assumed from how the code reads.
04Sensitive changes wait for extra proof, and the wait can't be skipped.
Two-step verification for the actions above isn't a prompt the app decides to show — it's a condition the database itself checks before the action is allowed to happen at all.
Thought through, underneath
A shared practice.
Not something done alone.
The parts most people never see.
What we watch for, quietly.
New code and new database changes are checked against automated security scanning before and after they ship, not just reviewed by eye.
Every table, every function, starts with no access at all. Access is added back deliberately, one purpose at a time — never granted broadly and narrowed later.
When a scan or a report turns up something that shouldn't be reachable, it's treated as urgent, not filed away for later.
What we ask of you.
Security here is shared, not something Drip & Bake does alone.
For a customer: use a password you don't reuse somewhere else, and keep your email up to date — it's how we reach you if anything about your account needs your attention.
For a merchant: if you haven't turned on two-step sign-in yet, it's there, and it's worth the extra ten seconds on the actions that matter most.
A related page
Money has its own page.
Everything above is about accounts, boundaries and access.
How a payment itself is protected — card details never reaching Drip & Bake, prices set by the server rather than a customer's device, a charge that can't happen twice — has its own page, because it deserves the full explanation rather than a summary here.
If something looks wrong, tell us.
Every business, its own room.
Every account, theirs to protect.
If a customer or a merchant ever finds something that seems like it shouldn't be possible, or notices something in their account that doesn't look right, we'd rather hear about it directly than not at all.
A good-faith report is treated as help, not a problem — investigated and fixed with urgency, not queued behind everything else.