BenchOS connects to your own Stripe account. You are the merchant of record. Every card swipe, payment link, and subscription goes straight to you. BenchOS never holds or touches your revenue.
Pair Stripe Terminal card readers and take tap, chip, or swipe payments right from the invoice. The charge is a direct charge on your connected Stripe account. You are the merchant of record, not BenchOS. Stripe bills you their standard processing rate. On the free plan, BenchOS adds a 0.5% platform fee; on Pro and AASP, there is no BenchOS fee at all.
Generate a Stripe payment link from any invoice and send it by email or text. The customer pays online and the payment records itself. The invoice balance updates, the ticket reflects it, and there's nothing to reconcile.
Set up monthly or annual service plans, maintenance agreements, or device protection. Cancel, pause, or resume from inside BenchOS without logging into Stripe. The billing runs on your connected account. BenchOS shows MRR, renewal dates, and payment status.
A full cash drawer workflow: set the morning float, accept cash payments through the day, and close with a blind count at night. BenchOS computes expected vs. counted and shows the over/short. The expected figure is revealed only after the count is entered, so it can't be fudged to match.
Save a customer's card securely through Stripe and charge it again for follow-up work, warranty deposits, or repeat service. No need to ask for the card number a second time. Card details live in Stripe, never in BenchOS. We store only the last four digits and the card type.
Most repair-shop software computes totals in the browser: JavaScript adds up line items, applies tax, and writes the result to the database. It works until it doesn't. A partial page load, a stale cache, a race condition between two tabs, and the invoice says one thing while the payment link charges another.
In BenchOS, every financial total (subtotals, tax, balances, payments totals, over/short) is computed by Postgres triggers from line items and payments. The application can create inputs (add a line, record a payment) but it structurally cannot author a total. A write that tries to set a money field is silently stripped before it reaches the database.
Because there is exactly one place that computes each number, there is no drift: the invoice, the ticket, the payment link, the PDF, and the customer portal all read the same value from the same source. A deposit collected yesterday and a card charge today net correctly by construction, not by hoping two code paths agree.
This isn't a theoretical architecture decision. It was built after finding real invoices that showed "$0.00 Paid in Full" because line items hadn't finished loading, and payment links that billed the wrong amount because a cached total disagreed with the records. Those bugs are structurally impossible now.
Cards, payment links, subscriptions, and cash drawers. All flowing through your own Stripe account, with totals the database guarantees. Start free. Upgrade when you need it.