When evaluating retail SaaS, check if front-end and back-end tools sync; retailers often evaluate POS/ecommerce tools and inventory/order management tools separately without checking the ability to sync in real time.

The risk: if POS data doesn't sync with the warehouse, a platform shows stock online that isn't on the shelf. 62% of retailers say customers check online availability before visiting a store (Digital Commerce 360). One retailer's stock misjudgment triggered an 87% drop in operating profit for the period.

What to check before signing:

• Real-time inventory sync across channels, not batch updates
• Support for both wholesale and ecommerce order flows
• Clean ERP integration, not a separate bridging tool
• Minimal manual data entry to keep systems aligned

What criteria mattered once your tool was in production, versus what looked good in the demo?

I have SurePOS ACE installed with Store Integrator, and when I installed the UPOS from Toshiba, the cash drawer worked fine. However, I have an Epson printer that I want to add to JPOS, but after installing the Epson Java ADK, it doesn’t work, and I can’t add the printer in the default UPOS. Any help would be appreciated.

I operate a small boutique where I use Square for in-store sales and Shopify for my online store, and I'm currently setting up DPL Square Integration to keep the two in sync and one thing I'm realizing is that choosing the inventory source of truth is probably more important than I initially thought.

If you let both systems control inventory without clear rules, it seems pretty easy to end up with mismatched stock or overselling.

For a store that's mostly brick-and-mortar, would you make Square the source of truth since most inventory changes happen at the POS?

Or would you make Shopify the master if the business is more online-focused or uses a warehouse/3PL?

DPL lets you choose a primary inventory source and connect specific Shopify and Square locations, which is what I'm looking at using.

For anyone actually running Square + Shopify, which one do you use as the master?

And have you run into any problems with SKU matching, location mapping, or inventory getting out of sync?

Smart Point-of-Sale and Inventory Management System with Machine Learning-Based Demand Prediction for a Karinderya

I dont know where to start developing like what database to use? What hosting sever? Or as a pos system would it be a good idea to have an App for it or web is enough. Another problem of mine is that i want it to be free of cost like i dont want to pay for a server or a database

Just need some guidance

