Shipping and Fulfillment

Shipping turns a paid product order into an operational workflow: confirm the order, choose a package, buy or record a label, track delivery, handle exceptions, and close the customer loop. Use Shipping with Products, Orders, Payments, and customer account pages.

Operating Model

Console Shipping Configuration

Console surfaces: Shipping, Shipping > Settings, Settings > Shipping.

Configure these before a workspace sells shippable products:

• Ship-from origin. Use the business address when it is the real fulfillment origin, or enter a dedicated warehouse, studio, or pickup location.
• Default units. Set the weight and dimension units operators expect to use when creating shipments.
• Enabled carriers. Only enable carriers the business is ready to use for rate shopping and label purchases.
• Markup and thresholds. Configure handling markup and free-shipping thresholds so checkout totals match policy.
• Package presets. Save common parcel dimensions, default weight, package type, and the default preset used to pre-fill new labels.
• Zones and rates. Confirm which destinations are supported and whether checkout should use calculated rates, flat rates, pickup, or no shipping.

If Shipping settings are incomplete, checkout may still create orders, but label buying and rate shopping can fail later.

Product Shipping Settings

Console surface: Products.

For each product, confirm:

• Product type and publish state.
• Whether the product requires shipping.
• Weight and weight unit.
• Length, width, height, and dimension unit.
• Package type.
• Flat shipping fee when the business wants a product-specific charge.
• Free shipping eligibility.
• Inventory behavior and whether oversell is allowed.

Physical products should carry parcel details whenever possible. Package presets help operators buy labels quickly, but product-level weight and dimensions are the fallback that keeps a new tenant from blocking on missing parcel data.

Rates And Labels

Console surfaces: Orders, Shipping.

Rate shopping needs:

• A valid ship-from address.
• A valid ship-to address.
• Parcel weight and dimensions.
• Enabled carrier configuration.
• Product or package preset data.

The label buy surface lets an owner or admin choose a rate, label file format, insurance when available, and customer notification behavior. Buying a label is a live carrier charge. Reprint uses the stored label URL and should not create a new charge. Void requests a carrier cancel or refund and returns the order to the right fulfillment state when the carrier accepts it.

Label formats can include standard PDF, label-sized PDF, PNG, and thermal formats depending on provider support.

Fulfillment Queue

Console surface: Shipping.

The Shipping landing page is the fulfillment work queue. It focuses on paid orders with a shipping destination that are not fully fulfilled.

Operators can filter by:

• Ready to ship.
• All orders.
• Unfulfilled.
• Partially fulfilled.
• Fulfilled.
• Delivered.
• Returned.
• Order status such as processing, shipped, delivered, or cancelled.

Use the queue for daily picking, packing, label buying, tracking follow-up, and exception review.

Batches

Console surfaces: Shipping, Shipping > Batches.

Batch buy is for operators who need to buy labels for multiple ready-to-ship orders at once. The review step resolves each selected order to a parcel and rate before purchase.

Before buying a batch:

• Review every order and address.
• Confirm the selected label format.
• Confirm whether customers should be notified.
• Remove unresolved rows or rows with unexpected rates.
• Remember that each row can create a live carrier charge.

The batch list is the audit surface after purchase. Use batch detail to see which labels succeeded, failed, or need manual follow-up.

Returns

Console surfaces: Shipping > Returns, order detail.

Returns use two related records:

• A return authorization or RMA that records why the customer is sending something back.
• A return label when the operator chooses to buy one for a specific outbound shipment.

Creating a return authorization does not automatically refund the payment or mark the outbound order returned. Creating a return label is a live carrier charge. Carrier return tracking can eventually move the shipment and fulfillment state to returned.

Use the order notes and timeline to record customer communication, restocking decisions, and refund ownership.

Tracking

Tracking is separate from fulfillment status. Carrier webhooks and polling can move a shipment through pre-transit, in transit, out for delivery, delivered, failure, returned, or unknown.

Operators should check:

• Tracking number and carrier.
• Tracking URL.
• Estimated delivery date.
• Event timeline.
• Failed or exception events.
• Whether the customer-facing tracking page loads.

Fulfillment status is the operator promise; tracking status is the carrier signal. They should usually agree, but during exceptions the order detail page is the source of truth for the next operator action.

Customer Tracking Pages

Customer surfaces:

• /orders.
• /orders/{orderId}.
• /{site}/track/{tracking}.

Customers should be able to see order history, fulfillment progress, shipment details, tracking links, and return tracking when enabled. Public tracking pages are workspace-scoped by tracking number, so an unknown or wrong-workspace tracking number should behave like a not-found page.

Test tracking with a known order and a deliberately wrong tracking value. The known order should show only the customer’s shipment context; the wrong value should not reveal another workspace’s order, customer, address, carrier event, or fulfillment state.

Order Fulfillment

Console surfaces: Orders, Shipping.

Use this flow for a normal shipped order:

1. Open the paid order.
2. Confirm payment status, customer, items, inventory, and shipping address.
3. Confirm parcel details from the product or preset.
4. Rate shop and choose the intended service.
5. Buy the label or add external tracking.
6. Pack the order and attach the label.
7. Confirm the order moved to fulfilled or partially fulfilled.
8. Verify tracking appears in the order and customer view.
9. Record any operator notes.

For multi-item orders, keep fulfillment status honest. Use partially fulfilled when only some items have shipped.

Daily Operations

Run this each shipping day:

Refunds And Returns

Refunds are a payment action. Returns are a logistics action. They often happen together, but they should be handled deliberately.

Before refunding:

• Confirm the order and customer.
• Confirm whether the item has shipped, delivered, or returned.
• Confirm policy eligibility and any restocking or return-shipping decision.
• Confirm whether inventory should be restocked.
• Confirm whether the refund happens through the connected payment account or out of band.
• Add an order note with the reason and owner.

Before buying a return label:

• Confirm the outbound shipment.
• Confirm the return address.
• Confirm the item should come back.
• Confirm who pays return shipping.
• Confirm the customer should receive the return label.

Launch Readiness

Before real traffic:

• Shipping origin and business address are correct.
• Products that require shipping have weight and dimensions.
• Checkout shows the expected shipping options.
• Rates, tax, discounts, and totals match policy.
• A test order can be fulfilled from order detail.
• The Shipping queue shows the order in the expected state.
• Tracking appears on the customer order page.
• Public tracking page resolves for the test tracking number.
• Refund and return owners know the policy.
• Operators know that label and return-label purchases can create live carrier charges.

Troubleshooting