How to add a delivery date picker to Shopify checkout
Most Shopify delivery date apps stop at the cart page. But the last screen where the customer thinks about shipping is checkout, right where they choose a shipping method, and that’s exactly where a delivery date picker does its best work. There is no path to payment that skips checkout, and the date decision sits next to the shipping decision instead of happening a screen earlier.
For most of Shopify’s history, putting a picker there wasn’t possible. Checkout was closed; apps could decorate the storefront, and that was it. That changed with checkout extensibility: on Shopify Plus, apps can now render inside checkout itself, natively, at defined points in the flow. Delivery date selection is one of the things this unlocks best.
I’m the developer of MSK: Delivery Date Scheduler, which ships a Checkout UI extension as a core feature, and this article explains what putting the picker in checkout actually changes, and honestly, who needs it and who doesn’t.
Why the cart isn’t always enough
The cart placement is the default for good reasons: it works on every Shopify plan, it’s easy to install, and most customers pass through it. For many stores it’s the whole answer.
But the cart has two structural weaknesses for date-sensitive orders:
The cart can be skipped. Buy-it-now buttons, accelerated checkouts like Shop Pay, and cart-drawer flows can carry a customer from product page to payment with barely a pause. Every customer who takes that path never saw the cart picker, and their delivery date becomes an email exchange after the fact.
The cart is early. Between the cart and payment, the customer reviews their address and picks a shipping method. A date chosen in the cart sits one screen away from the moment the customer confirms where they live and how it ships. That’s exactly where a date expectation is either confirmed or lost.
The checkout placement closes both gaps: there is no path to payment that skips checkout, and the picker sits exactly at the shipping decision.
What it looks like in checkout
My app’s extension renders directly above the shipping options in checkout, which is a deliberate choice of anchor. The customer sees the two shipping questions, which date, and which method, as one decision instead of two separated by a page.
The widget shows a strip of upcoming date pills, respecting every rule from your settings: lead time, cutoff time, delivery days, and blackout ranges. Tapping a date with time slots enabled opens a slot grid (“Morning 09:00 - 12:00”, “Afternoon 14:00 - 18:00”) below it. Longer horizons reach the rest of the window through an overflow control. The cutoff message, “Order by 2:00 PM for delivery on Tuesday”, appears here too, doing its urgency work at the exact moment of decision.
The choice is written to the order as cart attributes and, alongside them, as searchable order tags (delivery:2026-10-07, slot:09:00 - 12:00) that flow into your admin, same as a cart selection. On non-Plus plans, the cart drawer placement covers the realistic surfaces your plan allows.
One more detail merchants ask about: this is a real Checkout UI extension, reviewed and rendered by Shopify’s checkout runtime, not injected script. It appears in checkout for every Plus storefront theme, including checkout editor-customized ones, without touching checkout templates.
The honest part: this is a Plus feature
Checkout UI extensions require Shopify Plus. That’s a Shopify platform boundary, not an app design choice, and no third-party app can render inside checkout on a non-Plus store. So the decision tree is simple:
- On Plus? Put the picker in checkout, optionally also in the cart, or checkout only. My app lets you pick placement per surface: cart, checkout, or both.
- Not on Plus? The cart page and the cart drawer are your surfaces, and they’re genuinely good ones. My app’s cart widget auto-detects cart drawers across common themes (Dawn, Horizon, popular ajax-cart patterns) and mounts the picker inline right above the checkout button, so drawer-first stores aren’t stuck with a picker nobody sees.
If a non-Plus store is being sold “checkout integration” today, read the fine print: historically that meant carved-up checkout.liquid templates, which Shopify has retired, or it means a cart placement wearing a checkout name.
What a checkout picker can’t do
Checkout extensibility has guardrails, and some of them matter for delivery scheduling:
- The date stays optional. A Checkout UI extension can collect the date but can’t hard-block payment when it’s missing. If your operation requires a date on every order (some food and florist shops do), the checkout picker makes the date highly visible and easy to set, but a customer determined to skip it can still complete the purchase.
- No delivery surcharges per slot. The picker records the choice; it doesn’t price it. Time-slot pricing changes live in shipping rates, not in this extension.
- No slot capacity limits. Same story as the cart widget: slots can be offered, not capped.
For most scheduled-delivery stores these limits are acceptable, since the goal is capture the date at the moment of highest attention, not gate the purchase. But an app that implies otherwise is promising something the platform doesn’t allow.
Is it worth it?
The honest framing: if you’re on Plus and selling date-critical goods, food, flowers, occasion gifts, large items, a checkout picker is not a nice-to-have. It puts the one decision your whole operation depends on in front of every customer, at the exact moment they’re choosing shipping.
If you’re not on Plus, the same $5 gets you the cart page and cart drawer widget, which covers the realistic surfaces your plan allows, and if you upgrade later, the checkout extension is a toggle, not a migration.
There’s a 7-day free trial, and support is answered by the person who built the app within 24 hours. Start with the setup guide for the full picture, or check the app details here.