POS hosting where the till keeps taking money offline.
A website going down is an inconvenience. A till going down is a queue of people holding items they cannot buy, in front of you.
The shop cannot wait for the network.
Running a till through a website means the shop's ability to trade now depends on a request completing.
Sales that queue locally and reconcile later
A brief connection drop must not stop the till. Transactions are taken and synchronised when the link returns, which is the difference between a slow moment and a closed shop.
One stock number, two channels
The last item cannot be sold at the counter and online at the same time. Stock decrements are serialised across both rather than each channel holding its own view.
Terminals that do not share a cart
Two staff on two tills must have entirely separate sessions. A shared session is the failure where one customer's items appear on another's receipt.
Peak is a time of day, not a campaign
Retail load concentrates at lunchtime and after work rather than around a marketing send, and capacity is planned for that rhythm.
End-of-day reconciliation that balances
Takings have to match the till. Order records are retained and backed up because they are the accounting record, not just site data.
Downtime has a queue attached.
Every other WordPress failure is measured in lost visitors. This one is measured in people standing in a shop, which changes what the priorities are.
- Offline transactions queued and reconciled
- Stock decrements serialised across channels
- Sessions isolated per terminal
- Order records retained as accounting data
The transaction has to complete now.
A second of latency at a till is a second with a customer watching. This is the one WordPress workload where response time is measured socially.
What we change for point of sale
The shop trades in real time in front of a person, which is a stricter requirement than any web page has.
| Setting | What we do | Why |
|---|---|---|
| Connection loss | Transactions queued locally and reconciled on return | A till that stops when the network hiccups stops the shop trading, with customers already holding the items they came for. |
| Stock decrements | Serialised across counter and web channels | Both channels reading their own stock view means the last unit gets sold twice, and one of those customers finds out afterwards. |
| Terminal sessions | Fully isolated per till | A shared session puts one customer's items on another's receipt, which is discovered at the counter in front of both of them. |
| Capacity rhythm | Planned around trading hours rather than campaigns | Retail peaks at lunchtime and after work every day, which is a repeating shape rather than the one-off spike marketing produces. |
| Order retention | Treated as accounting records rather than site content | Takings must reconcile against the till at the end of every day, so those rows are financial evidence and not something to prune. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
What happens at the till if the internet drops?
Can the same item be sold in store and online at once?
Can two tills interfere with each other?
Are POS orders included in backups?
Keep the till open.
Move the store across. Migration is free, terminals included.