How Orders Are Created
Orders are created from webhooks: Order Management System is a webhook subscriber of the payments platform, and every order starts as a payment.succeeded event received through the subscription created when you enabled the addon. This page explains what happens from there: which purchases become orders, which of them ship, when multiple payments are bundled into one order, and how customer details stay in sync.
From payment to order
When the payment.succeeded event for a payment arrives, each purchased line item is read from the product behind its price:
- A line item whose product is marked Shippable becomes an order item.
- Line items of products that are not shippable are skipped.
- If the payment contains no shippable product, no order is created.
The number of units to ship is the quantity on the payment's line item. A price that represents several units is already expanded there when the payment is created — a 3-pack price purchased twice arrives as six units — so the order item ships exactly what the payment says.
Products are configured in the Payments view under Products; see Creating products and prices.
What the SKU decides
Shippable only decides whether Order Management System sees a purchase at all. Whether the order item it produces is something your warehouse actually ships is decided by whether the product has a SKU:
| Product SKU | The resulting order item |
|---|---|
| Set | Ships, unless the price it was bought at opts out. It carries the product's SKU and a unit count, it is what fulfillments and cancellations are recorded against, and it is included in exports and submissions to your 3PL provider. |
| Not set | Never ships. It is recorded on the order for visibility — a warranty, shipping protection, or a service fee sold alongside goods — and is left out of fulfillment, exports, and submissions. |
An item that never ships appears as Not Shippable on the order, carries no quantities, and is ignored when the order's own status is calculated. An order made up entirely of such items is Not fulfillable — there is nothing to ship. See Order statuses.
Category plays no part in any of this. It is sent as metadata to payment service providers — for example for VAT reporting on the split between digital services and physical goods — and never affects whether an item ships.
Excluding one price from shipping
Several prices often share one product: the goods themselves, and add-ons sold alongside them that must never reach your warehouse — shipping protection, a service fee. Clearing the product's SKU is no help there, because the goods sold under the same product need it. Exclude the add-on on its price instead.
Give the price a fulfillable key with the value false in its metadata, and every item bought at that price is treated exactly as an item whose product has no SKU: recorded as Not Shippable, and left out of fulfillment, exports and submissions to your 3PL provider. An order made up entirely of such items is Not fulfillable.
Set it on the price under Products → Prices, or send it through the API when you create or edit the price:
{
"metadata": {
"fulfillable": "false"
}
}
The value must be exactly false. A price without the key, or with any other value, leaves the product's SKU deciding, so nothing changes for the prices you never mark. Marking a price takes effect for orders created from then on, including orders you import manually later — an order that already exists keeps the details captured when it was created.
An item you expected to ship came out Not Shippable for one of two reasons: the product behind it has no SKU, or the price it was bought at is marked fulfillable: false. Correcting either applies to every order created from then on, but an order that already exists keeps the details captured when it was created — arrange those shipments outside Order Management System.
The SKU is the identifier your warehouse ships against
The SKU is copied onto every shippable order item created from the product, and it is what exports and 3PL submissions identify the item by. An add-on with a product of its own — a warranty, shipping protection — needs no SKU: nothing ships, so there is nothing to identify. Leave it empty for those, and mark the price instead when the add-on shares its product with goods that do ship.
Order bundling
When a customer makes several purchases in quick succession — for example, an upsell right after the initial purchase — you may prefer to ship them together. The Bundling window (minutes) setting under Settings > General in the Orders view controls this.
A new payment is added to an existing order instead of creating a new one when all of the following hold:
| Criterion | Description |
|---|---|
| Customer | The payment belongs to the same customer as the existing order |
| Shipping address | The shipping address is identical |
| Order state | The existing order is still completely unfulfilled |
| Time | The existing order was created within the bundling window |
With the window set to 0, bundling is disabled and every payment creates its own order.
The bundling window is set to 30. A customer buys a subscription box at 10:00 and accepts an upsell at 10:12. Both purchases share the shipping address, so the upsell items are appended to the 10:00 order and ship together.
Bundling and automatic fulfillment
Orders are handed to fulfillment routes only after the bundling window has closed. This guarantees a bundled order is submitted to your logistics provider as one complete shipment, not item by item.
Customer information sync
When a customer's details change in the payments platform — for example, they correct their email or shipping address — Order Management System refreshes the customer name, email, phone, and shipping address on their orders.
Orders that have already shipped, or that have been handed to a logistics provider, keep the address they shipped to.