Ticketless Parking Software Workflow: What to Verify

This guide is a specification and demonstration checklist for integrators and operators. It does not present every step as an existing Zibor Park software feature. Use it to define the required scope when discussing our Parking Management Software, then request confirmation of the offered modules, interfaces and operating conditions.

Identify the parking session, not only the plate

Define what creates a session and what identifies it inside the system. A plate reading, a vehicle image and an authorized access decision are related records with different purposes. The brief should state how the system associates them with a site, lane, direction and time, and how an operator investigates a mismatch.

Ask what happens when the same plate appears more than once, a vehicle reverses or an entry event arrives late. The expected handling should be documented and demonstrated with an agreed test sequence. Do not assume that a repeated observation should always create a new session or always be discarded.

Plate-based operation also requires a process for vehicles whose identifier cannot be used normally. A driver may have an unreadable plate, enter the wrong plate at a payment device or need assistance. Specify an alternative that staff can operate consistently, with an appropriate record of the intervention.

Map the normal journey and its evidence

Treat this as a desired workflow, not a universal implementation. Some projects use prepaid rights, others collect fees, and some combine several user groups. State the required journey for each group rather than asking for an undefined ticketless package.

An industry example is SKIDATA’s ticketless solution description, which describes plate-based identification and several possible payment points. Its particular functions belong to that supplier. The useful procurement lesson is to define the intended identification and payment journey explicitly.

Separate payment status from exit authorization

Document which system confirms payment and what the parking application receives. An initiated payment, an approved transaction, a reversal and a parking validation should not be treated as identical events. Ask the payment provider and parking integrator to define the states that affect the exit decision.

Clarify how a driver locates the correct session and sees an understandable amount due, where charging applies. If a project requires grace periods, discounts or account-based access, state the rule and request proof that the offered configuration supports it. Do not infer those functions from a payment-terminal photograph.

Our ticketed versus ticketless parking comparison addresses the wider operating trade-offs. This article focuses on verifying the software events inside a chosen ticketless approach, including what happens when payment and parking records disagree.

Specify the interfaces at the handover points

For each connection, identify the sender, receiver, message or signal and the party responsible for integration. Relevant boundaries may include recognition equipment, access controllers, a payment service and an operator interface. Request actual documentation for the proposed components rather than relying on a statement that they can be connected.

At the recognition boundary, confirm which device performs recognition and which data it sends. The LPR Cameras and Recognition Units page is a product starting point; the software brief still needs the offered camera’s actual event and interface details. Do not assume every network camera produces the same parking event.

Ask how the receiver identifies a repeated message and what happens if acknowledgement is delayed. Specify how timestamps are interpreted across devices and sites. These are integration questions to test, not claims that the offered platform already implements a particular API, retry mechanism or event format.

Give exceptional cases a controlled route

Prepare a short exception matrix before the demonstration. Include a missing entry, an incorrect plate association, a payment without an updated session, an exit request during a connection loss and an operator correction. For each case, identify the permitted action, the responsible role and the record needed afterwards.

Agree which operations may continue during an interruption and which must wait for assistance. Reconnection should include checking what was recorded locally, what reached the central system and how differences are resolved. A statement that software works offline is incomplete without that operating boundary and recovery process.

Data access and retention need a named owner too. Ask who can view images or identifiers, export records and approve deletion, and have the operator’s responsible adviser confirm applicable privacy requirements. A product brochure does not settle the lawful basis or retention period for a particular property.

Turn the demonstration into an acceptance script

Use the same test pack for every bidder. Give each journey a reference, agreed input, expected result and evidence to retain. Follow a normal visitor and an entitled user through the complete sequence, then run the approved exception cases in a controlled environment. Record observed behaviour rather than accepting a slide showing the intended flow.

For a Commercial Parking project, involve the operator who will deal with driver questions and payment exceptions. Their tasks should be workable without granting unnecessary administrative access. Include training, support escalation and ownership of unresolved records in the handover.

We recommend bringing a one-page journey map, user-group rules and a list of existing systems to the software discussion. They let us identify what must be confirmed in the offered scope. Approve the workflow only when its normal and exceptional paths can be explained, demonstrated and assigned to the people who will run the car park.