Files
parking_solution/wiki/concepts/validation-discounts.md
T
julian 58d8f06ba0 docs(wiki): tariff research — legacy ParkSQL2017 schema, time-tiers & validation/sponsorship design
Ingest the predecessor SQL Server schema (raw + source summary) and file design
pages for time-of-day/seasonal tariff tiers and merchant validation/postpaid
sponsorship. Cross-link tariff.md and validation-discounts.md. No code.
2026-06-18 10:59:21 +02:00

56 lines
2.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
type: concept
tags: [parking, domain, business, pricing, revenue]
sources: []
updated: 2026-06-15
status: open
---
# Validation & Discounts
A merchant (shop, hotel, clinic) **validates** a customer's parking so they pay less or nothing —
a common revenue/retention feature that modifies what a [[parking-session]] owes.
## Model: a discount is a signed event, applied at fee time
A validation is **not** an edit to the session or a mutable "discount applied" flag — same reason
as everything else ([[threat-model]]: an operator/merchant could otherwise fake free parking). It's
recorded so the fee computation and the audit both see it:
- A **discount/validation event** references the session: `{ sessionRef, kind, value, issuedBy,
ts }` — e.g. *2 hours free*, *€5 off*, *flat €1*, *100% off*. Appended + signed
([[append-only-event-chain]]).
- The [[tariff]] fee function applies eligible validations when computing what's due at the pay
station: `due = max(0, tariff_fee − discounts)` (or time-based: subtract validated minutes before
pricing). Pure + reproducible, like the base fee.
- The `payment` event then records gross fee, discount total, and net paid — so revenue reporting
([[reporting-analytics]]) can show **discount leakage** (how much was given away, by whom).
## How a validation is presented
- **Merchant terminal / portal** stamps the customer's ticket id (or plate) — issues the validation
event for that session.
- Or a **validation code** the customer enters at the pay station.
- Either way it ties to the session by **ticket id or plate** ([[parking-session]] identity).
## Anti-abuse
Because each validation is signed and attributed (`issuedBy`), over-validation by a colluding
merchant is **visible to [[reconciliation]]** (a merchant validating far more than their footfall is
an anomaly), rather than invisible free parking.
## Postpaid sponsors
When the validating party is a **business with a postpaid agreement** (its customers park free, it's
billed monthly) — not just a one-off discount — the **sponsor account + settlement** layer is in
[[validation-sponsorship]]. That's the distinction between a discount (this page) and a *sponsored*
session that accrues a receivable.
## Open
- Validation types the site needs (free hours / fixed amount / percentage / flat rate) — superset in
[[validation-sponsorship]] (`comp`/`percent`/`fixed`/`time-credit`/`rate-switch`).
- Whether merchants self-serve (portal/terminal) or the operator applies it.
- Caps (max discount, max per merchant/day).
- Prepaid coupon pool vs. postpaid accrual — see [[validation-sponsorship]].