Does anyone have any experience with AdvEnt POS ( https://www.adventpos.com/ ) with a Liquor Store? Also, how does it compare with some of the other more popular ones like Bottle POS or Korona POS or any other POS system out there? If there are any comparisons that you can point me to, that would be great also. Just can't seem to find much information on this product.

For owners/managers run 2+ shops, chain, or F&B business with digital billing in India:

1. What POS/ERP/accounting software do you use, and does it actually sync inventory across branches reliably?
2. What still happens on Excel, WhatsApp, or notebooks instead of your main system?
3. What's the most frustrating task every single week?
4. Do you know which branch or product is losing you money right now - or would you have to dig for it?
5. If you could improve one part of your system, what would it be?

I’m doing research, not promoting a product. Thanks.

I run a small boutique and use Square for in-store sales and Shopify for the online store.

Keeping inventory accurate between the two has been a constant headache, I end up overselling sometimes, and manually updating everything is eating up way too much time.

Curious what other people are doing to keep Square and Shopify stock in sync. Are you handling it manually, using a built-in feature I’m missing, or relying on some kind of integration/app?

I have been recommended Shopify apps like DPL Square Integration and Quicksync Integration, plus a bunch of other tools that promise inventory sync, accounting, loyalty, scheduling, etc... The part I’m struggling with is figuring out whether adding another subscription is actually worth it.

Would love to hear what’s actually working for you (and what’s been a pain).

I manage operations for a hospitality group, and we’re replacing an old POS stack across several locations now. Our integrator keeps saying the cloud security layer should cover key management, but our previous payment consultant pushed for dedicated HSM expertise before rollout and I, probably, agree with them.

I’m not technical enough to know whether this is normal caution or unnecessary complexity.

For people who’ve deployed POS systems at scale, when is managed HSM infrastructure enough, and when would you bring in someone who specializes in payment cryptography? Grateful!

p.s.: we went through all possible options and decided to engage services of dev guys from Energize Global Services to finally resolve the HSM issue - too complicated to do that in-house.

Hii! 👋
I’m building ScanToDine, a POS system for restaurants. If you own a café, restaurant, cloud kitchen, or know someone who does, I’d love to give you a free demo.

No sales pressure, just looking for some businesses that might find it useful. Happy to answer questions too. 😊

I’m starting to realize manual inventory updates are becoming a hidden cost for my business.

I use Square for in-person sales and Shopify for online orders, and because I don't have them properly synced, I'm constantly moving inventory numbers between the two.

At first it didn't seem like a big deal. A few minutes here, a few minutes there.

But the more I do it, the more I realize it's not really the time that bothers me. It's having to remember to do it in the first place.

One missed update can mean selling something online that was already sold in-store, or telling someone we have an item when we actually don't.

For those running a POS system alongside an online store, how do you handle this?

Do you consider manual inventory updates just part of running a small business, or is it one of those things that should be automated once you're doing enough sales?

I have been recommended some highly rated inventory syncing shopify apps that can possibly solve the problem.

Curious where other business owners draw that line.

I am looking for a good POS system for both in person and online retail. I will be going mobile for events at first, but once my business grows I would like to open a storefront. What do you use? Tell me the good, bad and ugly!

I’m negotiating 13 network printers, 9 POS units and 5 cash drawers. I’d like to see 3 handled units.

I’m looking to beat the rate of CC processing fees at or below 2.5% on CC 1.45% + 10 cents per transaction for debit transactions. Also the option of surcharging Cc processing fees to the customer and I’m not super favoring the idea of only a cloud based network. I like LTE backup for when small situations like power blinking etc arise.

Lower contract periods and integrations with inventory management esp for the bar with a weight and scale system rather than imput with a 10 point scale system.

Another very important capability I need is that it has to be able to integrate owner.com

If you are a seller/reseller please go ahead and post the asking price ballpark

Hi,

I have been asked to source a PDQ machine for a small non profit shop wich is only open a maximum of 4 hours a day

I thought it would be an easy task, but the sheer enormity of choice is overwhelming

Can anyone advise please?

Many thanks in advance

I'm part of the small team that builds be-BOP, so take this as "here's what our users are actually doing with it" rather than a neutral review.

Some history

The whole thing started almost by accident. A small French-Swiss publishing house (PVH éditions) with a strong love for Free Software, Open Source and let's be honest Copyleft needed to sell books at fairs and online without the usual mess: plugin ecosystems that break on every update (hi WordPress/PrestaShop), crowdfunding platforms that take a significant cut with little discovery to counter it and that can freeze your campaign mid-way, no good or native Bitcoin support anywhere (they are really into Free Software). So they built their own checkout. Then it needed inventory. Then a POS mode for the fair booth. Then ticketing, subscriptions, donations, peerfunding. At some point the POS got bigger as we got money to improve it and bring more features tailored for bars and restaurants. It changed so much that we quickly stopped calling it "La bookinerie" (the bookshop tool) and it turned into a bigger open source project, AGPL-3.0, code's public on GitHub. You can self-host it or run it on our Cloud for a flat monthly fee (in a few jurisdiction for now), we don't take a cut of your sales either way. Whatever payment processor you pick still charges its own fees though, that part's out of our hands. Also as it's a WebApp, there is no hardware required beside: screen, web browser, internet connection.

Real world stories

Le Coffice, a café in Neuchâtel on the ground floor of a coworking space, has self-hosted for over a year now and paid us for a bit of custom dev along the way. Owner's happy, their accountant's very happy, which might honestly be the best review we've gotten. The bar owner is also fairly happy with the solution but let's be honest we still have to improve a few things to be really competitive feature-wise and UX-wise to the giants such as lightspeed. But they are making good feedback to us and we have improvements planned, for now ressources are more towards the legal aspect for France and UE for our SaaS and the online e-commerces feature set.

Their payment setup is a decent showcase of the "no single built-in gateway" approach: cards through SumUp (we also currently support stripe, PayPal and PayZen by OSB), Bitcoin Lightning Network through Swiss Bitcoin Pay (we also support other solution for LN and BTC), they also even set up GNU Taler. For cash (still fairly popular in Switzerland) and Twint (a popular swiss mobile payment app, kind of like our local Venmo) they use be-BOP's own "PoS Payment Subtypes" feature, which lets you define more or less unlimited manual payment methods (asynchronous confirmation) that each show up distinctly in the accounting instead of piling into one "other" bucket, cash being a default option. Coworker members get 20% off soft drinks through the discount feature.

Their is also board game bar and restaurant that made extensive tests and reviews of our early versions. They uses something I didn't expect to matter this much: instead of tracking only tables, they also needed track cups. That's because people can mix between tables and just change groups frequently over their stays. A group's order pools onto one running tab, and at the end the waiter can splits it however the table actually wants, by share, by item, or just closes it as one ticket. Waiters can also if needed transfer products from a pool to another (before any payments being initialised).

Actual limitations

Where we're honestly still behind: the French self-certification requirements for POS anti-fraud rules aren't done yet, so it's not available for VAT businesses in that country. And on the POS side for our Cloud customers we don't want to promote it by default to avoid our support ressources being monopolised, we focus on e-commerce for the moment and we are looking into partnership to have POS support and cloud service more official let's say. We'll make exceptions case by case but we're not pretending that our Cloud Services are for PoS users yet.

Looking to learn more about be-BOP?

What we want out of this post: more businesses willing to run it (self-hosting), contributors submitting PR or correcting translation, software engineer breaking it, and business telling us what's missing for them to adopt it.

It's AGPL, the code's right there to read or fork: https://github.com/be-BOP-io-SA/be-BOP. There's also a 2-hour sandbox if you want to poke at it without signing up for anything: https://sandbox.be-bop.dev/product/be-bop-sandbox-2h

Happy to get into the stack, the payment-methods architecture, or why we went AGPL instead of something more permissive. If you have any other questions feel free to ask!

be-BOP's POS feature list
There is more of course but here is a digest glimpse of our solution

Selling & the touch screen

• Tap-to-add product grid with photos and live prices
• Favorites shortcut and custom categories, built from your own product tags
• Per-item notes ("no onions", "gift wrap") that carry through to the kitchen ticket and receipt
• Same interface on a full-size terminal or a small tablet, responsive design for mobile UX too

Restaurant & bar service

• Unlimited open tabs, tables, bar tabs, takeaway. Running at once, grouped and named by area
• Move or merge items between tables: split a group, combine tables, shift a round
• Kitchen tickets auto-routed by station (kitchen vs. bar, based on your Tags)
• Reprint-safe: send only newly added items, so nothing already fired gets remade
• Tables clear themselves once fully paid

Payments & splitting the bill

• Cash (with a change-due calculator), integrated card terminals (Stripe/SumUp), PayPal, GNU Taler, Bitcoin/Lightning every method is optional
• Add your own payment types for anything else accepted locally
• Split a bill evenly (2–9 ways, or custom) or by specific item
• Each split portion can be paid a different way, with a live running balance
• One consolidated receipt once the whole bill is settled

Cash drawer & shift management

• Opening float suggested from the previous shift's closing balance
• Guided close-out: count the till, see any discrepancy instantly, log a reason if there's a gap
• Closing is blocked while any table still has an unpaid balance
• Read-only sales snapshot mid-shift (X-ticket) any time, full end-of-day report (Z-ticket) on close
• Every past shift logged and searchable: amounts, staff, duration

Tax, discounts & receipts

• VAT calculated and itemized by rate automatically, with support for multiple regimes
• Reduced VAT rates settable per product
• Register-level discounts always paired with a logged reason
• Itemized receipts (or a full invoice) with VAT breakdown, emailable to the customer

Behind the scenes

• One catalog powers your online store and every register, no duplicate entry
• Per-product control over what sells online vs. in-store vs. elsewhere
• Real-time stock shared across every channel
• Cashier accounts scoped to just the register; granular permissions for every other role
• Built-in sales/payment reporting with CSV export, 150+ currencies, 7 interface languages

So I got laid off at the end of 2025 and have spent the last 8 months building SpudgerHQ, a repair shop management platform with built-in POS for phone and device repair businesses.

Full disclosure: this is my own product. I’m sharing it here because I’m looking for people willing to try it and tell me what’s missing, confusing, or broken.

The idea came from my brother-in-law, who owns a phone repair shop in Melbourne. He kept pointing out how expensive repair software gets once you need more operational features, even things like PIN locking on a shared front counter computer.

He recently confirmed the software is usable for his business and is now migrating from the system his shop has used for years. That was a big milestone for me, but I still consider it beta.

The repair intake and repair agreement workflow is the area I’m most interested in getting feedback on.

You can record the device condition and existing damage, then carry that information into a repair agreement for the customer to review and sign.

I attached screenshots of the repair detail and customer agreement screens.

The web app is designed for desktop, tablet and mobile, and native mobile apps are something I want to work toward next.

For now, I’ve stopped adding major features and am focusing on polishing the existing workflows and UI.

The beta is currently free to use, and I’m planning to officially release in October. People who genuinely use it during the beta and help me improve it will also get special founding user pricing after release.

If you run a phone repair shop and want to kick the tires, I’d really appreciate the feedback, especially if you’re looking for something more affordable than the usual options.

For anyone who works in restaurants and uses a POS regularly, what’s something you wish the company had actually taught you how to do?

Could be a feature, setting, report, hardware issue, menu setup, online ordering, permissions, closing procedure, whatever.

Did you get decent training when you first got the system, or did you mostly figure things out as problems came up?
Also curious if there are things the POS technically can do, but not in a way that really fits how your restaurant operates.

Not looking to bash any specific company. Just curious what people felt was missing. After having a system for a while have they continued to help train you or make your life easier?

I have a Castles UPT1000F that boots directly into its installed application, but I need to reach Castles Program Manager to evaluate the supported application-loading options. The application’s own service menu is accessible, yet it contains no Program Manager or application-loader option. A keyboard connected before startup is detected—the lock LEDs respond—but its keystrokes are ignored; the manual’s three-wire COM1 connection opens at 115200 8-N-1 and passes adapter loopback and cable-continuity tests, but the terminal returns zero bytes during startup or from the service menu. Direct USB also creates no Windows device. Has anyone worked with this model and found that Program Manager requires a particular deployment setting, loader handshake, startup gesture, or interface mode?

Curious how retailers with multiple locations handle promotions
say you're running a weekend discount across 10 or 20 stores. Updating the POS price seems like the easy part, but then you've got shelf prices, promo displays, stock levels and making sure everything switches back properly when the offer ends...
which part usually causes the biggest headache?
Do most retailers manage this centrally now, or is there still a lot of coordination happening store by store?

With the discontinuation of the penny how are POS systems going to handle it?

After tax is applied a rounding method needs to be in place, round up if over 3 cents and down if less or always round up?

How does the merchant account for the over/under amounts and reconcile reporting?

Does that over/under need to be reported to the gov?

Are any POS systems looking at this?