> ## 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.
# Order Types
> Different transaction modes in TWICE including rental, sale, subscription, and buyback orders.
## Definition
An Order's type is determined by the **purchase type** of its line items. Every Order Item carries a `purchaseType` field, and the same Order can mix line items of different types — for example, a rental bike with an accessory sold outright. The purchase type controls how pricing is calculated, what fulfillment rules apply, and which lifecycle transitions are valid.
## Where do I use it?
* Configuring [Auto-Fulfillment](/docs/concepts/orders/auto-fulfillment) rules per purchase type
* Setting up [Listings](/docs/concepts/catalog/listings) so they can be booked, purchased, or both
* Filtering reports by purchase type
* Building Workflows that branch on order type
* API integrations that need to drive different behaviour for rentals vs sales
## Key Properties
The supported purchase types are defined in `OrderItem.purchaseType`:
| Purchase Type | Internal value | What it means |
| :------------------- | :------------- | :------------------------------------------------- |
| **Rental / Booking** | `booking` | Temporary use with a return expected at `endDate`. |
| **Sale** | `sale` | One-time transfer of ownership. No return. |
| **Subscription** | `subscription` | Recurring billing for ongoing access. |
| **Buyback** | `buyback` | You acquire an item from the customer. |
Every line item has:
* `startDate` and `endDate` — define the rental period for rentals; optional for sales
* `duration` and `durationLabel` — the rental period length and its display label
* `pricing` — calculated from the [Price Table](/docs/concepts/catalog/price-tables) that matches the line item's `purchaseType` and dates
* `capturedTotal` and `refundedTotal` — per-line payment aggregation
* `depositAuthorisedTotal`, `depositCapturedTotal`, `depositRefundedTotal`, `depositCancelledTotal` — per-line deposit totals, common for rentals
* `fulfillmentState` — the line's own fulfillment state; the Stock Items committed to the line each carry their own
## Relationships
* Each [Order Item](/docs/concepts/orders/order-lifecycle) references a [Listing](/docs/concepts/catalog/listings) and inherits its eligible purchase types.
* The matched [Price Table](/docs/concepts/catalog/price-tables) determines how the line item is priced (per-day, flat, depreciation-aware for buybacks, etc.).
* [Service Locations](/docs/concepts/admin/locations) define separate fulfillment and return rules per purchase type — see [Auto-Fulfillment](/docs/concepts/orders/auto-fulfillment).
* [Stock Items](/docs/concepts/inventory/stock-item-state) committed to a rental line item move out at pickup and return at the end of the rental period; sales lines do not return.
## Lifecycle
### Rental orders
The default circular-commerce use case. The customer takes possession of items for a defined period, then returns them.
* **Pricing**: per-period rates from the Listing's rental Price Table (per-hour, per-day, per-week, custom).
* **Fulfillment**: pickup (in-store, shipped, or local delivery) at `startDate`, return at `endDate`.
* **Deposits**: commonly required. Held as a separate authorisation or capture and released or refunded on return.
* **Lifecycle**: Open → In progress → Closed.
* **Cancellation**: governed by the order's [Cancellation Policy](/docs/concepts/orders/order-lifecycle).
* **Edits**: rental dates can usually be extended while In progress.
### Sale orders
A permanent transfer of ownership — typical for accessories, used-product resale, or new product sales alongside a rental catalog.
* **Pricing**: flat sale price from the Listing's sale Price Table.
* **Fulfillment**: single delivery event. No return expected.
* **Deposits**: not applicable.
* **Lifecycle**: Open → In progress (handed over / shipped) → Closed. There is no rental hand-out/return step.
* **Cancellation**: must follow a refund flow once fulfilled — see [Payments](/docs/concepts/orders/payments).
* **Edits**: items can be added or removed while Open, not after fulfillment.
### Subscription orders
Recurring billing for ongoing access to a product or service — used for memberships, leasing-style rentals, and gear-as-a-service.
* **Pricing**: per-cycle rate from the Listing's subscription [Price Table](/docs/concepts/catalog/price-tables). Each plan defines a payment cycle (e.g. monthly), commitment length, and optional renewal price.
* **Fulfillment**: typically a single initial delivery, with the subscription period tracked on the order.
* **Billing**: requires a recurring-capable payment provider (Stripe or Adyen card payments).
* **Lifecycle**: stays In progress for the duration of the subscription. Closes when the subscription ends or is cancelled.
* **Cancellation**: ends the subscription and stops future billing. Items may need to be returned depending on the agreement.
* **Customer portal**: customers manage their subscriptions through a self-service [Subscription Portal](/docs/concepts/orders/subscription-portal) — accessible via a secure link in subscription emails.
### Buyback orders
The merchant acquires an item from a customer — a key part of circular commerce. Used when customers trade in or sell back used items.
* **Pricing**: the merchant pays the customer. Often calculated from a depreciation rate or condition-based formula.
* **Fulfillment**: the customer hands over the item; the merchant receives it into inventory as a new [Stock Item](/docs/concepts/inventory/stock-item-state).
* **Payment direction**: reversed — the merchant owes the customer. Payouts are made via the configured payment method.
* **Lifecycle**: Open (offer pending) → In progress (item received) → Closed (payout complete).
* **Where it shows up**: [Service Locations](/docs/concepts/admin/locations) have a dedicated **Buyback** tab in their fulfillment and return rules.
### Mixed orders
A single order can include line items of different purchase types — for example, a one-week ski rental (`booking`) plus a pair of socks (`sale`). Each line item carries its own `purchaseType`, dates, and pricing, and is fulfilled according to that type's rules.
## FAQs
Each Listing has one or more Price Tables. The set of `purchaseType` values across those tables determines what the Listing supports. Adding a sale Price Table to a rental Listing makes it buyable; removing all rental tables makes it sale-only.
Yes — that's the core of circular commerce. A Stock Item moves through rental cycles, and at some point the merchant can convert it into a sale (or a buyback offer to the customer). The Stock Item history records every order it participated in.
Subscriptions are best for ongoing access without a fixed return date. Rentals are best for defined-period bookings with explicit return events. Use whichever matches the customer agreement — the data model supports both, on the same Listing if needed.
`booking`. The internal enum value on Order Items is `booking` — there is no `rental` value. The admin labels the same concept **Booking** or **Rental** depending on context; [Service Location](/docs/concepts/admin/locations) fulfillment rules use **Booking**. Treat the labels as equivalent, but always send `booking` in the API.
Pricing is typically driven by a depreciation rule on the Listing or a manual offer entered by staff. The result is stored on the Order Item like any other purchase type.
## Developer Reference
Order type is set via `purchaseType` on the `orders` endpoints.
Open the endpoint in the API reference.
## Related
Order, Payment, and Fulfillment states.
Hierarchy, deposits, refunds, and payout flows.
Per-type pricing per Listing.
Type-specific fulfillment rules.
Customer self-service for subscriptions.