Our own product — municipalities, cities and associations
MuniPass — resident parking and pass lending for municipalities
A parking permit is at once a decision about a quota, a payment, and an answer somebody needs on the street in seconds. MuniPass holds those three against the same data — and carries, beside them, the lending of the annual passes the same municipality owns.
The brief
A parking permit looks like a form and is three things at once: a decision about how many permits an address may hold; a payment in which the municipality has to remain the payee; and an answer an enforcement officer needs at the windscreen in seconds. In administrative practice those three sit in different systems — or in none.
The solution
The address quota is checked against the official building register and the federal address data, not against a line somebody typed. Payment runs through the municipality's own acquirer contract, so MuniPass is never the payee at any point; recurring fees produce a SEPA collection file for the municipality's own banking or for k5. Roadside checking is a screen of its own, with a role of its own, that answers exactly one question.
The outcome
Permit, payment and checking hang off the same data: whoever checks sees no residential address, and whoever applies never recalculates a quota. The parking module is finished and ready to be rolled out.
A closer look
An authority introducing resident parking rarely buys software for one problem. It buys it for three that get in each other’s way.
The first is an administrative decision. How many permits may fall to one address is a number per address — and the address itself is where this goes wrong in practice. MuniPass therefore checks against the official building and dwelling register and the federal address data, rather than against whatever somebody typed into a field. When a quota is exhausted the application says so before anyone has to work it out; an application is not yet a permit but sits with the office for review, and a refusal carries its reasoning in the case file.
The second is money, and this is the decision that shapes the product most.
The acquirer contract stays with the municipality — MuniPass is never the
payee. That is more awkward to build than the usual arrangement, where the
platform collects and forwards, and for a public body it is the only route that
stops the question of holding citizens’ money in trust from arising at all.
Recurring fees run by SEPA direct debit: the application produces the collection
file in pain.008 format, which the office uploads to its own banking or to k5.
First and recurring collections sit in separate blocks, because a bank processes
them differently, and the file comes in two schema versions, because the bank
decides that and we do not.
The third happens on the street and takes seconds. One screen answers exactly one question — may this vehicle be here? — from the plate, the permit reference or the printed QR code. Enforcement officers get a role of their own that sees only that screen: no bookings, no memberships, no residential addresses. Data minimisation here is not a setting but the definition of the role. Where a permit covers two vehicles, an NFC tag in the car switches which plate is valid — a tap, with no camera and no sign-in — and every switch is logged with its time.
The pass lending the platform began with has remained beside it as a second module. A municipality that owns three Klimatickets and lends them to its residents does not have a software problem — until the second request for the same week. A public calendar shows real availability, handover and return are documented with a signable PDF, and a waiting list offers a freed-up day to the next person automatically.
That both modules run on the same multi-tenant platform is not technical self-indulgence. Each municipality appears under its own presentation, with its own logo and colour — because a service the municipality provides should look like the municipality and not like a contractor.