julian
58d8f06ba0
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.
2.6 KiB
type, tags, sources, updated, status
| type | tags | sources | updated | status | |||||
|---|---|---|---|---|---|---|---|---|---|
| concept |
|
2026-06-15 | 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
paymentevent 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.