A setup review drawer that respects SureCart's checkout boundary
The challenge of a cross-domain cart
Shoppers configuring a setup — foil, mast, tail, board, and size — want to see everything they've chosen and the running total before they check out. But the storefront's checkout is owned by SureCart on a separate domain, which rules out the usual same-site cart drawer tricks.
Older SureCart drawer patterns assumed same-origin access to local storage and cookies. That assumption breaks the moment checkout lives on its own domain.
The implementation goal
Design a drawer where the Webflow configurator remains the single source of truth for selected items, and the drawer's only job is to display that selection clearly before redirecting to the correct SureCart checkout URL.
A setup review drawer, with checkout left entirely to SureCart
The configurator keeps state for whatever the shopper has selected. The drawer reads that state, renders a clean summary — foil, mast, tail, board, size, SKU, and total — and then redirects to SureCart to complete the transaction.
This proof card documents the architecture; a full production build is the next step.
Our other projects
The brief was to give configurator shoppers a polished way to review their full setup before checkout, without introducing any code that depends on SureCart's internals or weakens checkout reliability.
Shoppers building a custom setup — choosing foil, mast, tail, board, and size — want a clear summary of what they've picked and what it costs before committing to checkout. Because the shop runs on a separate SureCart domain, a naive browser-based cart implementation risks depending on cross-domain storage or cookies that aren't actually accessible.
The shop lives on its own SureCart domain, separate from the Webflow marketing site. Anything built here has to avoid relying on cross-domain SureCart local storage, cookies, or exposing any secret API keys in browser JavaScript.
The documented architecture keeps the Webflow configurator as the single source of truth for selected line items. The drawer simply renders that state and redirects to a SureCart checkout URL when the shopper is ready to buy — no cross-domain data access required.
The Webflow configurator holds selection state in the browser. The drawer reads that state directly, displays the setup summary, and hands off to SureCart's hosted checkout for payment, keeping the two systems cleanly separated.
- Setup review drawer showing foil, mast, tail, board, size, SKU, and total
- Configurator remains the single source of truth for selected items
- Redirects to SureCart for checkout instead of replicating it
- No cross-domain SureCart cookies, local storage, or secret keys in the browser
- Designed as a layer separate from the configurator Worker itself
This proof card documents an architecture that's ready to build: a review drawer that improves the pre-checkout experience without adding any risk to the checkout flow itself.
- Architecture documented end-to-end from configurator state to SureCart redirect
- Explicit safeguard against exposing SureCart secret keys in browser JavaScript
- Boundary between review UI and checkout authority clearly defined
Does this replace SureCart's checkout?
No — that's the entire point of the design. The drawer only renders what the configurator has already selected and then hands off to a SureCart checkout URL. Payment, order processing, and checkout logic stay fully owned by SureCart, which keeps the shop reliable even though it lives on its own domain.
Why put this in Webflow if external code is involved?
Webflow hosts the configurator experience and needs to show shoppers what they've selected before sending them to checkout. The drawer is JavaScript sitting on top of that Webflow front end — it reads configurator state but never touches SureCart's checkout or payment logic directly.
What is needed before publishing?
A working prototype screenshot and clear framing that positions this as a setup review layer, not a replacement for SureCart checkout.
This work shows SoFlow can improve a commerce experience — giving shoppers a clearer setup review — without blurring the line around who owns checkout and payment security.
Does this replace SureCart's checkout?
No — that's the entire point of the design. The drawer only renders what the configurator has already selected and then hands off to a SureCart checkout URL. Payment, order processing, and checkout logic stay fully owned by SureCart, which keeps the shop reliable even though it lives on its own domain.
Why put this in Webflow if external code is involved?
Heading 1
Heading 2
Heading 3
Heading 4
Heading 5
Heading 6
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
- Item 1
- Item 2
- Item 3
Unordered list
- Item A
- Item B
- Item C
Bold text
Emphasis
Superscript
Subscript
Heading 1
Heading 2
Heading 3
Heading 4
Heading 5
Heading 6
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
- Item 1
- Item 2
- Item 3
Unordered list
- Item A
- Item B
- Item C
Bold text
Emphasis
Superscript
Subscript
Legacy drawer assumptions depended on same-site SureCart behavior — shared local storage and cookies — that no longer matched a shop architecture split across domains.
The new direction gives shoppers a clear setup summary inside Webflow while leaving checkout reliability untouched, since SureCart never has to share cross-domain state with the browser.
Earlier same-site SureCart drawer scripts assumed direct access to local storage and same-origin APIs, an assumption that no longer holds once checkout is served from a separate shop domain. A drawer built on those old assumptions would silently break.
