Orders are the central commerce resource in Flint. Every sale flows through an order: it holds line items, discounts, charges, tax, a requested tip, and the full pricing and settlement state for the transaction. Other resources attach to orders rather than replacing them: payments, refunds, invoices, checkout sessions, and subscriptions all read from and write back to an order.
Line items come from your catalog (a variant_id or bundle_id, with price and display resolved automatically) or are ad hoc (you provide the name and unit price). An order stays open while you build it, then settles through payment: pay it in full, or close it explicitly when no balance remains. pricing_amounts reflects what the order should collect; settlement_amounts reflects what has actually been paid, refunded, and is still outstanding.
If any line item resolves to a variant with inventory_tracking: "tracked", the order needs an inventory_routing_source before it can hold stock: either a fixed Location or an allocation policy. Flint holds the routed quantity when payment begins, commits it when payment succeeds, and consumes it when fulfillment hands the goods off. inventory_reservation_id points at the claim, and inventory_demand_revision advances whenever the tracked demand or its routing changes. If payment succeeds but the stock cannot be committed, inventory_exception_status reads paid_inventory_failed and the order waits for POST /v1/orders/{order_id}/inventory-exception/resolve, unless your settings tell Flint to refund automatically instead. See the Inventory guide for the whole path.
For the model behind this design, see the Orders-first guide. To collect payment against an order, use checkout sessions for hosted payment, invoices for receivables, or payments for direct integration.