> ## 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.

# How to price a listing

> Set what a listing costs — purchase options, fixed versus rate-based pricing, the Elapsed and Started distinction that decides how a partial period is charged, and which table applies when.

<Card title="Open in TWICE Admin" icon="external-link" href="https://admin.twicecommerce.com/catalog/listings" horizontal>
  catalog/listings
</Card>

Pricing a rental is not pricing a product. A product has a price; a rental has a price *and* a rule for what happens when the customer keeps it for two and a half days.

That rule is the part of this tab worth understanding properly. Everything else — a number in a field — takes a minute.

## Prerequisites

<Warning>
  **Required permission:** listing manage rights. All four system roles hold them.
</Warning>

<Info>
  **Decide before you start how you charge for a partial period.** A customer picks up at 14:00 on Monday and returns at 09:00 on Wednesday. Is that two days or three? Both answers are legitimate, both are configurable, and the choice is made in a dropdown that is easy to skim past. It is the difference between a ski hire and a plant hire, and getting it wrong is a revenue question, not a cosmetic one.
</Info>

## The Walkthrough

<Steps>
  <Step title="Choose the purchase options">
    On the **Pricing** tab, **Purchase options** decides how customers can acquire this listing — *Customers can acquire this listing as* **Bookings**, **Sales**, or both.

    One listing can be both. That is how the same thing is rented and sold without duplicating it, and it is worth turning on deliberately rather than discovering later that a listing was rental-only all along.
  </Step>

  <Step title="Attach a price table">
    Prices live in **Price tables**, not directly on the listing. A table can be attached to one listing or shared across many, which is what makes a rate card a rate card.

    The table marked **(Default)** is the one that applies when no other does. Add tables with **Add table** or **Add new price table**.

    <Note>**Only a price table with no validity period can be a listing's default.** A dated table is a seasonal or promotional overlay by definition, so TWICE will not let it be the fallback. Build the default first, undated, then add dated tables around it.</Note>
  </Step>

  <Step title="Pick the pricing shape">
    Inside a table, prices come in two shapes and they answer different questions:

    * **Fixed price per duration** — fixed prices for set periods, e.g. 1 day or 3 hours. The customer picks a duration and pays that price.
    * **Rate based** — rates charged for the booked duration, where a day runs 24 hours from pickup.

    Fixed durations suit a business with named products — a day pass, a weekend rate. Rate-based suits one that bills whatever time was actually used.
  </Step>

  <Step title="Choose Elapsed or Started — the decision that matters">
    On a fixed-duration price, the unit dropdown offers each unit twice, and the suffix is the whole point:

    |                   | What it means                             | Monday 14:00 pickup, "2 days"         |
    | ----------------- | ----------------------------------------- | ------------------------------------- |
    | **Day (Elapsed)** | Pickup plus the exact duration            | Due back Wednesday 14:00              |
    | **Day (Started)** | The return is derived from the pickup day | Due back at the end of the second day |

    **Elapsed** is a rolling clock: the customer gets the full period they paid for, whenever they collect. **Started** is calendar-based: a day is a day, and collecting at 16:00 does not buy you until 16:00 two days later.

    Neither is more correct. Elapsed is fairer to a late-afternoon collection; Started is simpler to run a counter on and matches how most day-hire businesses already think. Pick the one that matches how your staff already answer the question, because they will answer it that way regardless of the setting.

    <Note>**Sub-hour units have no variant.** Prices with sub-hour units are always charged by duration, so the choice does not arise below an hour.</Note>
  </Step>

  <Step title="Add a deposit if you take one">
    **Booking deposit** sets a **Deposit** held against the booking. It is part of the table rather than a separate setting, so a listing on a different table can carry a different deposit.
  </Step>

  <Step title="Check which listings you just changed">
    Before saving a shared table, open its **Linked listings** — *listings that are using this price table*.

    A shared rate card is a shared consequence. If that list is longer than you expected, the edit reaches further than you meant, and **Unlink** is how you take a listing off it.
  </Step>
</Steps>

## How do I know it worked?

* **The listing shows a price on the storefront** for the dates a customer would pick.
* **A two-and-a-half-day booking is charged the way you intended** — this is the one to test with real dates, because it is where Elapsed and Started diverge.
* **The deposit appears at checkout** if you set one.
* **Linked listings lists exactly the listings you meant to price.**

## Troubleshooting / Common Pitfalls

<AccordionGroup>
  <Accordion title="The listing shows no price">
    **In order of likelihood:** no price table is attached; the attached table has no rows for the purchase option the customer chose; or the only table has a validity period that does not cover the requested dates and there is no default behind it.

    **What to do:** make sure an undated default table exists and is attached. Dated tables are overlays — they are not a substitute for having a default.
  </Accordion>

  <Accordion title="Customers are being charged for more or less time than we expect">
    **This is Elapsed versus Started.** A fixed-duration price billed on the wrong basis is off by up to a full unit on every booking that does not start at the beginning of a period.

    **What to do:** open the price row and look at the unit's suffix. Take a real booking that came out wrong, work it through both readings, and set the one that produces the number you meant.
  </Accordion>

  <Accordion title="I cannot set the seasonal table as the default">
    **Working as designed.** Only a price table without a validity period can be a default. A dated table is by definition an overlay for a window.

    **What to do:** keep an undated default as the baseline and let dated tables layer over it.
  </Accordion>

  <Accordion title="Editing one listing's price changed several listings">
    **Cause:** the table is shared. That is the point of a price table, and it is a genuine trap when you did not realise the table was in use elsewhere.

    **What to do:** check **Linked listings** before editing. If the listing needs to move independently, give it its own table rather than editing a shared one.
  </Accordion>

  <Accordion title="We need different prices per location or per sales channel">
    **Not available.** A price table is scoped by validity period. There is no per-location or per-channel price, so a listing costs the same everywhere it is sold.

    **What to do:** if two locations must charge differently, they need separate listings with separate tables — which also means separate stock rules and separate publishing. Worth being sure the difference is worth that before committing to it.
  </Accordion>

  <Accordion title="The price is right for a booking and wrong for a sale">
    **Cause:** purchase options and prices are set per table, so a table serving both bookings and sales needs rows for both.

    **What to do:** check the table has prices defined for each purchase option the listing offers. A listing offering Sales with no sale price is sellable in principle and priceless in practice.
  </Accordion>
</AccordionGroup>

## Next Steps

<CardGroup cols={2}>
  <Card title="Price tables" icon="table-cells" href="/docs/concepts/catalog/price-tables">
    The model behind tables, rows, and resolution.
  </Card>

  <Card title="Listing Pricing tab" icon="tag" href="/docs/catalog/listings/pricing">
    The tab reference, field by field.
  </Card>

  <Card title="Deposits" icon="shield-halved" href="/docs/concepts/orders/deposits">
    What a booking deposit does on the order.
  </Card>

  <Card title="Create and publish a listing" icon="plus" href="/docs/catalog/listings/overview">
    The tabs either side of this one.
  </Card>
</CardGroup>