CartGenie writes a small number of first-party cookies onto your store's domain. Most of them are what make the cart and checkout work at all — if a cookie banner blocks them, shoppers lose their carts and orders stop confirming.
This page lists every cookie, explains what breaks without it, and tells you how to configure a consent banner so your store keeps working.
Scope: cookies written on your domain by the CartGenie storefront widget. Cookies on CartGenie's own admin and hosted checkout domains are separate and aren't covered here.
If you're in a hurry, this is the whole answer.
Add these four to your consent tool's "strictly necessary" allowlist so they load before and regardless of consent:
CARTGENIE_CART_ID
CARTGENIE_ORDER_ID
CARTFLOW_CART_ID
CARTFLOW_ORDER_IDPut this one in your "Analytics" or "Performance" category:
CG_USER_SESSIONClassify this one as "Functional" (recommended) or Analytics if you're being conservative:
CARTGENIE_SETTINGS_CACHEAnd one rule that matters more than the categories: never block the CartGenie script itself. See Don't block the script below.
These are required to deliver the cart and checkout your shopper asked for. Under GDPR and the ePrivacy Directive they qualify as strictly necessary, so they don't require opt-in — but you do still need to disclose them in your cookie policy.
Cookie
Lifetime
What it does
What happens if it's blocked
| 30 days | Links the shopper's browser to their cart on our servers. Written when a cart is created, when a shopper returns via an abandoned-cart link, and on first add-to-cart. | The store stops working. Every page load starts an empty cart and nothing a shopper adds ever persists. |
| 2 days | Lets your thank-you page find the completed order after the payment redirect. | The shopper pays successfully but never sees an order confirmation. |
| Read only — never written | Legacy name, read as a fallback when | Only affects shoppers holding a cart from before the rename. |
| Read only — never written | Legacy name, read as a fallback for order lookup. | Same as above. |
CARTFLOW_* cookiesCurrent CartGenie code never sets these — it only reads them, so shoppers who still have a cart from the older CartFlow naming don't lose it. You should still allowlist them. Some consent tools actively delete cookies that aren't on the allowlist, and deleting these would throw away a perfectly valid cart.
Cookie
Lifetime
What it does
What happens if it's blocked
| 30 minutes, rolling | A random, pseudonymous session ID used to group a shopper's activity for behavior and funnel reporting. Refreshed while the shopper is active; a new ID is issued after 30 minutes idle. | No effect on the storefront — the cart and checkout work normally. You lose session-level analytics for that shopper. |
This is the one CartGenie cookie that clearly requires opt-in under GDPR/ePrivacy. It's a persistent identifier used for behavioral tracking rather than for delivering the cart, so it belongs in your banner's Analytics or Performance category, off by default for EU/UK visitors.
Cookie
Lifetime
What it does
What happens if it's blocked
| 10 minutes | Caches your store's settings — store ID, store name, feature flags, display config — so the widget doesn't refetch them on every page view. | Nothing breaks. The widget refetches settings on every page load instead of every 10 minutes: more API calls and a slightly slower first paint. |
Recommended category: Functional / Performance. It holds only your store's configuration — no shopper data — and lives for 10 minutes, so it's defensible as strictly necessary, and most banners let functional cookies load by default. Allowlisting it is the better operational choice. If your legal team prefers to gate it, the only cost is performance.
This is the part that catches people out.
Most consent banners don't block cookies individually — they block the script that writes them. CARTGENIE_CART_ID and CG_USER_SESSION are written by the same CartGenie widget bundle. So if you block the CartGenie script to suppress analytics, you take the cart down with it.
The CartGenie widget has to load unconditionally.
To suppress CG_USER_SESSION while keeping the cart alive, you need a consent tool that supports per-cookie blocking rules rather than script-level blocking. Most enterprise-tier tools (OneTrust, Cookiebot, Termly and similar) can do this; simpler banner scripts often can't.
If yours can't, the practical fallback is after-the-fact deletion: let the cookie be written, then have the consent tool remove it when the shopper declines analytics. That's weaker than true prior consent, so check it against your own compliance requirements. If you need genuine prior opt-in and your tool can't do per-cookie rules, contact support — we can talk through options for your setup.
Matching. All CartGenie cookies are first-party, host-only, and scoped to path=/. Exact-name matching works for every cookie on this page — no wildcards needed.
Custom checkout domains. If your checkout runs on your own domain via a custom domain or CNAME, CARTGENIE_ORDER_ID is also set server-side during the payment redirect, in addition to the browser-side write. This doesn't change how you configure your banner — the cookie name and category are the same either way.
Third-party cookies. CartGenie sets none. Everything on this page is first-party on your domain. Your payment gateway, analytics, and marketing tools may set their own; those are outside CartGenie's scope.
Here's a starting block you can adapt. This is a template, not legal advice — have your own counsel review your cookie policy before publishing.
Strictly necessary cookies Our checkout provider, CartGenie, sets
CARTGENIE_CART_ID(30 days) andCARTGENIE_ORDER_ID(2 days) to remember the contents of your shopping cart and to display your order confirmation after payment. The legacy cookiesCARTFLOW_CART_IDandCARTFLOW_ORDER_IDmay be read for the same purposes. These cookies are required for the store to function and cannot be disabled.Functional cookies
CARTGENIE_SETTINGS_CACHE(10 minutes) temporarily stores this store's display configuration to speed up page loads. It contains no personal information.Analytics cookies
CG_USER_SESSION(30 minutes) assigns a random session identifier so we can understand how shoppers move through our store. It does not identify you personally and is not used for advertising.
A cookie scanner found a cookie that isn't on this list. What is it? It isn't from the CartGenie storefront widget. Check your other embedded scripts — payment gateways, chat widgets, analytics, and pixels all set their own. If you think it's ours, send us the cookie name and we'll confirm.
Can I turn off CG_USER_SESSION entirely for all shoppers? Not from the CartGenie dashboard today. It has to be handled by your consent tool. If store-level control would be useful to you, let support know — demand shapes what we build.
Do these cookies contain personal information? No. CARTGENIE_CART_ID and CARTGENIE_ORDER_ID hold random identifiers that point to records on our servers. CG_USER_SESSION holds a random ID and a timestamp. CARTGENIE_SETTINGS_CACHE holds your store's configuration. None of them store names, emails, addresses, or payment details.
Does this apply if I only sell in the US? The cookies are the same. Consent requirements differ — GDPR/ePrivacy prior consent applies to EU/UK visitors, while US state privacy laws (California, Colorado, and others) generally focus on disclosure and opt-out of sale/sharing rather than prior opt-in. Disclosing all of the above in your privacy policy is good practice regardless of where you sell.