Designing an order-request flow for variable-weight products before payment

What was happening

A commerce migration had fixed-weight products that could map cleanly to variants, but also products where customers could request arbitrary grams or kilos. The final prepared weight might differ from the requested amount, so immediate payment at the initial estimate could create refunds, manual corrections, and customer confusion.

Why the obvious solution was not enough

The storefront still needed a familiar ordering experience, but payment had to happen after the merchant reviewed availability and final weight. The design also needed to carry customer details, shipping information, line-item notes, and order comments into the review step.

How the solution works

1. Keep standard fixed weights as normal variants whenever the catalog can express them accurately.
2. Use a bounded custom quantity UI only for products that genuinely require arbitrary weight input.
3. Validate requested weight and pricing rules in the application layer rather than trusting a browser-calculated total.
4. Create a Draft Order as the merchant's reviewable order request instead of immediately creating a paid order.
5. Attach customer, shipping, line-item, and order-note context so staff do not need to reconstruct the request from a separate message.
6. Allow the merchant to adjust unavailable items or the final prepared weight inside the Draft Order.
7. After review, send the platform invoice or checkout link so the customer pays the confirmed amount through the configured payment method.
8. Use a dedicated 'Order Request Received' confirmation before payment so the customer understands that the request is waiting for review.

What should be verified before shipping

• Test fixed-weight variants and arbitrary-weight products separately.
• Reject zero, negative, malformed, and unreasonable custom weight values before creating the request.
• Confirm customer, address, notes, and requested weight are readable in the merchant review view.
• Edit final weight and availability before invoicing and verify the payment request reflects the updated amount.
• Confirm successful payment converts the reviewed request into the expected paid order and fulfillment flow.
• Test unavailable items so the customer is not asked to pay for merchandise the merchant removed during review.

What changed

The architecture separates customer intent from final billable quantity, giving the merchant a controlled review step before payment. This case is documented as a feasibility and system-design pattern rather than claiming a production launch that was not part of the study.

Reusable lesson

When the final quantity is not known at add-to-cart time, forcing immediate payment creates downstream correction work. Model the uncertainty explicitly with a reviewable order state.