If your Shopify pickup orders show as “Shipping” in the admin, a pickup app is almost certainly routing them through Shopify’s shipping framework instead of native local pickup. The order looks like a shipment to Shopify, so the admin, POS, and “Ready for pickup” emails all read Shipping — and the real fulfillment type lives only inside the app’s own dashboard. The fix is an app that writes real native pickup orders.
This is one of the most confusing things a multi-location store hits after installing a pickup app. The shopper clearly chose pickup. The app’s dashboard says pickup. But Shopify’s own admin says Shipping, complete with a “create shipping label” button on an order nobody is shipping. Here’s what’s happening and how to make it stop.
Why do my pickup orders show as Shipping in the Shopify admin?
There are two layers to the answer: what Shopify does natively, and what some apps do on top of it.
Native Shopify handles this correctly. When local pickup is enabled on a location and a shopper picks that location at checkout, Shopify creates a real pickup order — it carries the pickup location, shows a “Ready for pickup” fulfillment action, and never asks you for a shipping label. That’s the behavior you want.
The problem appears when a third-party pickup app changes how the order is built. To add their own date pickers, time slots, or delivery options, some apps turn off Shopify’s native store pickup and route every pickup and local-delivery order through the shipping framework instead. To Shopify, the order is now a shipment.
So the admin labels it Shipping, the order shows a shipping address (often the store’s own address, auto-filled), and Shopify offers a shipping label for an item that’s being collected in person. The shopper chose pickup; the data says ship.
Is this a bug, or is it intentional?
For an app doing this, it’s usually a documented design choice — not a glitch you can fix in settings.
Based on publicly available help docs as of 2026, Bird Pickup Delivery Date is the clearest named example: its own documentation states it disables Shopify’s native store pickup and routes pickup and local-delivery orders through the shipping framework, telling merchants to ignore the admin’s shipping-label prompt. Its docs describe this as a deliberate design choice, and note that Shopify’s native views won’t correctly display the actual fulfillment method the shopper chose.
That’s an honest disclosure on the app’s part — but it puts the burden on you. The real fulfillment type (V1 in order notes, later in custom fields) lives in the app, while Shopify’s own records say something different. Other pickup apps that lean on the shipping framework produce the same symptom; Bird just documents it plainly.
The takeaway: if your pickup orders read Shipping and an app is involved, no Shopify setting will move them back. The behavior comes from how the app builds the order. To change it, you change the app — see our breakdown of real native orders vs draft orders and shipping workarounds.
Why does “pickup-as-shipping” actually hurt?
It’s tempting to file this under cosmetic — the order came through, the money cleared, who cares what the label says. But the wrong fulfillment type quietly breaks four things that a multi-location store relies on every day.
Native pickup notifications stop firing. Shopify’s “Ready for pickup” and “Picked up” emails and texts only send on real native pickup orders. If the order is a shipment, Shopify never knows it’s a pickup, so those messages never go out. You either notify customers by hand or depend on the app’s own emails — one more system to trust.
POS Pro loses the pickup queue. Your in-store staff work pickups from POS Pro’s native pickup workflow, which reads native pickup fulfillment. A shipment doesn’t appear there as a pickup task, so staff lose the built-in queue and track collections in a spreadsheet or the app dashboard.
Reporting and fulfillment data go wrong. Every report that splits orders by fulfillment type now miscounts. Pickup looks like shipping. Your pickup order share, carrier costs, and per-location pickup volume are all distorted because the underlying records lie about what the order is.
You’re maintaining two sources of truth. The whole point of running on Shopify is that the admin is the system of record. When the true fulfillment type lives in an app dashboard and Shopify says something else, you’ve split your source of truth in two — and reconciling them is manual work forever.
The fix: real native pickup orders
The durable fix is an app that writes real native pickup orders — orders Shopify itself recognizes as pickup, carrying the chosen store, with no shipping label in sight.
When the order is a genuine native pickup order, everything downstream just works, because it’s Shopify’s own machinery doing the work:
- The admin shows the pickup location and a “Ready for pickup” action, not a shipping label.
- Native “Ready for pickup” and “Picked up” emails and texts send automatically.
- POS Pro surfaces the order in its native pickup queue for in-store staff.
- Reports count pickup as pickup, so your fulfillment data is real.
This is the difference between an app that composes with Shopify-native and one that replaces it. A pickup app like BopiSafe should add the shopper-facing layer — real-time per-store stock, an in-cart store picker, time slots — while letting Shopify’s own fulfillment, notifications, and POS run underneath, untouched. When it does that, you get one source of truth instead of two.
How to diagnose your own store in 5 minutes
You don’t need to read anyone’s documentation to find out which kind of app you have. Open your admin and check a recent pickup order against this list.
| Check | Real native pickup order | Routed through shipping |
|---|---|---|
| Fulfillment method shown | Pickup, with the store location named | ”Shipping” |
| Shipping address on the order | None (it’s a pickup) | A shipping address, often your store’s own address auto-filled |
| Admin action offered | ”Mark as ready for pickup" | "Create shipping label” / “Buy label" |
| "Ready for pickup” email | Sends automatically from Shopify | Doesn’t send (app sends its own, or none) |
| POS Pro pickup queue | Order appears as a pickup task | Order doesn’t appear as a pickup task |
| Where the true type lives | In Shopify’s order record | In the app’s separate dashboard |
If you’re landing in the right-hand column on three or more rows, your pickup orders are being routed through the shipping framework. That’s the symptom this whole post is about, and it won’t change until the app does.
One more tell: place a test pickup order yourself from a private browser session, then watch your inbox. If no native “Ready for pickup” email arrives when you mark the order ready, Shopify doesn’t think it’s a pickup — regardless of what the app dashboard shows. For the deeper version of this, see how a proper checkout validation layer keeps the order’s fulfillment type honest end to end.
What “good” looks like for a multi-location store
Step back from the bug for a second, because the fix is also the foundation of a real BOPIS experience. A multi-location store wants the whole loop to hold: shoppers see real-time per-store stock, choose where to collect from an in-cart store picker, and check out as a real order that Shopify recognizes as pickup.
That last step is exactly the one that breaks when pickup is faked as shipping. Get it right and the rest of your stack — notifications, POS, reporting — falls into place for free, because you never left Shopify’s native rails. Get it wrong and you spend your weeks reconciling two systems that disagree.
If you’re setting this up from scratch rather than fixing an existing app, start with our full BOPIS setup guide — it covers locations, pickup-only products, and capacity before you ever touch a third-party app.
Industry research backs the priority. Per NewStore’s inventory-visibility research, 71% of consumers expect to view in-store inventory online, and a large share won’t make the trip without it — which means the shopper-facing layer (real per-store stock + a store picker) is where pickup apps earn their keep. None of that value is worth poisoning your order data to get. You can have the shopper-facing polish and correct native pickup orders; they aren’t a trade-off.
A quick worked example
Consider a 3-location apparel store doing 600 pickup orders a month. If every one is routed as a shipment, that’s 600 orders a month where the native “Ready for pickup” email never fires — so staff manually message 600 customers, or rely on app emails the customer may not recognize. It’s 600 orders missing from the POS pickup queue, and 600 rows of fulfillment data that count pickup as shipping.
Now flip the app to one that writes real native pickup orders. Those 600 emails send themselves, the 600 orders appear in POS Pro’s pickup queue, and the reporting is accurate without anyone touching a spreadsheet. The shopper experience is identical; the operational tax drops to zero. That’s the entire case for caring about a label that “looks cosmetic.”
Written by the BopiSafe team — we build BOPIS infrastructure for Shopify merchants.
Next steps
- Run the 5-minute diagnostic above on a recent pickup order — find out which kind of app you have.
- Read real native orders vs draft orders to understand the two ways pickup apps fake an order, and why both cost you.
- If Bird is your current app, see our BopiSafe vs Bird comparison for a side-by-side on how each structures pickup orders.
- Or install BopiSafe to write real native pickup orders that your admin, POS Pro, and native notifications all recognize.
Seeing pickup orders show as Shipping and not sure which app is doing it? Email miles.bopisafe@outlook.com — we’ll help you read the order record and figure out the cause.