How to Add a Delivery Date Picker to Magento 2 Checkout

A bakery can't fulfill a wedding-cake order the same day it's placed. A florist can't deliver "sometime this week." A furniture store can't install a sofa before the truck even has room for it. Magento's checkout, though, treats every order the same way: place it now, ship it whenever. If your business runs on scheduled delivery or installation, that gap is a real operational problem — not a nice-to-have.

Why Magento has nothing for this out of the box

Core checkout is built around a single assumption: an order becomes "ready to ship" as soon as payment clears, and warehouse/fulfillment figures out timing after the fact. There's no field anywhere in the shipping step for "what date does the customer want this," because Magento's checkout model doesn't have a concept of a customer-chosen delivery date at all — not in the UI, not in the quote/order data model, not in the emails.

Merchants who need it end up improvising: a free-text "special instructions" box that customers ignore or fill in wrong, a follow-up phone call after the order lands, or a note asking the customer to email their preferred date separately. All of that adds manual work and gives the customer no immediate confirmation of when their order is actually coming.

What an admin-configurable date picker needs to get right

Just bolting a calendar widget onto the shipping step isn't enough — the dates it lets a customer pick have to reflect what the business can actually do. That means three settings an admin controls, not the customer:

Minimum lead time — how many days out the earliest available date is, so a same-day order for a delivery that needs 48 hours of prep isn't even selectable.
Maximum days ahead — how far into the future the calendar opens, so customers aren't scheduling a delivery six months out that nobody can plan around.
Blocked weekdays — days the business simply doesn't deliver or install (no Sunday installs, no Monday flower deliveries), removed from the calendar entirely rather than left selectable and then rejected.

Get any of those wrong and the calendar either frustrates customers with dates that don't actually work, or lets through orders operations can't fulfill.

The detail that actually matters: the date has to be validated server-side twice — once when the shipping step is saved, and again immediately before the order is placed. A crafted request that skips the checkout UI and posts directly to the order-placement endpoint with an out-of-window date (a blocked weekday, or a date before the minimum lead time) has to be rejected at that second check too, not just the first. Client-side calendar restrictions are a UX nicety; they are not a validation boundary.

Timezones are where this quietly breaks

The other detail that's easy to get wrong: "today" and "N days from now" have to be computed in the store's configured timezone, not the server's system timezone or the shopper's browser clock. A store running in America/New_York with a server set to UTC will compute the wrong cutoff for what counts as "tomorrow" near midnight if the lead-time math uses the wrong clock — a date that should still be valid gets wrongly rejected, or one that should be blocked slips through. Consistent store-timezone handling on both the client-facing calendar and the server-side validation is what keeps boundary dates from behaving unpredictably right at the edges.

Where the chosen date actually shows up

Once the module captures the date, it isn't just stored and forgotten — it surfaces everywhere someone actually needs to see it: on the order view in the admin panel (so warehouse and fulfillment staff know what they're working toward), on the customer's order confirmation page immediately after checkout, and in the order confirmation email, so the customer has a written record of the date they picked without needing to dig through their account.

Give customers a real delivery date — and validate it properly on both ends of checkout.

See Checkout Delivery Date — from $34