Quick answer:
Parkcore's shop and bar now take card payments through the same terminal and the same underlying payment connection used everywhere else in the park — reception, owner payments, retail — rather than a separate EPOS contract with its own till, its own reporting, and its own disconnected record of what was actually sold. A sale at the bar updates stock automatically and shows up in the same reporting as everything else, because it's genuinely part of the same system, not a different product pretending to be.
Ask most holiday parks how their on-site shop or bar takes card payments, and a surprising number will describe two completely separate systems quietly running side by side: the booking and guest management software on one screen, and an entirely different EPOS till — its own contract, its own hardware, its own reporting dashboard nobody fully trusts — sitting a few feet away. The two were never actually built to talk to each other. They just happen to occupy the same building.
How "bolted on" usually happens
This isn't really anyone's fault. Booking software companies are, understandably, experts in bookings — availability, guests, owners, pitches. Point-of-sale companies are experts in tills — baskets, pricing, card processing, receipts. Historically, a park wanting both has had to buy both, from two different companies, and accept that connecting them meant, at best, exporting a sales report from one system and manually reconciling it against the other at the end of the week. At worst, it meant not connecting them at all, and simply trusting that both tills were doing roughly the right thing independently.
That arrangement works, in the sense that both systems individually do their job. What it can't do is show a genuinely unified picture — because the information genuinely isn't unified. It's two separate records of two separate businesses that happen to share a car park.
What "actually integrated" looks like in practice
Parkcore's shop and bar now process card payments through the same terminal connection already covering reception and owner payments — one underlying payment setup per park, not a separate contract and a separate piece of hardware logic for retail specifically. A sale at the till reduces stock automatically, through the same movement-logged system covered in our piece on stock's audit trail — not a nightly batch sync, not a manual stock adjustment someone has to remember to make, but an immediate, accurate update the moment the sale happens. Bar tabs work through a hold-then-complete pattern — reserving an amount when a tab opens, completing the actual total when it closes — rather than requiring a fresh card tap for every single round, which is specifically how a bar actually operates rather than how a generic retail till assumes it does.
Takings from the till show up in the same reporting as everything else — covered in its own piece — alongside guest payments and owner payments, not as a separate export that needs manually stitching into the rest of the picture.
Why "it's all one system" is the actual point
The value here isn't that card payments at the bar feel slightly nicer than before — it's that a sale at the bar is no longer information trapped in a separate system. It affects stock levels the moment it happens, which affects reorder suggestions, which affects what gets ordered next. It shows up in takings reporting the same way a guest's booking payment does, so a manager reconciling the day doesn't need to check two unrelated dashboards and hope they roughly agree. The shop and bar stop being a semi-detached annexe to the real business and become a properly connected part of it — because, underneath, they always should have been.
How this compares to typical park EPOS setups
Most holiday parks running a shop or bar alongside booking software are running exactly the two-system arrangement described above — a separate EPOS platform, a separate contract, a separate login, connected to the booking system not at all or only loosely, through manual exports if at all. It's a genuinely normal, accepted way to run a park, simply because the alternative hasn't usually existed as an option. A handful of larger, more expensive hospitality platforms do offer genuinely unified retail and booking — but typically aimed at a scale and price point well above what most family-run parks would consider for a site shop and a bar.
Parkcore's position is that a holiday park's shop and bar aren't a separate business bolted onto the real one — they're part of the same operation, selling to the same guests and owners the rest of the system already knows about, and the software should reflect that rather than forcing a park to run two unconnected systems and reconcile the difference by hand.
What's still being finished
Bar tab pre-authorisation — the hold placed when a tab opens — is the piece still being finalised rather than fully complete; straightforward single-transaction sales at both the shop and the bar are live and tested today. We'd rather say that plainly than let "shop and bar are live" imply every detail of bar tab handling is finished when the core of it is still being proven out. We expect that by Mid November this will have been proven and tested with Worldpay.
No card data passes through either system unnecessarily
The same security standard covered in our piece on data isolation and security applies here specifically: the terminal itself handles the card, and what gets stored afterward is deliberately minimal — the last four digits, the card brand, an approval code, a transaction reference. Bringing retail into the same connected system as the rest of the park doesn't mean widening how much sensitive card data gets stored or who can see it; if anything, having one properly secured payment connection per park, instead of two separate systems each with their own card-handling practices, narrows the number of places that data could ever be exposed.
Key takeaways
- Shop and bar card payments now run through the same terminal connection as reception and owner payments, not a separate EPOS system.
- A till sale updates stock automatically and immediately, feeding directly into reorder suggestions and reporting.
- Bar tabs use a hold-then-complete pattern suited to how a bar actually operates, rather than requiring a card tap per round.
- Most parks run a genuinely separate EPOS system for retail, reconciled against booking software manually if at all — this is the normal, accepted arrangement industry-wide.
- Bar tab pre-authorisation specifically is still being finalised; standard shop and bar sales are live and tested today.
Frequently asked questions
No — card payments at the shop and bar run through the same terminal connection already used for reception and owner payments, as part of one system rather than a separate product.
Yes — a sale, void, or refund updates stock immediately through Parkcore's logged movement system, with no manual stock adjustment or batch sync required.
Parks running a shop or bar alongside their booking software can see how Parkcore brings retail, reception and owner payments together through one connected system, rather than two that happen to share a building.
