RepairCMS POS

A repair shop's till is where the money is, and where the law is strictest. In Austria and Germany every sale has to be signed by a certified fiscal system, a cancellation has to leave a trail, and the cash drawer has to balance at the end of the day. Without a register inside RepairCMS, a finished repair was rung up somewhere else, and the job, the receipt and the cash book could disagree.

I designed and built the POS backend and the web register, working from a spec I shaped with the product owner. Much of the code was written by AI coding agents working to my architecture, and every change went through my review. The iPad register app is a colleague's work; it runs on the backend described here.

A NestJS module over MongoDB, scoped per shop like the rest of RepairCMS, with a React register on top. A sale is created once, signed by the fiscal service, paid by card or cash and mirrored into the shop's cash book. Every step is recorded on the sale itself, so the register can always say what happened and why.

Register

Quick items, barcode search, and a repair job, quote or service report loaded straight into the cart.

Fiscal signing

Every sale signed for Austria, Germany or Switzerland, with the signature stored exactly as returned.

Card payments

Card terminal payments, including card and cash split across one sale.

Vouchers

Gift vouchers sold and redeemed from RepairCMS's own ledger.

Cancellations

A cancelled receipt is reversed with the fiscal service first, then refunded to the card.

Day-end

Cash in and out, and a day-end close that compares the expected drawer with the count.

Around it: a 30-day test mode and a go-live checklist for new shops, thermal and A4 receipts by print or email, encrypted storage for every shop's fiscal credentials, and guards that stop a repair being charged twice, once at the register and once as an invoice.

1. 01

   No sale is ever charged twice

   Every sale carries an idempotency key, backed by a unique index per shop. A double tap or a retried network call finds the first sale instead of creating a second one, and requests to sign a sale are never blindly retried.

   Trade-off Every client, the web register and the iPad app alike, has to create and keep a key for each sale.

2. 02

   Keep selling when the fiscal service is down

   If the signing service can't be reached, the sale is still booked as waiting, and a background queue signs it as soon as the service is back. A real rejection fails the sale; an outage never does.

   Trade-off The register has to show and explain a waiting state, and the queue has to stop retrying rejected sales instead of trying forever.

3. 03

   Count in cents so the signed total always matches

   Totals start from the gross price in whole cents, discounts are folded into line prices, and net and VAT are derived from there. The total the fiscal service signs is the total in the shop's books, to the cent.

   Trade-off A split payment is signed with the method of its largest part, because the fiscal record takes one method per receipt; the full split stays on the sale.

4. 04

   Cancel first, then refund

   A cancellation reverses the signed receipt before any card refund is tried, and a refund that fails is saved on the sale, not only shown on screen. Money never goes back for a receipt that still counts as a sale.

   Trade-off A failed refund needs a person to follow it up, rather than the whole cancellation failing.

Live

With paying shops since August 2026

3

Countries' fiscal rules: Austria, Germany, Switzerland

2

Registers on one backend: web and iPad

1

Sale per idempotency key, however often it is sent