Your cart didn’t vanish
because of us.

On big drops, some shoppers reached the front of the line and found an empty cart. We pulled the full network capture. The cart was emptied by Shopify’s own checkout queue the instant it finished, not by SuperSwipe. Here’s the proof, in plain English and in full technical detail.

See the technical proof What actually happened
Confirmed by Shopify

Shopify has acknowledged the bug in their own checkout queue, and a fix is in progress.

Shopify has officially replicated the empty cart behavior on their own systems and confirmed to SuperSwipe that it’s a bug in their checkout queue. At approx 9PM PST on May 29, Shopify issued a temporary fix that allowed users to enter the draw. Their team is now working diligently on a permanent fix.

Officially replicated by Shopify on their own systems, not just our capture.
Shopify’s checkout queue wasn’t equipped for the traffic this drop generated.
SuperSwipe does not control Shopify’s queue or throttle settings.

SuperSwipe has run successfully on Shopify’s checkout queues before via testing. The empty cart behavior appeared only with the checkout queue Shopify added for this Cactus Jack drop.

Our infrastructure never blinked.

While Shopify’s checkout queue buckled under the traffic, SuperSwipe stayed up the entire time, every fan, every poll, every spike.

100%
SuperSwipe uptime during the drop
All systems operational
Drop start No incidents · no degradation Drop end
200 OK Every SuperSwipe response in the capture succeeded.
0 Errors, timeouts, or dropped requests on our side.
No access SuperSwipe never has access to Shopify’s checkout or queue.

Three facts, straight from the wire.

The three facts below come straight from a decrypted network capture of a real, queued entry. Nothing is inferred.

The cart was real.

Right up to the moment the queue released the shopper, the cart held its item. Shopify’s own endpoint confirmed it.

Shopify’s queue emptied it.

The instant Shopify’s queue finished, its checkout page sent the browser to /cart/clear, creating a brand new empty cart.

SuperSwipe can’t touch checkout.

SuperSwipe’s only cart call is the clear-then-add on the storefront when a fan taps Enter Draw. It has no access to Shopify’s checkout or queue, and made no cart action after the queue.

0
Fans attempted to enter the draw
90 min+
Shopify held fans in its queue
0
SuperSwipe cart actions in Shopify’s checkout or queue

What actually happened.

No jargon. Just the five things that happened to one shopper’s cart, in order.

1
Shopify storefront

The shopper added their item.

A normal add-to-cart on the store. The cart now holds one item, a real, valid checkout is created and ready to go.

2
Shopify queue

Shopify put them in line.

On a hyped drop, Shopify runs its own checkout throttle, a waiting room that holds shoppers back.

3
Shopify queue

The line cleared.

Shopify’s queue returned PollComplete, “you’re up.” That response contained no cart and no destination URL. What happens next is decided by Shopify’s own checkout code running in the browser.

4
Shopify storefront

The queue sent the browser to “clear cart.”

Instead of dropping the shopper back into their checkout, Shopify’s queue page navigated the browser straight to /cart/clear, and it did so without attaching the cart cookie.

5
Shopify storefront

A brand new, empty cart.

With no cart cookie to recognize, Shopify spun up a fresh, empty cart and showed it to the shopper. Their item was gone, item_count: 0. From the shopper’s seat, it looks like SuperSwipe lost their order. We didn’t. The queue did.

Who did what.

Every request in the capture maps to a responsible party, by who actually made the call, not by who got blamed.

Built, held & destroyed the cart
Shopify
myshopify.com/queue/poll Held the shopper in line, then returned PollComplete
shop…/cart/clear → /cart Emptied the cart, created a new empty one
shop…/checkouts/cn/<token> The queue / checkout page the shopper waited on
No access to checkout or queue
SuperSwipe
status.superswipe.com/release-progress/<id> GET only, live progress. No Set-Cookie, no redirect.
storefront /cart/clear.js + /cart/add.js SuperSwipe’s only cart call: clear-then-add on the storefront when a fan taps Enter Draw. Carries the cart cookie.
checkout & queue No access. SuperSwipe performed no cart action after the queue.

The technical proof.

The single request that empties the cart, captured raw, with the three details that pin it on Shopify’s queue and rule out any app, theme, or server redirect.

post-queue navigation, 17:37:32
GET /cart/clear HTTP/2.0 referer: …/checkouts/cn/<token>/en-us/throttle?_r=… sec-fetch-mode: navigate sec-fetch-dest: document sec-fetch-site: same-origin upgrade-insecure-requests: 1 # note: 34 cookies were sent, but NOT the `cart` cookie   -- response -- HTTP/2.0 302 location: https://shop…/cart server: cloudflare set-cookie: cart=hWNCk29e… ; SameSite=Lax # new EMPTY cart

1 It’s a navigation, not a fetch.

sec-fetch-mode: navigate + sec-fetch-dest: document means a full top-level page navigation (a window.location change), not an XHR, and not a 3xx from any server. The page itself drove the browser here.

