Home › Insights › Case Studies › Park Pay
Case Study SaaS & Platforms

Park Pay: A parking platform with subscriptions and an ad marketplace

Park Pay

Introduction

Urban parking looks like a solved problem until you try to sell it two ways at once. A driver arriving today wants a space for an hour. A commuter wants a permit that renews without being thought about. An operator wants both, from one system, across every site they run — and would quite like the audience standing in their car parks to be worth something beyond the parking fee.

Most platforms pick one of those and bolt the others on. Park Pay wanted them designed together.

Key Challenges

  • Two booking models in one product — On-demand daily parking and subscription permits have different billing, different availability logic and different expectations. Both had to feel native rather than bolted together.
  • An advertiser ecosystem, not an ad slot — Advertisers needed to onboard themselves, build campaigns, place them and measure them, without the operator acting as an intermediary for every step.
  • Concurrency and real availability — Availability has to be accurate at the moment of booking across multiple sites, under load, or the product breaks its core promise.
  • One experience, three audiences — Drivers, operators and advertisers use the same platform for entirely different reasons. A single interface had to serve all three without becoming a compromise for each.

Our Approach

Kansoft treated this as one product with two business models rather than two products sharing a login:

  • User journey mapping first — Separate flows for the occasional driver, the permit holder, the operator and the advertiser, mapped before any architecture was fixed.
  • Architecture sized for multi-tenancy — Built from the start to carry multiple operators and locations, so growth is a deployment rather than a rebuild.
  • A booking engine that flexes — One engine covering both the one-off transaction and the recurring permit, instead of two systems reconciling against each other.
  • The advertiser module as its own surface — Self-contained, so advertiser functionality could evolve without touching the booking path.
  • Phased delivery — Shipped iteratively, with the booking core proven before the advertising layer was built on top of it.

Our Solution

  • Smart parking management — Real-time space availability with location-based search across sites, so what the driver sees is what they can actually book.
  • Subscription engine — Monthly, quarterly and annual permits with recurring billing and permit management, running alongside daily booking rather than separately from it.
  • Integrated advertising platform — Self-service advertiser onboarding, campaign creation, ad placement and performance tracking, administered by the advertiser rather than the operator.
  • Unified payments — One payment gateway integration covering booking transactions, subscription billing and advertiser payments.
  • Analytics for all three audiences — Revenue and occupancy for operators, history and spending for drivers, impressions and engagement for advertisers, from one reporting layer.

What was delivered

  • One product, two revenue models — Daily booking and subscription permits in a single experience that encourages drivers to move from the first to the second.
  • A revenue stream beyond parking fees — An advertising marketplace that monetises the audience the car parks already have, with self-service onboarding keeping operational overhead down.
  • Room to grow without rebuilding — A multi-tenant SaaS architecture that takes on new locations and user volume without re-architecture.

Client Overview

Park Pay is a US-based provider of digital solutions for urban parking management. The business needed one product to carry two very different jobs: letting drivers book a space for a day or hold a permit for a year, and letting advertisers run campaigns against that audience without operator involvement. Doing either well is ordinary product work. Doing both inside one platform, for multiple operators and locations at once, is where the engineering sits.

  • Industry SaaS & Platforms
  • Technology Stack React, Next.js, Python, Payment Gateway Integration, Real-Time Mapping
  • Services Used SaaS product development, Custom software development, API & integration development
FAQ

Questions about this engagement

How does the subscription side differ from ordinary booking?

Daily booking is a one-off transaction against live availability. Subscriptions are monthly, quarterly or annual permits with recurring billing and permit management behind them. Both run in the same product, so a driver moves between them without changing tools.

What does the advertising platform actually do?

It is a self-service marketplace: advertisers onboard themselves, create campaigns, place ads and track performance without the parking operator administering any of it. That is what makes it a revenue stream rather than an additional support burden.

How does one platform serve several operators and locations?

Through a multi-tenant architecture with real-time availability per site. New locations are added as deployments rather than as re-architecture, which is what keeps the cost of growth flat.

Who gets analytics, and what do they see?

All three audiences, from one unified layer. Operators see revenue and occupancy, drivers see their own booking history and spending, and advertisers see impressions and engagement against their campaigns.