Shopify POS / New feature

Cart sharing on Shopify POS
Making the cart something that isn't tied to a device

A cart a staff member starts building is saved automatically, so another device or another staff member can pick it up and take it all the way through checkout. A cart built on the floor while helping a customer can be handed straight to the register.

What's on this page
  1. What actually changes (understand it in 30 seconds)
  2. How it works : from the floor to the register
  3. Four things this feature lets you do
  4. Before vs. Cart sharing
  5. Cart view and draft order conversion
  6. Requirements
  7. Five points engineers should know
  8. Three use cases you can put to work
  9. A one-line summary you can use in a pitch

1What actually changes

Until now, a POS cart wassomething that lived only on the device that created it.
Cart sharing turns the cart intosomething that is saved automatically and shared across the whole team. No matter who built it, any cart can be opened, continued, and taken through checkout from any device.

Before : the cart lives on the device

A cart built on a mobile device on the floor can only be checked out on that device. Moving to the register means relaying it verbally or ringing it up again.

Cart sharing : the cart belongs to the team

Saved automatically even mid-build. Any device can open the same cart and keep going, and a different staff member can take it straight through to payment.

2How it works : from the floor to the register

Sales associate A Helping a customer on the floor Mobile device Add products Build the cart As items are entered they're saved automatically No saving required Switch between multiple carts Hand off Cart view Customer A's cart Customer B's cart Customer C's cart List of open carts Filtered by the logged-in staff member by default Open on another device Complete checkout at the register Proceed to payment Sales associate B takes over Zero re-entry
floor-to-register selling: a way of selling that lets you separate the person assisting the customer from the person taking payment.
A staff member on the floor builds the cart next to the customer, then hands it straight to the register staff to take payment. It requires carts to move across devices.

3Four things this feature makes possible

Auto-save
Saved automatically as you build it
Works across devices
Open it from any device
Anyone can take over
Any staff member can continue and check out
Draft order in one swipe
Convert a cart into a draft order

4Before vs. Cart sharing

ItemBeforeCart sharing
Saving a cart On the device Stays on the device that created it Auto-save Saved from the moment you start building it
Continuing on another device Not possible (re-enter everything) Possible Open it from any device
Handing off to another staff member Communicated verbally or by note Yes Can complete checkout in place
Serving multiple customers at once Switching carts isn't part of the design Can switch Can move back and forth between per-customer carts
Visibility into open carts Not documented Dedicated view Filtered to the logged-in staff member by default
Converting to a draft order Not documented One swipe

5The cart view and draft order conversion

A dedicated cart view keeps things from piling up

Your team's open carts are organized into a single list.the default filter is the logged-in staff member, so you see only your own carts first. Clear the filter and you can reach the whole team's carts.

draft

Turn a cart into a draft order with one swipe

For carts that don't close on the spot, you canconvert them to a draft order with a single swipe. From there they plug into existing draft order flows, such as following up later or sending a payment link.

How long carts are retained, the cart limit per store, and how deletion is handled are allnot documented. Check the Help Center and the behavior on an actual device before you set internal rules.

6Requirements

You need POS Pro

All POS Pro merchantsare covered. Whether it's available on POS Lite is not documented.

11.11

POS app version 11.11

This feature ships in version 11.11 . You'll need every device in the store on the same app version.

The steps to enable it are said to bedocumented in the Help Center, and the Changelog entry itself gives no specific settings path. Restrictions on supported countries and plans are also not documented.

75 points for technical teams

1. Carts move from the device to the account

What used to be "temporary state local to the device" becomes a shared resource you can access across devices. Offline behavior and conflicts (opening the same cart on two devices at once) are not documented = an area that needs testing on real hardware.

API ?

2. No mention of API / Webhook specs

The changelog only covers the POS app feature itself; whether carts can be manipulated from the Admin API or POS UI Extensions isnot documented. You'll need to check the developer documentation before designing an integration with external systems.

3. You need a plan for "whose sale is this?"

Since the person who builds the cart and the person who rings it up are now different, you have to decide up front how per-staff sales will be counted. How staff attribution is recorded on a cart is not documented = the more your store relies on incentive programs, the more you need to confirm this in advance.

4. The default filter is "my carts"

The cart view is filtered to the signed-in staff member by default. If staff are going to take over each other's carts, failing tospell out clearing the filter in your operating procedurewill lead to "I handed it over but I can't find it."

draft

5. Draft order conversion is a hook into your existing automation

Being able to turn a cart into a draft order with a single swipe meansyou can feed unclosed in-store carts into the existing Flow / app / webhook setups that are triggered by draft orders. Follow-up emails, inventory holds, pay-later links and the like can be connected using what you already have. That said, which metadata ends up on the converted draft order is not documented.

8Three ways to put this to work

A → B
USE CASE 1

Shifting to a "floor-selling" operation that separates selling from checkout

Problem
What a staff member proposed on the floor gets re-entered from scratch by someone else at the register. Reading items back and retyping them stretches checkout time per transaction and backs up the register during peak hours.
Approach
Split the work: floor staff build the cart on a mobile device, and the register staff pick it up from the cart view and only run payment.
Result
No more re-entry at the register, and fewer corrections from mistyped items. Sales staff can keep advising the customer without leaving their side.
Technical notes
The cart view is filtered to the signed-in staff member by default, sothe step of clearing the filter at handoffshould be spelled out in your store manual. This assumes every device is on 11.11 or later.
Customer A Customer B Customer C Customer D Carts in progress
USE CASE 2

Preventing mix-ups when one staff member is handling several customers at once

Problem
While customers wait for a fitting room or a stock check, staff serve someone else, juggling different items across customers in their head and on paper notes. Items get mixed up or missed at checkout.
Approach
Create a separate cart per customer and switch between them while serving. Carts in progress are saved automatically, so they stay intact even if you step away.
Result
What each customer is considering stays on the device, so mix-ups and missed items go down. You won't drop anything even when you serve another customer during a wait.
Technical notes
Cart retention period and limits are not documented.How to handle unclosed carts at closing time(convert to draft orders or discard) — decide this as an operating rule up front.
swipe draft Later Follow-up & payment links
USE CASE 3

Turn carts that didn't close on the spot into follow-up assets as draft orders

Problem
Deals where a shopper says "let me think about it" — high-ticket items, or a size that's out of stock — vanish as spoken words. Nothing about what was proposed, or at what price, stays with the store.
Solution
Convert a cart that didn't close into a draft order with one swipe, then follow up later with a quote or a payment link.
Impact
What was discussed in-store persists as data in the admin and becomes the starting point for follow-up. No time spent reconstructing the proposal.
Technical notes
Existing automations triggered by draft orders (Flow, third-party apps, webhooks) may work as-is. That said,there's no documentation on which metadata (staff member, location, original cart) carries over after conversion, so convert one cart and inspect the real data before building any automation.

9One-line summary you can use in a pitch

"A feature that frees POS carts from a single device and makes them shareable across the team.
Auto-save, handoff between devices, a dedicated cart view, and one-swipe conversion to a draft order.
Build it on the floor, close it at the register. Available now on POS Pro+ version 11.11."