Feature Guide · Rates
One engine.
Many rate cards.
A rate change should be a configuration decision, not a code release. Here is how Valletto scopes a rate to a stand, evaluates it once, and carries the same answer from the curb to the receipt.
What it is
A stand-scoped rate card evaluated by one canonical pricing engine.
A rate card combines ordered base rules with the discounts, validations, surcharges, fees, and taxes that may change its result. The inputs are facts about the visit - time, duration, tags, and stand - rather than a cashier choosing a number.
That shared evaluation is the important part: mobile, web, guest checkout, and backend workflows do not get to develop their own version of the math.
Who uses it
The rate card is where an operator's commercial agreement becomes an operational rule.
Owner
Sets the commercial shape
Chooses the stand, base plan, special rules, discounts, surcharges, fees, and taxes. Valletto does not set the prices.
Property manager
Reviews what guests and partners owe
Uses the preview and the written agreement to confirm the negotiated rate, validation, and split before launch.
The setup order
Scope first, base math second, modifiers last - then preview the whole receipt.
1 · Scope
Choose the stand
Rates are selected in the context of a location and one stand. Two stands at the same property can carry different rate cards.
2 · Base
Choose flat, duration-bucket, or incremental math
Rules can be gated by duration, arrival or departure time, weekday, calendar date, tags, or crossing a configured day boundary.
3 · Modifiers
Add discounts, validations, surcharges, fees, and tax
Each modifier has an explicit kind and action; the preview shows how matching entries alter the running total.
The daily loop
Every surface supplies the same session facts to the canonical valletto-pricing engine.
Evaluate
The first eligible rule matches each pricing period
Enabled rules are ordered; the first eligible base rule for each pricing period produces that period's starting amount, then eligible modifiers are applied.
Explain
The guest sees a breakdown, not a mystery total
The result carries receipt groups and modifier totals so checkout can name parking, validation, fees, tax, and tip separately.
Change
A later edit does not rewrite history
The payment history keeps the charged totals, modifier breakdown, receipt context, and pricing signature; it does not claim to freeze the whole rate plan or every pricing input.
The edge cases
The hard cases are explicit rules, not cashier judgment.
Validation
A validation can reduce, replace, cap, or split
A split records the guest amount and partner amount separately. Discounts cannot drive the guest total below zero.
Midnight
A day can mean session, calendar day, or rolling 24 hours
Calendar metering uses the rate plan's timezone and can move the boundary away from midnight.
No match
The system does not invent a rate
A missing or ineligible plan is treated as unavailable rather than silently substituting a different stand's price.
What it deliberately does not do
A pricing engine enforces configured terms; it does not negotiate them.
No prescribed prices
Valletto does not decide what valet should cost
Every amount in this guide and its visual is illustrative. The operator and property own the commercial decision.
No second calculator
The browser is not another pricing authority
The canonical rate math lives in valletto-pricing. Apps present and preview its result instead of maintaining competing formulas.
What it connects to
The rate card is upstream of every place money is explained.
Checkout
Guest payment and receipt
The checkout surface reads the evaluated amount and modifier breakdown before payment.
Partners
Validations and billing
A partner-issued validation becomes a pricing modifier and, where the agreement requires it, a partner ledger entry.
Records
Transactions and financial reporting
The resulting transaction remains linked to its session so the total can be traced back to the rate and modifiers that produced it.
→Product-faithful staged view based on the current Rates screen and pricing schema. All names and amounts are synthetic.
The practical result
Change the agreement once; explain the same price everywhere.
The rate card is consequential because every later payment, validation, receipt, and transaction depends on it.
Next: see how open sessions and dispatch turn those configured rules into a live operation.
