---
title: "Understanding Products & Pricing"
description: "A concept overview of Orbit Products: a purchasable logistics service whose price is calculated per transport, why a product can show no price or be marked unavailable, and the sales/purchasing split."
url: "https://support.pr-7.orbit.do/en/advanced-features/understanding-products-pricing"
locale: "en"
apps: ["mission", "hub"]
lastReviewed: "2026-10-17"
---

# Understanding Products & Pricing

A concept overview of Orbit Products: a purchasable logistics service whose price is calculated per transport, why a product can show no price or be marked unavailable, and the sales/purchasing split.

> **Note:** A `Product` is a purchasable logistics service you offer to shippers. Its
> price isn't a fixed number in a catalogue — Orbit works it out for each
> transport when the service is chosen.

**Who this is for:** operators who want to understand what a `Product` represents and how a price appears — or doesn't — when booking. It is a concept overview, not a build guide; if you configure products, the build guides are linked at the end.

## What a product is

A `Product` is a sellable logistics service — a same-day courier, an overnight pallet service, a temperature-controlled run. Rather than storing one fixed price, a product describes *how* to price a service and *whether* it can be offered at all. When someone chooses the product for a specific transport, Orbit runs that description against the details of the job — the route, the load, the timing — and produces the price and terms for that particular move.

This is why the same product can return one figure for a Paris to Berlin run and another for a London to Manchester one, and why a price only exists once there is a real transport to price it against.

## How a product is assembled

A product is built from a set of modular building blocks, sometimes called bricks. You don't need to work with them to book, but knowing the four kinds explains what a product decides for each transport:

* **Context** — gathers the shared facts the other blocks need, such as the route or the vehicle type.
* **Feasibility** — decides whether the service can be offered for this job at all.
* **Pricing** — produces the priced lines that add up to the quote.
* **Scheduling** — offers the bookable time slots or windows for the service.

Because the price is assembled this way, it reflects the actual job in front of you rather than a generic list price.

## Sales, purchasing, or both

A product prices one or both sides of a deal:

* **Sales** — what the customer pays. This lands on the `Order`.
* **Purchasing** — what it costs you to have a carrier carry it out. This lands on the `Tour`.
* **Sales and purchasing** — both sides, from a single product.

The two are different numbers for different audiences: a customer sees the sales price on their `Order`; a carrier only ever sees the purchasing-side rate on the `Tour`.

## When no price is shown — this is normal

A product doesn't always come back with a bookable price, and that is valid, expected data rather than a fault to fix. Evaluating a product against a transport has three possible outcomes:

* **A price** — the service is available and can be booked at the price shown.
* **Price on request** — the service is available, but a price can't be worked out automatically for this job. Instead of a figure, the customer is offered the chance to request a quote, which reaches an operator to price by hand.
* **Unavailable** — the service can't be offered for this particular transport, usually with a short message explaining why, such as a load that is too heavy for the service.

So a product card that shows no price, or is marked unavailable, is telling you something true about that specific job — it is not a broken price. Operators enable the request path with the **Allow Requests** option on a product, and the wording of the request prompt shown to the customer is configurable.

## Where you see products

Products appear as selectable cards while you build a transport in the **TransportComposer** in Orbit MissionControl, and to shippers booking in Orbit Hub. Each card shows a price, a request prompt, or an unavailable note, depending on the outcome above.

In Orbit MissionControl, changing transport details refreshes the product offers, so the selected product is evaluated against the updated schedule. A selected product available on request can still be submitted as a request. If a selected, automatically priced product becomes unavailable, Mission disables the booking action until the offer changes or you choose another date or product.

## Price source and manual changes

In Orbit MissionControl, dimmed text next to the amount on a `Tour` shows where the price comes from. On an `Order`, the source follows the **Price** heading when line items are present. Hover over or focus the information icon to read what the source means. Select the pencil icon to edit the price.

* **from product**: the selected `Product`'s current pricing produced the price.
* **from callout**: a carrier offered the price in a callout.
* **from carrier**: the carrier provided the price through its integration.
* **set manually**: someone entered or changed the price by hand.

Editing line items by hand marks the price as manual. A later calculation does not replace those lines. Choosing a scheduling option or changing a `Product`'s name or description does not by itself make its price manual. A fresh `Product` calculation can update a product-sourced price and identifies it as **from product**.

When a Carrier is assigned or changed, Orbit recalculates a product-sourced purchasing price with the matching purchasing Products for that Carrier and the Tour. If several Products can price the Tour, the lowest price is chosen. You can select another eligible purchasing Product when you want a different one. A price set by hand, from a callout, or by the Carrier is kept as it is.

## Learn more

This article is a concept overview. For building and running products, see:

* [Products](https://support.pr-7.orbit.do/en/advanced-features/products) — the full guide to composing a product.
* [Calculator Widget](https://support.pr-7.orbit.do/en/advanced-features/calculator-widget) — an embeddable price calculator.
* [Product Messages](https://support.pr-7.orbit.do/en/advanced-features/product-messages) — the notes and alerts a product can show while pricing.
* [Product Testing](https://support.pr-7.orbit.do/en/advanced-features/product-testing) — checking a product's output before it goes live.
* [Product Metrics](https://support.pr-7.orbit.do/en/advanced-features/product-metrics) — the figures behind a price, such as distance and travel time.

## FAQ

**Q: Why does a product show no price?**

Because the price for that specific job can't be worked out automatically,
or the service isn't available for it. If requests are enabled, the customer
can ask for a quote instead; otherwise the card shows the service as
unavailable, usually with a reason. Both are valid outcomes, not errors.

**Q: Why is the same product a different price on two bookings?**

A product prices each transport on its own details — route, load, and timing
— so the figure changes from job to job. There is no single stored price to
look up.

**Q: Does every company have products?**

No. Products are Orbit's pricing layer, and a company that prices its
services elsewhere may have none. In that case a price is set by hand rather
than calculated.

**Q: Why doesn't the carrier see the price the customer paid?**

The customer's price (sales) and the carrier's rate (purchasing) are
separate figures. A carrier only sees the purchasing-side rate on the
`Tour`, never the sales price on the `Order`.
