TWO WAYS TO APPLY IT
A discount — a percentage off, a fixed amount off, or a switch to a different rate schedule entirely — can be applied through a promo code entered by the visitor themselves in the app or web flow, with duration-based limits and per-user or total usage caps set by the operator.
Or it can be applied through a Bluetooth beacon at a reception desk, where a single tap validates the visit without anyone typing a code in at all. Each beacon is configured to a specific discount type, runs for roughly three years on one battery, and can be reassigned to a single site or shared across several without a hardware swap.
WHERE THIS EARNS ITS KEEP
Healthcare is one of the clearest cases: a hospital validating both staff and patient parking needs a system that can tell the difference automatically, apply the right rate to each, and hold up under high volume without a receptionist processing every single validation by hand. A retail park or shopping centre validating tenant and customer parking has a similar problem at a different scale — dozens of individual retailers, each needing to validate their own customers, without every one of them needing separate hardware or a manual process to reconcile at the end of the month.
Hotels and hospitality venues use it slightly differently again — a beacon at a reception desk lets front-of-house staff validate a guest's parking in the same motion as checking them in or handing over a room key, without a separate system to log into. And for any operator letting tenants or retailers validate their own visitors, the platform keeps a downloadable validation history, so on-charging tenants for the discounts applied on their behalf is a matter of exporting a report rather than reconstructing it from memory.
A QUIETER MECHANIC WORTH KNOWING ABOUT
For sites that need more certainty than a discount code offers, a pre-authorisation hold can be placed on a visitor's payment method upfront and released automatically once validation is confirmed — useful anywhere an operator wants a payment guarantee in place before a discount is applied, rather than trusting that validation will happen after the fact. It runs in the background of the same flow, so a visitor scanning a code or having a beacon tapped for them never sees the mechanics of it either way.
WHAT IT MEANS FOR THE REST OF THE LOT
Validation isn't a site-wide setting — it's scoped to a rate, the same way any other rate rule is. A validated rate sits in the priority list alongside every other rate on the site and only fires for a session that actually carries a matching validation — a promo code, a QR scan, a beacon tap. Every other car on the same site, at the same time, is still charged under whatever standard rate the operator has configured. A hotel running a validated rate for guests isn't discounting transient parking for the general public in the same structure; a retail park validating one tenant's customers isn't discounting everyone else's stay. Full-rate and validated sessions run side by side on the same engine, at the same time, without either one touching the other.
THE REVENUE CASE FOR RUNNING IT THIS WAY
Because validation is scoped to a rate rather than the whole site, an operator can see exactly what a validation programme costs — and what it's worth — rather than guessing at the impact on total revenue. Discounted and free sessions are logged the same way as full-rate ones, so the gap between what a validated session would have cost at full rate and what it actually cost is visible in the same reporting as everything else on site. That's a materially different position to comping cars at the gate with no record of how many, how often, or what it added up to. Seeing the actual cost of a validation programme against the full-rate revenue still coming in from the rest of the lot is what turns it from a goodwill gesture into a decision an operator can make with numbers behind it — extend it, tighten the caps, or pull it back.
WHY THIS MATTERS BEYOND CONVENIENCE
Manual validation processes create two kinds of risk: under-validation, where a visitor who should have had a discount applied doesn't get one and has a bad experience, and over-validation, where discounts get applied more generously or more often than intended because there's no real record of who validated what. A digital, logged validation removes both. Every validation applied — whether by code or by beacon — is recorded, timestamped, and attributable, which matters as much for financial reconciliation as it does for the visitor standing at the gate wondering why their discount hasn't come through.
