Downloads
Eine Kasse, jedes Gerät.
macOSErkannt
Version 1.10.27 · Apple Silicon · .dmg
Für macOS herunterladenAuf einem Intel-Mac? Intel-Build herunterladen
Jede App verbindet sich mit dem kostenlosen WordPress-Plugin — installiere es zuerst.
Desktop
iOS und iPad
Android
Web
Dein ShopWooCommerce+ WCPOS-Plugin
So passt alles zusammen
Ein Shop im Zentrum. Jede Kasse synchron.
- Ein Plugin ist die gesamte EinrichtungDas kostenlose Plugin fügt deinem WooCommerce-Shop eine sichere REST-API hinzu. Das ist die ganze Installation — nichts muss pro Gerät gehostet oder konfiguriert werden.
- Jede App liest und schreibt im selben ShopKassiere einen Verkauf am Desktop, erstatte ihn auf deinem Telefon — ein gemeinsamer Bestand an Produkten, Bestellungen und Kunden, der in Echtzeit aktualisiert wird.
- Offline-first, damit die Kasse nie stehen bleibtJedes Gerät arbeitet auch ohne Verbindung weiter und synchronisiert sich wieder, sobald es online ist.
Was synchron bleibt
- Produkte & Preise
- Lagerbestände
- Bestellungen
- Kunden
- Steuern & Belege
Erste Schritte
Drei Schritte bis zum ersten Verkauf
Von Anfang bis Ende dauert es etwa zwei Minuten.
- 1
Kostenloses Plugin installieren
Die Grundlage, mit der sich alles verbindet. In deinem Dashboard: Plugins → Installieren, dann nach „WCPOS“ suchen.
WCPOSKostenlos · GPL
Neueste Version 1.10.20 · WordPress 5.6+ · WooCommerce 5.3+ · PHP 7.4+
- 2
Wähle dein Gerät
Alles kostenlos, alles synchron. Nimm das oben erkannte Gerät oder eines dieser Geräte.
Desktop-App
iOS & iPadBeta
AndroidBeta
- 3
Möchtest du mehr? Wechsle zu Pro
Ein lizenziertes Plugin, das auf derselben Grundlage Terminalzahlungen, Erstattungen und Bestandskontrolle ergänzt.
Die vollständige Kasse freischalten
Zahlungen, Erstattungen, Bestand & Preise, Bestellverwaltung, Tagesabschlussberichte, Multi-Store und vorrangiger Discord-Support.
Versionsverlauf
Was ist neu
Aktuelle Änderungen — jede App teilt dieselbe Versionslinie.
Versionshinweise stammen von GitHub und werden möglicherweise auf Englisch angezeigt.
1.10.20Neueste Version23. Sept. 2026
- Checkout no longer reports "Checkout failed" for a sale that reached the store. If the till was busy sending another change, or an earlier attempt had failed, the checkout screen could give up waiting even though the order had been saved. It now hears back as soon as the order is saved, and pressing Checkout again after a failure tries straight away.
- Search repairs a damaged search index instead of failing at every launch. When the saved search index could not be read, search stayed broken with "Failed to initialize search". The index is now discarded and rebuilt from the till's records.
- Gateways that take no payment at the till — quotes, invoices, purchase orders — now close the order with the Order Status you set for them. The checkout used to succeed but leave the order at POS - Open. Only gateways with an Order Status saved in POS > Settings > Checkout are affected, and the order is not marked paid.
- Refunds that arrive from a payment gateway now respect your POS customer-email settings. A refund recorded by a gateway's webhook could email the customer even with POS customer emails switched off; refunds made in wp-admin or at the till were not affected.
1.10.1919. Sept. 2026
- A till no longer loses live records during its startup tidy-up. With the POS open twice on the same device, the tidy-up could mistake live records — including the sign-in row — for damaged ones and remove them. It now leaves alone anything it cannot fully account for. Web merchants receive this through WooCommerce POS plugin 1.10.19, which serves the storage worker; desktop and phone apps carry it in this release.
- A sale that could not be sent because the till was signed out now waits for sign-in instead of being given up on. The cashier is told as soon as it happens, and the sale sends itself once the session is back.
- A refused POS request now says why it was refused. A 401 from the POS routes names the reason in the response and in Health > Logs, instead of only reporting that the request failed.
1.10.1818. Sept. 2026
- A web till with the POS open in more than one tab repairs its local database again. Since the 1.10 storage repairs shipped, every repair on web was refused whenever another tab of the same store could be open, so a damaged record stayed damaged and the same storage errors repeated on every sync. The tab that leads the store now owns the repair and the other tabs follow it. Web merchants receive this through WooCommerce POS plugin 1.10.18, which serves the storage worker; desktop and phone apps carry it in this release.
- Voiding an order the server had refused no longer fails silently. When an order could not be created on the server (for example while the till was signed out) and the cashier then voided it, the void raised an error nothing caught and the order stayed in the cart. The till now removes the order and its failed request locally and confirms the removal; any other failure to void shows an error instead of nothing.
- A till opened from WordPress admin no longer sends an invalid sign-in token on its first requests. A request made before a token was stored carried the word "undefined" as its credential, which the server rejected as an invalid token instead of falling back to the WordPress login session. Such requests now carry no token, and a retry after a token refresh no longer keeps the old token in the request address.
- A plugin update no longer restores cashier permissions the merchant had removed. Every update re-granted every default capability, so a store that had turned off product or coupon editing for cashiers saw it come back after each release. Updates now grant only capabilities that are new since the last update; a deleted cashier role is still recreated whole.
- Product search on the older
wcpos/v1routes splits the typed text the same way as the rest of the POS. Punctuation stays literal and single letters and common words count, so "IT 5012" no longer searches as "5012" and "0,4" is one term. - An order digest write no longer fails on a busy MariaDB. The checkout-lane digest write now retries once on lock contention, as the product and customer digests already did.
- The older order-update route checks order ownership the same way as the current one under HPOS. A role that can edit its own orders but not other people's is treated the same on both routes. Cashiers are unaffected.
1.10.1716. Sept. 2026
- A till no longer gets stuck at login on "Something went wrong: useStoreSession must be called within an active store session". A damaged range in the till's local database made the login write fail and left the cashier on a red banner. The write is now repaired and retried, and if the saved session still cannot be honoured the till returns to the store list with a message instead of the banner. If the site has to be added again, it opens a fresh local database and does not pick up sales still waiting to sync in the old one. Web merchants receive the storage repair through WooCommerce POS plugin 1.10.17, which serves the storage worker; desktop and phone apps carry it in this release.
- A newly connected till no longer misses a stock change made in its first minute. A product set out of stock on the server shortly after a new device, login or reset stayed "in stock" on the till indefinitely. The till now records the server's position before the first browse, so the change arrives with the next sync.
- A variation whose stock is managed at product level shows the right stock in the variation picker. When the parent product sold out, the picker's badge and Add to Cart button kept saying "in stock" for up to five minutes. They now read the parent's stock, the same way the cart does.
- Switching stores no longer carries the previous store into the first requests of the new one. Requests made while a switch was still completing used the outgoing store, so the first products or barcodes could belong to it until the next sync. Pro multi-store only.
- Health > Logs records a screen error the app catches as "Part of the screen failed to load", and reports it when you have allowed error reporting.
1.10.1616. Sept. 2026
- Cashiers can sell an out-of-stock variation again when "Avoid overselling" is off. The variation picker's Add to Cart button disabled on stock alone and ignored the store setting, so an out-of-stock simple product could be sold but an out-of-stock variation could not. The button now follows the same rule as the cart: it disables only while the setting is on and the variation is unsellable.
- An idle web POS no longer sits at 30% CPU after the cashier stops. Local database cleanup compacted storage fifty records at a time and rewrote every index between batches, so a till with a large backlog of deleted records churned for minutes. Cleanup now compacts in one batch and rewrites the indexes once. The web app loads its storage worker from this plugin, so web merchants receive this fix through this update.
- Health > Database no longer shows "checking…" forever on a server that reports high load. A host that stamps every response as under high load while answering in a tenth of a second kept the till backed off, and the backed-off checks always started with the same three record types, so the other six never got a turn. Checks now rotate fairly, all record types are probed on each backed-off tick, and a "high load" header on a fast reply no longer counts against the server.
- Health > Performance says what pace the till is keeping with the server, and why. One line at the top of "Your server, over time" reads Normal pace, Easing off (with the factor and the reason), or Paused until a given time.
- Tills stop showing products the store has hidden from the POS. Between 1.10.1 and 1.10.14 the POS product search could return a hidden product (fixed in 1.10.15), and a till that searched during that window kept a copy. Upgrading now writes a fresh removal notice for every hidden product and variation, and every till drops its stale copies on its next ordinary sync, with no reset or manual sync needed.
- The POS Only and Online Only counts above the WooCommerce products list are accurate. They counted trashed and auto-draft products that the view never lists; they now count the same statuses as WordPress's own "All" view.
- The server no longer reports high load from a guessed CPU count. On hosts that hide
/proc/cpuinfo, the load average was divided by one CPU, so any load above 1.8 read as "high" forever and every till slowed its sync. When the CPU count is unknown, no load is reported. - The connection check can no longer be served from a page cache. The public ping was answered before the cache-control headers were set, so a cached "ok" could mask an outage for the cache's lifetime. It now sends the same no-store headers as every other POS response.
1.10.1515. Sept. 2026
- Tills no longer grow to gigabytes of memory over a long shift. The product search index was keeping up to a hundred complete copies of itself in memory as it updated. Measured on a test store, memory after cleanup grew from 46 MB to 404 MB in an hour before the fix and from 47 MB to 160 MB after it; this is what took one merchant's till to 3.2 GB over an eleven-hour shift.
- The Logs screen no longer freezes the app.
- Product search finds a product however you order the words. Searching "blue shirt" and "shirt blue" now return the same results.
- Start-up repair of a damaged local database is safer. Oversized internal change logs are now bounded and recovered without unbounded reads, and the app no longer rewrites bookkeeping records that have not changed. The web app loads its storage worker from this plugin, so web merchants receive this fix through this update rather than through the app bundle.
- A sync refresh that returns the same record twice is rejected instead of being applied against an incomplete snapshot, which could previously prune records that were still present on the server.
- Product search shows every match again. When a search matched more products than fit on the first page, the Products page stopped at that page and scrolling to the end loaded nothing more.
- The product search index repairs itself again. When the app detected that the index had drifted from the product data, the rebuild silently did nothing, so stale or missing search results stayed that way until the app was reinstalled.