2 It came from Shopify’s queue page.

The Referer is …/checkouts/cn/<token>/en-us/throttle, Shopify’s own checkout waiting room. Third-party app scripts (including SuperSwipe’s) do not run on that page.

3 No cart cookie → new empty cart.

The request rode along with 34 cookies, but not the cart cookie. With nothing to identify the existing cart, Shopify minted a fresh one and set it via set-cookie: cart=….

✓ There is no server, theme, or app redirect, we looked.

We scanned 6,422 responses in the queue-completion window for any Location: header pointing at /cart/clear. There were none. Shopify’s PollComplete body carried only a token, no URL. The destination is constructed by Shopify’s own checkout-web JavaScript, which is where the string /cart/clear lives.

✓ Both cart-creation paths reproduce it.

We tested cart creation via Shopify’s Storefront API and via the AJAX Cart API (/cart/add.js). Both replicate the same post-queue empty cart behavior, so the defect isn’t tied to how the cart is built. Shopify is aware of this.

SuperSwipe, on the storefront

SuperSwipe’s Enter-Draw clear

  • POST /cart/clear.js → 200
  • sec-fetch-mode: cors · dest: empty
  • referer: the storefront (/)
  • Carries the cart cookie
  • Fires only when a fan taps Enter Draw. Clear-then-add. Harmless.
Shopify, post-queue

The one that wiped the cart

  • GET /cart/clear → 302
  • sec-fetch-mode: navigate · dest: document
  • referer: …/en-us/throttle (the queue)
  • cart cookie NOT sent
  • Shopify mints a new empty cart.
Time Who What happened Result
17:27:37 SuperSwipe GET /api/release-statistics, read-only telemetry, no Set-Cookie 200
17:30:19 SuperSwipe POST /cart/clear.js, Enter Draw clear-then-add on the storefront (carries cart cookie) 200
17:30:20 SuperSwipe POST /cart/add.js, Enter Draw adds the item, cart item_count → 1 200
17:30:22 Shopify GET /checkout → /checkouts/cn/<token> (enters queue) 302
17:31:19 Shopify GET /cart.json, cart still valid, item_count = 1 200
17:37:31 Shopify POST /queue/poll, queue finishes (PollComplete) 200
17:37:32 Shopify GET /cart/clear, mints a NEW EMPTY cart 302
17:37:38 Shopify GET /cart, shopper lands on the cart… now empty 200
17:37:39 Shopify GET /cart.json, confirmed item_count = 0 200

What this proves.

Here’s exactly what the decrypted capture establishes.

Proven from the capture

  • The queue (ThrottlePoll / PollComplete) is Shopify’s, on Shopify’s domain.
  • The cart was valid (item_count=1) until the queue completed.
  • Shopify’s /cart/clear ran at completion and produced an empty cart.
  • SuperSwipe’s only cart call is the storefront clear-then-add on Enter Draw; it has no access to Shopify’s checkout or queue.

Cart clear after the queue originates from the Shopify-hosted checkout / throttle page (its Referer), where third-party app scripts do not run, and no SuperSwipe resource performed any cart action after the queue.

What Shopify should fix.

This is squarely inside the checkout throttle. Three concrete changes would end the empty cart problem for every merchant running a queued drop.

1

Preserve the cart across the queue. A shopper admitted by PollComplete should land in their existing checkout (/checkouts/cn/<token>) or a populated /cart, never via /cart/clear.

2

Keep sending the cart cookie when leaving the queue. The post-queue navigation reached /cart/clear with no cart cookie, which is what caused Shopify to spin up a new empty cart.

3

Don’t route queue completion through a clear step at all. There is no reason the path out of the waiting room should pass through /cart/clear.

What we’re doing about it.

We’re not waiting on this. Here’s exactly where the fix stands, and how we’re keeping your next drop clean.

Confirmed

Shopify confirmed it’s their bug.

Shopify reproduced the empty cart behavior on their own systems and confirmed to us it’s a bug in their checkout queue. We’re working closely with their team on the fix.

In progress

Solution in progress.

Shopify has acknowledged the issue on their end and their engineering team is working diligently to rectify it. We’re in direct contact with Shopify throughout, and we’ll post each update right here as the fix lands.

Going forward

Future drops, coordinated with Shopify.

Every upcoming drop will be coordinated directly with Shopify, so the checkout queue and the cart stay in sync, start to finish.

We’ll keep this page updated as the fix progresses. Questions in the meantime? Talk to us.

SuperSwipe is read-only at checkout, by design.

SuperSwipe runs fair draws and sets up the cart on the storefront when a fan taps Enter Draw, then hands them to Shopify’s native checkout. We have no access to Shopify’s checkout or queue, so once a shopper is in line, the cart is entirely in Shopify’s hands. When the queue misbehaves, the fix is Shopify’s, and we’ll keep bringing the receipts so the right thing gets fixed, fast.

Install on Shopify Questions? Talk to us