> ## Documentation Index
> Fetch the complete documentation index at: https://www.twicecommerce.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Listing pricing
> Pricing defines how your listings are sold, rented, or booked - giving you full control over how prices adapt by date and variant.
## Price Tables
A **Price Table** defines *what the price is* and *when it applies*.
You can either:
* **Define price tables directly in the listing**, or
* **Connect the listing to a predefined table** created under **Catalog → Price Tables** for reuse across multiple listings.
Each Price Table can include:
* **Date ranges** — set seasonal, promotional, or time-based pricing. A date range controls **when a table's rows are candidates**, not which table wins.
When several tables apply to the same booking, there is **no per-table priority**. Every active table's rows are pooled together and the engine selects the optimal one — the longest-covering row, with ties broken by the **lowest price**. So a dated table does **not** override the default by date: a cheaper promotional row is selected, while a higher dated price applies only when no cheaper row covers the same duration. See [Price resolution](/docs/concepts/catalog/price-tables#price-resolution) for the full logic.
## Variant pricing
When a listing includes variants, each variant can have its own pricing structure.
By default, variants inherit the **base price** from the listing.
You can override this by linking or defining new Price Tables for specific variant combinations.
> Note:
> If you need one variant to be bookable while others are not (for example, one for sale and another for rent), you’ll need to create a **separate listing**
Examples:
* Variant Size of “XL” costs €5 more
* The booking price of Variant Class of “Premium” has a different rate than “Standard”
## Purchase price
For listings sold outright, you can define:
* **Price** — the active selling price.
* **Compare-at price** — typically the *price as new* or original retail value, shown for reference for the end-customer.
Example: *€129 (compare at €169)*
## Booking price
For rental or booking-based listings, you can choose between **rate-based** or **fixed** pricing models.
### Rate-based pricing
Rate-based pricing defines prices per time increment (e.g. day, week, or month).
Each rate period includes two values:
* **Base rate price** — applied for the first increment of the defined period.
* **Additional rate price** — applied for every following increment of that period.
If multiple rate periods are defined (for example, *day* and *week*), the pricing logic:
1. Finds the **longest rate period** that fits inside the booking duration.
2. Applies the **base rate** for the first period.
3. Then fills the remaining duration with **additional rates**, again prioritizing the longest available periods.
**Example:**
| **Rate period** | **Base** | **Additional** |
| --------------- | -------- | -------------- |
| 1 week | \$100 | \$50 |
| 1 day | \$20 | \$10 |
For a **16-day booking**, the system applies:
2 × 1-week (first $100, second $50) + 2 × 1-day additional rate ($10 + $10) = **\$170**
### Booking duration increment
When using rate-based pricing, you can set a **booking duration increment** on the [Limits](/docs/catalog/listings/limits) tab to restrict selectable durations to whole multiples of a chosen unit — for example, 1-week increments so customers book in full weeks only. The storefront booking widget only offers return dates and times that align to the increment. Durations that are not a whole multiple are rejected.
This setting has no effect on fixed-duration pricing rows, which derive their duration from the row itself.
### Starting at pricing
Both rate-based and fixed pricing support a **Starting at** billing mode. When enabled, duration is counted by **calendar periods touched** instead of elapsed time.
With a day rate of €20:
| Booking | Elapsed (default) | Starting at |
| --------------------- | ---------------------------- | ------------------------------------ |
| Mon 14:00 – Wed 14:00 | 2 days (48 hours) = €40 | 3 started days (Mon, Tue, Wed) = €60 |
| Thu 23:00 – Fri 01:00 | 2 hours (within 1 day) = €20 | 2 started days (Thu, Fri) = €40 |
For **rate-based** pricing, enable Starting at with the **”Starting at pricing”** checkbox in the rate-based booking section header. All rate-based rows on the table share the same setting. When rates span multiple durations (day + week), the engine picks the cheapest calendar-aligned composition.
For **fixed** pricing, each row has its own setting via the duration unit dropdown. Select “Day (Started)” instead of “Day (Elapsed)” to anchor the return date to the calendar rather than the pickup time.
Sub-hour units (seconds, minutes) always use elapsed duration regardless of this setting.
See [Starting at pricing](/docs/concepts/catalog/price-tables#starting-at-pricing) for the full concept, including calendar alignment rules and week-start-day behavior.
### Fixed pricing
Fixed pricing sets a single price for a defined booking duration (e.g. “€100 for 3 days”).
This model works best for package-style bookings, like “Weekend bundle” or “7-day rental.”
## Booking deposit
The Pricing tab also holds the listing's **booking deposit** (`bookingDeposit`) — a single fixed amount, entered in your store currency, requested as a **refundable security hold** when the listing is booked.
* **One amount per listing.** There is no percentage-based deposit and no separate prepayment deposit — the field is a fixed amount. Leave it empty (or 0) for no deposit.
* **Refundable hold, not a charge.** When the customer pays by card, the deposit is reserved on the card as an authorization. It is released after the items are returned in good condition, or captured (partially or fully) to cover damage or late returns.
* The deposit sits alongside the rental payment as its own Payment object on the order.
See [Security Deposits](/docs/concepts/orders/deposits) for the full hold lifecycle — reservation schedule, capture, release, and expiry.
## Advanced price controls
Under **Advanced options**, you can control *when* specific price rows are available or applied.
With **rate-based pricing**:
* Define weekday-specific rates (e.g. weekends cost more than weekdays).
With **fixed pricing**:
* Restrict when a pricing package can be purchased.
For example, you might create a “**Weekender**” package — a 3-day duration (Fri–Sun) that’s **only purchasable on Fridays**.
**Advanced Rate-based Pricing Setting: Fallback price**
Rate-based Price Tables support a **fallback price**, used when no rate is defined for a time period.
If multiple fallback prices apply, the **cheapest** one is used.
## Subscription pricing
For listings with recurring billing, subscription pricing defines plans that charge customers on a regular cycle.
Each subscription plan on a Price Table includes:
* **Label** — customer-facing name (e.g. "Monthly", "Annual")
* **Price** — per-cycle amount
* **Payment cycle** — billing frequency (e.g. every 1 month, every 3 months)
* **Commitment** — minimum number of billing cycles the customer commits to (up to 24)
* **Renewal** — auto-renew after commitment (continues billing until cancelled) or no renewal (ends after commitment)
* **Cancellation lead time** — how far in advance a cancellation request must be made
Optional settings:
* **Initial charge type** — charge at order creation (default) or defer to the subscription start date
* **Collection method** — charge automatically via the stored card (default) or send an invoice for manual payment
* **Renewal price** — a different per-cycle price after the commitment period ends (auto-renew only)
If the listing has variants, each variant value can apply a **rate multiplier** to the base subscription price — the same mechanism used for booking and sale variant pricing.
On the storefront, customers pick a plan (if multiple exist), select a start date, and see a billing schedule preview before adding to cart. TWICE stores the card at checkout and handles all future billing automatically.
See [Subscriptions](/docs/concepts/catalog/subscriptions) for the full billing lifecycle, retry logic, and admin management.
## Summary
Price Tables let you define reusable pricing logic that adapts by date or variant — whether defined directly in the listing or shared across multiple listings from the catalog.
They support flexible rate-based models, weekday rules, fallback logic, subscription plans, and variant-level overrides — keeping your pricing **structured, predictable, and scalable**.