Security

How we look after venue and guest data.

What Reservory does today to protect your venue, your guests and your payments, in plain terms. Nothing here is a certification.

RLSOn every venue table
AES-256Integration secrets
StripeHolds the card data

The short version

Six things worth knowing.

  • Each venue’s data is separated at the database, not only in application code
  • Card details are entered into Stripe’s fields and never reach Reservory’s servers
  • Payments settle to your own Stripe account
  • Integration credentials are encrypted before they are stored
  • Operator actions such as refunds and cancellations are recorded in an audit log
  • Security reports go to a named inbox with a published disclosure policy

In more detail

How the pieces work.

Staff sign-in

Authenticator-based two-factor protection

Staff can enrol an authenticator app. Owners can require two-factor authentication for owners and admins. Verified factors are enforced for protected operator access, with database checks as a backstop.

Tenant separation

Row-level security on venue data

Every table that holds venue data has Postgres row-level security. A signed-in staff member’s queries only return rows for a workspace they belong to. A small set of server tasks, such as payment webhooks and scheduled jobs, run with elevated database access; those paths check the workspace explicitly. A cross-tenant isolation test runs on every pull request.

Payments

Stripe holds the card data

Reservory uses Stripe Connect with Standard accounts. Guests enter card details into Stripe’s payment fields, and each venue is paid out from its own Stripe account.

Credentials

Encrypted integration secrets

OAuth tokens and API keys for connected services (Mailchimp, Klaviyo, HubSpot, QuickBooks and others) are encrypted with AES-256-GCM before they are written. The key is kept outside the database.

Guest links

Signed, expiring links

Payment and waiver links sent to guests carry a signed token that expires. A token issued for one purpose is rejected for another.

API keys

Stored as hashes

Reservory API keys are shown once when created. Only a SHA-256 hash is stored.

Retries

Duplicate requests are caught

Booking, payment and refund requests carry an idempotency key, so a browser retry or dropped connection doesn’t repeat a booking or a charge. If the result of a request is uncertain, it is held for reconciliation instead of being run again blindly.

Audit log

Who did what, and when

Refunds, cancellations and other operator actions are logged with the staff member and time. Each workspace sets how long the log is kept (365 days by default, 30 days minimum).

Webhooks

Outbound calls stay public

Webhook destinations must use HTTPS and resolve to a public internet address. The address is checked again at every delivery, and private or internal ranges are refused.

Guest privacy

Deletion requests

A guest deletion request waits 30 days so it can be cancelled, then the guest’s personal details are anonymised and any scheduled emails or texts to them are cancelled.

Compliance

Where we stand today.

PCI DSS

Card data stays with Stripe

Reservory is not a card processor. Stripe collects and stores card details; Reservory works with Stripe’s payment references, not card numbers.

SOC 2

Not certified

Reservory has not completed a SOC 2 audit. If you need architecture or access-control detail for a review, email us.

Questions about security?

Email the security inbox or read the disclosure policy, including scope and testing rules.