The server is the gate, not the screen
A point of sale is where cash, card data and staff behaviour meet. Aura's rule is that the client UI is a convenience and the server is the actual authority — a tampered terminal still can't do what its token doesn't allow.
Server-side enforcement
The apps hide actions by role, but every mutating endpoint checks the caller's token independently. Hiding the Refund button is a courtesy; refusing the refund is the control.
PINs are never readable
Staff PINs are stored as salted hashes — nobody, including an admin, can read one back. A manager can reset a PIN; they can't look one up. Deactivating a leaver disables their PIN on every device at the next sync.
Fresh sessions
Every PIN sign-in gets a completely fresh session — carts and state never leak between staff on a shared terminal. Back-office sessions refresh silently; a truly expired one asks for a sign-in and loses no work.
Manager override, attributed
A manager-gated action — discount, void, comp, no-sale, settings, floor editing — takes a manager's PIN for that single action, and records their id against it. The server keeps the till; nobody hands over a device mid-service. Refunds have no override path at all.
An audit trail that answers questions
Every discount, void and comp is logged with its reason and who approved it. Every drawer open — including no-sales — is recorded against the register with the approving manager. Reports → Logs is your shrinkage trail.
Atomic commits
Every sale commits atomically on the device. There is no window in which a sale is half-recorded — a power cut mid-transaction leaves either a complete sale or none.
Eight roles, and a rule about creating them
ADMIN, SUPER_ADMIN, MANAGER, SERVER, CASHIER, BARTENDER, CHEF, HOST. Staff can only be created at or below the creator's own role — so a manager can't quietly mint themselves an admin.
| Action | Server / Cashier / Bartender / Chef / Host | Manager + |
|---|---|---|
| Ring & send orders, take payment | ✓ | ✓ |
| Open/settle tabs, work the KDS, tick checklists | ✓ | ✓ |
| Log wastage | ✓ | ✓ |
| Discounts, voids, comps, no-sale | Request only | ✓ authorise by PIN |
| Refunds | — | ✓ button hidden otherwise |
| Terminal settings, floor editing | — | ✓ |
| Back office | — | ✓ |
| Create staff | — | ✓ at or below own role |
Where it lives and how it moves
One server, isolated businesses
Your Aura server hosts one or more tenants and every query is scoped to the caller's tenant. A back-office sign-in takes an email, a password and a tenant id.
Local databases
Desktop terminals persist at ~/.aura/aura.db;
Android and iOS use the app's private storage. Browser terminals deliberately keep
nothing across a reload — which is also why they're convenience screens, not tills.
Signed and expiring
Public web receipts are reachable only with a signed token and expire after 90 days. A tampered or expired link shows nothing at all, rather than leaking a sale.
Licence-gated, validated, rate-limited
The guest ordering endpoints refuse any venue whose licence has no QR Ordering product — stale codes stuck to tables serve nothing. Past that gate, every order is validated server-side (real products, real prices, sane quantities) and rate-limited, so a public endpoint can't be used to mine your menu or flood your kitchen. Which products an account may run rides in the signed token itself, so a terminal cannot grant itself one.
Signature-verified, idempotent
Payment webhooks verify the provider's signature before they're trusted, and capture is idempotent — a provider retry can't double-capture a bill.
Won't boot insecure
With AURA_ENV=production
the server refuses to start on placeholder secrets and enables HSTS — so a
dev JWT secret can't reach production by accident.
Built-in rate limits, per minute
Applied per client IP, so one misbehaving caller can't degrade service for the venue.
What Aura holds about your guests
Being able to answer this precisely is most of a POPIA conversation, so here it is plainly. Aura stores personal information about guests only where a feature needs it:
| What | Why it's held |
|---|---|
| Customer name and phone or email | To attach a customer to a sale for loyalty points, store credit, house accounts and WhatsApp receipts. Optional — a sale needs no customer at all. |
| Booking name and contact | To hold and confirm a reservation, and to send the WhatsApp confirmation. Guests supply it themselves when booking online. |
| Pickup name and optional phone | To identify a takeaway order at collection. |
| Visit and spend history | To drive loyalty tiers and the new-vs-returning and top-spender reports. |
| Birthday, if given | Only to issue the automatic birthday voucher. |
Consent and reach
- WhatsApp receipts go only to customers who have opted in. No opt-in, no message.
- Guests aren't required to identify themselves to order by QR — a table order needs no name, and kiosk mode wipes everything between customers on a 45-second reset.
- Card data never touches Aura. Card-present payments happen on the Yoco terminal; pay-by-link and QR payments happen on the provider's own page. Aura records the payment leg, not the card.
Access, export and deletion
- Customer records are visible and editable in Back Office → Customers, so a subject-access or correction request is a screen, not a support ticket.
- Every report and list exports to CSV, so you can produce a data extract yourself.
- Store-credit changes carry a reason and are audited, so an adjustment can always be explained.
Send us your security questionnaire
If your group or your insurer needs one filled in, we'd rather do that than have you guess from a marketing page.