We run a live multi-location Apple service business on this system every day. That means every protection below is tested against real money and real customer data, not a staging environment. Here's exactly what's in place.
Every business table is scoped to your shop by Postgres row-level security. Another shop can't read your rows even through a direct database query, because the boundary sits below the application. A UI bug can't leak what it was never allowed to load. The same enforcement applies to customers: a logged-in customer can only reach their own tickets and invoices, not other customers' records.
Two-factor authentication is required for every staff account. There's no toggle to turn it off. It's enforced in the database: a session that hasn't completed its second factor can't read a single business record. Authenticator app is the primary method; email codes are the fallback. If a tech loses their phone, an admin resets their enrollment from Settings.
Totals, tax and balances are calculated by the database from line items and payments. The app can't write a total at all: money fields are stripped from every write, and a database-level guard reverts any total the database didn't compute itself. What the customer pays and what you're owed are the same figure everywhere, to the cent.
Your Apple service certificate is stored on our hardened GSX gateway in a compartment isolated to your shop. It authenticates your GSX calls and nothing else. No other tenant can reach it, and there's no gateway for you to install or run.
Apple's labor reimbursement runs through a single enforced boundary in the code. A customer is never billed Apple's money, Apple's credit never inflates your revenue, and your books stay clean on both sides.
Three built-in tiers (admin, manager, technician) cover most shops. You can also build custom roles: pick exactly which pages a role can open and which actions it can take, like issuing a refund, placing a parts order, or processing a payment. The checks run on the server, so a technician can't reach a refund by knowing the URL.
Logins, logouts, user invites, role changes, payments, refunds, ticket updates, assignments, product changes, purchase orders, data imports, data exports, integration connections, cash management, and payment links are all logged with who did it and when. Separately, an access log shows every active staff session with its IP, device, 2FA status, and sign-in time. If someone leaves the shop, a manager ends their session from Settings and they're out immediately, on every device.
Payments run through your own Stripe account. Money settles directly to your bank. BenchOS never holds your funds, and card numbers go to Stripe, never our servers.
BenchOS earns only its plan fee. On paid plans there's no platform fee on card payments at all. See pricing for the exact numbers.
The unglamorous parts matter most, so they run on proven, managed infrastructure rather than anything we hand-rolled.
Reviewed October 2026
No. Card details go directly to Stripe and never touch our servers. Saved cards are held as Stripe tokens, not raw numbers.
No. Your shop's data is used to run your shop. It isn't sold, shared with other tenants, or used to train models.
Your data goes with you. Everything exports from Settings, individually or in one spreadsheet. We've migrated full multi-location shops on and off the platform.
Card data never touches BenchOS (it goes straight to Stripe, which is PCI Level 1), so we're out of the card-data part of PCI scope by design. We don't hold a SOC 2 report or ISO certification today. What we do have is comprehensive audit logging across every business action, automated security checks against the live database, and people who will walk an IT reviewer through any of it. If your shop needs a specific attestation, tell us.
If your shop has a specific requirement, or you're vetting BenchOS for a multi-location move, ask us directly. You'll talk to people who build and run repair shops, not a ticket queue.