Reliability & trust
Boring where it counts.
A system trusted with the till, the bookings and the books earns it structurally, not contractually. This page is how DeckPOS is actually built — kept accurate the way the rest of the site is: if the behavior changed, this page would be wrong.
Your money
Cards settle to your own Stripe account
Every store connects its own Stripe account. Card takings move from your customer to you — the platform never holds your funds, and processing fees are between you and Stripe at your rate.
Integer cents, always
Money is stored as whole cents and tax rates as basis points. There is no floating-point arithmetic anywhere near a price, a total or a refund.
Books that check themselves
Automated integrity checks continuously look for money that does not add up — a paid order missing its payment, a confirmed booking missing its nights — across every store, every day. Failures surface to the platform operators before they surface to you.
Your operation
The register works offline
When the internet drops, the register keeps selling from its local cache and queues each sale. Everything syncs when the connection returns — built for places where the line goes down in weather.
One availability ledger
A campsite night or room night exists once, as a row that can only be written once. The website and the front desk sell from the same ledger, so a double-booking is structurally impossible, not procedurally discouraged.
Permissions, not trust
Staff sign in with PINs and act within capabilities — a cashier can ring sales without being able to refund them. Sensitive actions land in an audit log the owner reads.
Your data
Exports on any day
Your products, customers, orders and bookings export as CSV whenever you like — including during a trial, including the day you leave. There is no retention hold.
Tenant isolation, enforced by the database
Every store's rows are fenced by row-level security enforced in the database itself, and an automated test suite of hundreds of refusal tests proves — on every change — that one store cannot read another's data.
API keys sealed, not stored
Third-party credentials you add (Stripe, QuickBooks, ad platforms) are encrypted in the application with a key the database never sees. Nobody — including support — can read one back out of a screen.
Access to your store
Support cannot let itself in
Platform support has no standing access to your store. When you want help inside it, you open a time-limited support session — and every read during it is written to your own audit log.
Webhooks are signed
Events the platform sends to your systems are signed so your side can prove they came from us; events we receive (payments, phone calls) are verified the same way in reverse.
AI reads, people decide
Every AI feature is draft-first and read-only: assistants answer from what your login could see, marketing drafts wait for your approval, and nothing AI-generated is published or spent by itself.
The paperwork
The formal versions live under Terms, Privacy, Data processing and the subprocessor list. Data rights — export or deletion, no account required — start at /my-data.