Every store selling something time-sensitive eventually asks the same question: where does the delivery date picker actually go?
The answers you find are usually about how, not where — a theme snippet here, a checkout extension there. The placement itself gets treated as a detail. It is not a detail. It decides which customers give you a date, which ones slip past without one, and how often you find out at the wrong moment.
There are three places. None of them is the best one.
What your Shopify plan allows
Start here, because it removes options before preference does.
| Placement | Plans | How it works |
|---|---|---|
| Product page | Any | Theme app block inside the product form |
| Cart | Any | Theme app block on the cart page or drawer |
| Checkout | Shopify Plus only | Checkout UI extension |
Checkout UI extensions run only on Plus checkouts. That is a platform boundary, not an app limitation, and no app can sell you around it.
Worth untangling one thing here, because the timing confuses people. checkout.liquid and Additional Scripts stopped executing for non-Plus stores in August 2026. Plus stores had already migrated, in 2024 and 2025. So if you arrived at this question because your checkout customisation broke recently, you are almost certainly on a non-Plus plan — and the fix for you is the product or cart placement, not a checkout extension you cannot run.
Product page
The date sits inside the add-to-cart form, so it is chosen before the item is in the cart.
Choose it when the date is part of the decision. A cake for Saturday is not worth buying if Saturday is full. A bouquet that cannot arrive on the 14th is not a purchase, it is a disappointment. Showing availability at the moment of choosing is the difference between a sale and a refund.
It is also the only placement that survives Buy Now. Because it lives inside the product form, a shopper who uses the dynamic checkout button still carries a date.
What it costs you. You are asking for a commitment before the cart exists, which is friction at the earliest point. And on multi-item orders it is the wrong shape: a customer buying four things does not want to pick four dates unless the items genuinely ship separately.
Cart
One date for the order, chosen once everything is in the basket.
Choose it when the date applies to the whole order rather than to individual items — a weekly grocery delivery, a catering order, a single scheduled drop.
What it costs you, and this is the one people get caught by. The Buy Now button skips the cart entirely. A shopper who uses it lands straight at checkout with your cart-page picker never rendered, and that order arrives with no date attached. You will not see an error. You will see an order you cannot schedule.
There is also the cart-style problem. Shopify's own documented approach for a cart date picker works on the cart page only — its help article states plainly that it will not work with drawer or pop-up carts. Plenty of stores discover this after switching to a drawer cart for unrelated reasons.
Checkout — Shopify Plus
The selector appears at the final step, as part of checkout itself.
Choose it when the date is a confirmation rather than a choice, or when you want the path to the cart kept clean. It is also the only placement that catches every order regardless of how the shopper got there, since everyone passes through checkout.
The practical gotcha. Turning the feature on is not enough. The selector appears only when delivery dates are on, at least one availability rule exists, the checkout switch is on, and the block has been placed in Shopify's checkout editor. Three of those live in the app and the fourth lives in Shopify, which is why "I enabled it and nothing happened" is the single most common question about this placement.
What it costs you. The customer is as deep in the funnel as they will ever be. A date that turns out to be unavailable here is the most expensive possible moment to find out — which is exactly why capacity has to be enforced upstream too, not only at the last step. And it needs Plus.
Per-item or per-order?
Placement and date granularity are separate decisions, but they constrain each other, and picking them independently is how stores end up rebuilding this twice.
Per-order means one date for the whole basket. It suits groceries, catering, weekly boxes — anything that leaves on one van on one day. The cart and checkout placements both fit it naturally, because by then the basket is known.
Per-item means each line carries its own date. It suits stores where items genuinely have different production times: a stocked cushion that ships tomorrow next to an upholstered chair that takes ten weeks. This only really works on the product page, because that is the one place where the customer is looking at a single item and its own lead time.
The mistake is choosing per-item dates and then collecting them in the cart. The customer gets asked the same question several times, and the answers are hard to reconcile against a single delivery run. If the items ship together, one date is the honest model. If they genuinely do not, say so at the product level.
The failure mode nobody mentions
Ask in any Shopify community and you will find the same two threads over and over: the date I picked in the cart doesn't show up in checkout, and the date isn't saving to the order.
This is the real risk with delivery dates, and it is not about placement — it is about whether the value survives the hops. A date is collected in the storefront, has to reach checkout, has to be written to the order, and has to reach whatever you actually pick from: an admin view, an order tag, a CSV export for the delivery run.
Break any link and the picker still looks like it works. The calendar renders, the customer chooses, the order completes. You find out on the packing bench.
When you are evaluating an approach — a theme snippet, an app, a custom extension — the question is not "does the calendar show". It is: place a test order, then check the order in your admin, check its tags, and check the CSV export. If the date is in all three, the chain holds.
Choosing
| Your situation | Placement |
|---|---|
| The date decides the purchase (cakes, flowers, events) | Product page |
| One date for the whole order (groceries, catering, weekly boxes) | Cart |
| You use Buy Now / dynamic checkout heavily | Product page, or checkout on Plus |
| You run a drawer or pop-up cart | Product page or checkout — test the cart placement before relying on it |
| The date is a confirmation of something chosen earlier | Checkout (Plus) |
| You want every order to carry a date, no exceptions | Checkout (Plus), with capacity enforced upstream |
| Not on Plus and your checkout customisation just broke | Product page or cart — the checkout route is not available to you |
Most stores land on product or cart. Plus stores usually end up with two placements, not one.
How this works in OrderRules
All three placements read the same availability rules, lead times, cutoffs, blackout dates and capacity. There is no second configuration to maintain, and no way for the checkout view to disagree with the product view, because they are reading one source.
- A date chosen earlier carries forward. At checkout the customer confirms it rather than choosing again, and where items carry their own per-item dates, checkout shows them as a read-only confirmation.
- Capacity applies everywhere. A date that is full greys out in the product picker, in the cart, and at checkout.
- The date reaches the places you actually work from — saved to the order, added as an order tag, and included in the CSV export for your delivery run.
- On Plus, the checkout placement is an addition rather than a replacement. On every other plan, the product and cart pickers work exactly as they always have.
If your constraint is how much you can produce on a given day rather than which days you deliver, that is a different setting — see order date vs delivery date, which covers counting a daily limit against the delivery date instead of the order date.
The honest limit
One thing worth stating plainly, because it applies wherever you put the picker.
Capacity is enforced at checkout, and it holds for every normal case including express checkouts. What it does not do is hold a lock. Checkout validation reads a snapshot of what is already booked, so two shoppers completing checkout within roughly the same second, for the same date, with one place left, can both get through.
It needs near-simultaneous checkouts on a date down to its last place, so it is rare. But it is not impossible, and where a date's capacity is small it is worth sizing it with a place of headroom rather than to the exact maximum. An app that tells you otherwise is claiming something the platform does not offer.
Where to go next
- Delivery date at checkout — the Plus placement, and the four conditions it needs
- Getting started with delivery dates — the product and cart pickers, on any plan
- Theme app block setup — placing the block in your theme
- Delivery capacity limits — why a date greys out when it is full
- The best Shopify delivery date picker apps — if you are still choosing a tool