One append-only ledger
Every credit and debit on every wallet is a permanent entry with a running balance. Nothing edits a balance directly: an adjustment is a new entry with its own reason and author, and the previous entries stay exactly as they were. That is what makes a balance explainable to the cent, months later.
- The ledger is the source of truth. The balance shown on a pass or a dashboard is a cache of it. Employee reward balances are rebuilt from the entries every night and corrected if they ever drift.
- Writes to the ledger take a row lock, so two redemptions of the same wallet at the same instant cannot both succeed.
- Every entry records who caused it: a staff member, a POS terminal, a scheduled job, or the guest themselves.
Reserve, then commit
A redemption is not a single step. The code is validated, the amount is held on the wallet, and only when the sale completes is the hold turned into a debit. If the sale is cancelled or the terminal loses power, the hold is released automatically after five minutes and the guest keeps their balance.
- Wallet passes carry a static identifier plus a short-lived redemption token; a screenshot of a pass does not spend it twice.
- A sale voided on the POS releases its hold immediately.
- Disputes: a redemption a guest reports as wrong can be reversed by a manager, as a new ledger entry, never by deleting the original.
Your data stays yours
Every organization on Perktiva is isolated at the database level. Each query runs inside the organization's own context and the database itself refuses rows that belong to anyone else, on top of the checks in the application. Within an organization, a general manager sees only the locations they are assigned; corporate roles see everything.
- Row-level security policies on every tenant table, enforced by PostgreSQL, not only by application code.
- Location scoping applies to employees, rewards, redemptions, reports, and gift-card activity alike.
- Platform operations that must see across organizations run on a separate, explicitly privileged connection and are logged.
Access and audit
Managers and above sign in with email, password, and, if you require it, a second factor. Crew sign in at the counter with an employee code and PIN that cannot reach the dashboard. Every role has an explicit permission set, and sensitive actions ask for the password again.
- Two-factor authentication (authenticator app) for any account, and an organization-wide setting that requires it for every manager and admin.
- Accounts lock after repeated failed sign-ins; sessions time out after eight hours idle; a password change signs out every other session.
- An audit log records who did what across staff and money operations: issues, redemptions, adjustments, voids, role changes, key rotations, with actor, time, and address.
- Rate limits on every authenticated route, and a stricter one on sign-in.
Card payments never touch Perktiva
Gift-card purchases and reloads are paid through Stripe Checkout, on Stripe's pages. Perktiva never sees, stores, or transmits a card number. Once your Stripe account is connected and verified, gift-card sales are charged on it directly and Stripe pays them out to you; Perktiva is not the merchant of record for those sales.
- A card is issued only after Stripe confirms the payment, from a signed webhook; a duplicate webhook cannot issue a second card.
- Refunds run through Stripe and are mirrored on the ledger as their own entries.
- POS integrations authenticate with per-location API keys that can be rotated or revoked at any time from the dashboard.
Encrypted, backed up, monitored
Perktiva runs on managed infrastructure with TLS everywhere, secrets held in a dedicated secrets manager rather than in code or configuration files, and error and uptime monitoring that pages us before you notice.
- Database backups on a weekly, monthly, quarterly, and annual schedule, stored off the primary provider, with restores drilled rather than assumed.
- Every change ships through an automated pipeline that type-checks, lints, builds, runs the test suites, and audits dependencies, and it deploys only after all of that passes.
- Security reviews of the money path and authentication are part of the release cycle, and findings are fixed before the next release, not filed.