Self-Service Parking Payment Kiosk Procurement Checklist

This guide helps parking operators and importers prepare a comparable RFQ. It does not assert that every payment method, fiscal device, bank interface or software feature is available in the current Zibor Park product. The Self-Service Payment Kiosks page is the product reference; the quoted configuration and local payment partners must establish the actual functionality.

Write the customer journey before the bill of materials

Start with the operating model. Does a driver pay before reaching the exit, at the exit, on entry or by selecting a parking space? What identifies the stay: a ticket, license plate, space number or account? Can the user pay remotely, and if so, how is that transaction matched to the gate? Show the steps for a successful payment and for a missing ticket, unreadable plate, declined card and unpaid overstay.

Place the machine on a site plan. A pay-on-foot station needs pedestrian access and a safe waiting area. An in-lane machine needs driver reach, lane protection and a way to assist a customer without blocking all exits. Consider lighting, weather, screen visibility, language choices and the site’s accessibility requirements. A machine with the right electronics can still fail operationally if the location makes it difficult to use.

The broader Commercial Parking solution covers entry, payment and exit as a system. The kiosk specification should identify its specific role within that sequence.

Separate the four commercial responsibilities

Many quotations combine equipment and services under one line item. Break them out so buyers can compare the same scope.

Ask who provides each part, who configures it, and who is responsible when a transaction fails. A payment reader supplied by a bank or processor may not be included in the kiosk price. Software integration may need a separate statement of work. Obtain interface documents and a responsibility matrix rather than assuming two products can exchange the required transaction states.

Check the payment and data boundary

Payment-card handling is a security and compliance matter involving the merchant, device, processor and other service providers. A particular approved payment device does not make the whole deployment automatically compliant. Ask the payment provider which equipment and software are in scope, how account data is handled, who maintains the terminal, and what evidence the acquiring bank requires in the target market. Do not send card details through an unapproved parking application or store them in ordinary logs.

The PCI Security Standards Council’s PCI DSS overview is a starting point for understanding payment-data security requirements. Ask the acquirer and payment provider to identify the standards and controls that apply to the proposed deployment. A payment terminal’s approval does not, by itself, establish compliance for the complete parking system. This is a procurement check, not a claim about Zibor Park certification.

Define data retention for plates, tickets, payment references and operator actions. The parking system may only need a transaction token or paid/unpaid status; the payment provider should define what crosses each interface. Confirm local privacy and tax rules with qualified advisers for the operating market.

Demand a demonstrated exception workflow

A good RFQ asks for failures as well as features. What does the driver see if the payment network is unavailable? Can staff find a transaction when a receipt printer runs out? How does the system avoid opening the barrier twice for one paid exit? What happens when a tariff changes during a stay, a card is declined, or a user pays for the wrong plate? The supplier should describe both the user feedback and the operator recovery path.

For testing, use a non-production payment environment supplied by the processor. Do not rely on an HTTP success message alone: reconcile the kiosk event, parking entitlement, payment authorization, receipt and exit event. Record which system is the source of truth for each status. If the proposal includes offline operation, require a written account of limits and later reconciliation; do not infer it from a “network ready” label.

Send an RFQ that can be priced and accepted

Include the site plan, operating model, projected transaction pattern, accepted payment methods by country, ticket or plate identification method, expected interfaces, accessibility and environmental requirements, network ownership and service hours. Request an itemized offer with named hardware, payment components, software licenses, integration work, consumables, training and warranty boundaries. Ask for acceptance scenarios covering normal payment, declined payment, missing identifier, network outage and reconciliation.

For a project inquiry, share the intended transaction flow and the payment partner or acquirer already selected. We can discuss the relevant Parking System Equipment and clarify which product documents are available. The final payment method, certified interface and commercial terms must be confirmed in the project quotation.