Supplement Preorders: Map Payment and Fulfillment Timing

By NUMUS editorial team

A supplement preorder creates a gap between the customer's order and the product's arrival. To explain that gap in a processing review, show when the customer commits, when money is collected, when you expect to ship, and what happens if the schedule changes.

This guide covers a one-time preorder. Start with the actual product, supplier timing and customer offer, then draw the sequence. The broader supplement payment processing page can help frame the business conversation; this worksheet focuses on the dates and decisions for a particular release.

Separate the dates before choosing the payment flow

Write down the order date, expected inventory receipt, planned dispatch and estimated customer arrival. A supplier's estimate for reaching your warehouse is not the date you expect the customer to receive the product. Include the time needed to receive, check and pack inventory in your own planning.

Add payment events on a separate line. Is the proposal to collect the whole price when the order is placed, collect a deposit and a later balance, or collect payment later? Those choices need confirmation for the actual account and checkout setup.

Shopify's preorder documentation describes full, partial or no payment at order placement, depending on the purchase option, and says a preorder app is needed. It also limits the feature to specified payment providers. These are Shopify-specific product conditions, not evidence that another setup supports the same flow or accepts your catalog. Shopify: Pre-orders.

Do not use “authorized” and “charged” interchangeably in your worksheet. Stripe's separate authorization and capture documentation says a hold must be captured before its authorization expires; its validity windows vary by transaction and payment method. A long fulfillment gap therefore needs a deliberate payment design, not an assumed open-ended hold. Stripe: Place a hold on a payment method.

A fictional preorder timeline

The following scenario is invented. Fieldglass Supplement Store offers one bottle of fictional “Catalog Item B” as a one-time preorder for $40 total. For this exercise only, assume its proposed provider has confirmed the described full-payment-at-order arrangement for this exact model. No real provider approval, standard lead time or recommended charge timing is implied.

The original order-to-dispatch gap is 15 calendar days. The expected order-to-arrival gap is 19–21 days. These simple calculations describe the fictional offer; they are not acceptable-delay thresholds.

Keep the supplier update alongside the customer-facing promise. If you cannot identify the basis for the dispatch estimate, mark that uncertainty before opening orders. A date entered into a checkout field is not a substitute for an operational plan.

Bring your proposed sequence and its unresolved assumptions to NUMUS. Discuss your preorder model.

Work the delay branch before launch

Now suppose the fictional supplier reports on October 12 that inventory will arrive later. The store reassesses its plan: dispatch October 23, estimated arrival October 27–29. The seven-day shift affects the customer promise as well as the warehouse calendar.

For PRE-104, the team records the original promise, the new estimate, the reason known at that time and who owns the next update. Customer support contacts the customer with a clear explanation and available next steps under the offer and applicable requirements. In this example, the customer chooses to continue. That choice is recorded; silence is not entered as an affirmative response.

An example message outline is: “Your order PRE-104 was expected to ship October 16. Our current estimate is October 23 because the incoming delivery has been delayed. The estimated arrival is now October 27–29. Here is how to contact us about continuing or canceling, and when we will update you again.” This is an operational outline, not a complete notice template for every jurisdiction.

The store dispatches PRE-104 on October 23 and records carrier-reported delivery on October 28. Its actual order-to-dispatch gap was 22 days; order-to-delivery was 27 days. Preserving those actual dates makes the exception explainable later.

For a second fictional order, PRE-105, the customer chooses to cancel on October 13. Support records the request and stops fulfillment. The payment owner checks the successful $40 charge, initiates the appropriate refund on October 14 and records its reference and subsequent status. The two orders now have different outcomes despite belonging to the same launch.

Give the refund handoff a named owner

Order cancellation and the related payment action need separate checks. Stripe, for example, distinguishes canceling an uncaptured payment from refunding a completed one; its refund documentation also describes pending and failed refunds. Those statuses belong to Stripe's workflow and do not establish the timing or tools available in another account. Stripe: Refund and cancel payments.

For your own handoff, record the order, payment reference, amount, requested action, person responsible and next status check. Confirm that the warehouse received the cancellation instruction. Avoid describing a refund as received by the customer merely because someone submitted the request.

If a delay affects many orders, keep an order-level list. One customer's response should not overwrite everyone else's choice. Track “awaiting response,” “continuing,” “canceled,” “payment action pending” and “resolved” according to what actually happened.

Questions to resolve before accepting preorders

Use the finished timeline to ask your proposed provider and checkout team:

• Is this exact product and one-time preorder model supported, including the expected payment-to-delivery gap?
• Which charge sequence has been confirmed, and where are its conditions recorded?
• If authorization and capture are separate, how is the actual expiration identified and handled?
• What happens when inventory or dispatch timing changes after an order is placed?
• Who handles customer messages, cancellation requests and payment follow-up?
• How will you identify every affected order and reconcile each final outcome?

Confirm the customer terms and applicable requirements for the real offer before using the workflow. The finished preparation record should make your model easier to assess without suggesting that a particular payment arrangement will be approved.

Describe the product, planned delivery gap and exception process when you inquire. Discuss your preorder model.