EKGIS Naturals
Cookies and browser storage
cartonium checkout hosts checkout and customer-account pages for EKGIS Naturals on a *.litecheckout.io subdomain. This technical notice describes the cookies and browser storage used by cartonium checkout and Stripe on those pages, and by Google Analytics, which this merchant has configured for checkout.
Current inventory
| Name and location | Purpose and audience | When it appears | Lifetime |
|---|---|---|---|
__stripe_midStripe machine identifier; first-party on this origin, not iframe-confined | Helps Stripe prevent fraud on payment-bearing checkout surfaces. | May be set for a visitor when a surface loads Stripe.js, before the visitor interacts with payment fields. | 1 year, according to Stripe on 24 Aug 2026. |
__stripe_sidStripe session identifier; first-party on this origin, not iframe-confined | Helps Stripe prevent fraud on payment-bearing checkout surfaces. | May be set for a visitor when a surface loads Stripe.js, before the visitor interacts with payment fields. | 30 minutes, according to Stripe on 24 Aug 2026. |
_gaGoogle Analytics cookie; first-party, restricted to this exact host | Distinguishes returning visitors for the merchant's Google Analytics 4 property so checkout starts and purchases can be counted and attributed to the merchant's storefront traffic. | On the checkout page, once the Google tag loads, unless the visitor is in the EEA, the UK, or Switzerland, where analytics storage is denied by default and no cookie is set. | Up to 2 years by default, according to Google's Google tag configuration reference on 12 Sep 2026. |
_ga_N2WMMBVYXLGoogle Analytics session cookie; first-party, restricted to this exact host | Keeps the visitor's session state for the same Google Analytics 4 property. | Same conditions as _ga. | Up to 2 years by default, according to Google's Google tag configuration reference on 12 Sep 2026. |
lc:ga4:begin:<digest>Browser sessionStorage | Marks that a checkout-start event was already sent for this checkout in this tab, so a refresh does not send it twice. The digest cannot be turned back into the checkout link. | When the checkout page first sends that event. | Ends with that tab's browser session. |
lc:ga4:purchase:<orderNumber>Browser localStorage | Marks that the purchase event for that order number was already sent from this browser, so a refresh or a return to the confirmation does not count the order twice. | When the confirmed order is first shown. | Until the browser clears site data; it holds only the order number and a timestamp. |
__Host-lc_customer_sessionHttpOnly cartonium checkout cookie | Authenticates a signed-in customer account. It is not set for a guest shopper. | After the customer completes email-link or emailed-code sign-in. | Stored for up to 24 hours by default, or up to 365 days only when persistent sign-in is affirmatively requested. The session can become unusable earlier after 6 hours of inactivity by default, after 30 days of inactivity for persistent sign-in, or after server-side revocation. Logout clears the cookie. |
__Host-lc_booking_group_resume_<publicRef>HttpOnly cartonium checkout cookie | Lets a guest or signed-in shopper resume the booking group represented by the public reference. | After a valid booking-group recovery action is used. | Up to 24 hours, or until logout. |
__Host-lc_subscription_recovery_<handle>HttpOnly cartonium checkout cookie | Lets a guest or signed-in customer continue a specific subscription-payment recovery. | After a valid subscription recovery action is used. | Up to 1 hour, or until logout. |
litecheckout:fields:<opaqueCheckoutToken>Browser sessionStorage | Restores a checkout draft containing entered name, email, phone, company, delivery address, country, and marketing choice after a refresh. It never contains card details. | Written in the shopper's current tab while checkout fields are edited. | Cleared after a completed order when possible; otherwise it ends with that tab's browser session. |
litecommerce.checkout-account-selection.v1: <opaqueCheckoutToken>Browser sessionStorage | Remembers the account email the shopper explicitly selected while checkout was open, so the same tab can present the permitted pending-payment account recovery after a refresh. | Written when the shopper explicitly continues with the signed-in account during checkout. | Cleared after a completed switch to another account when possible; otherwise it ends with that tab's browser session. |
litecommerce.checkout-account-switch.v1: <opaqueCheckoutToken>Browser sessionStorage | Holds the random retry identifier and opaque switch-epoch recovery state for one pending-payment account change. It contains the selected and branch email, but no payment or sign-in credential. | Created before the current tab asks cartonium to pause the prepared payment, then updated as the recovery branch is admitted and identified. | Cleared after the switched checkout is rebound and its new payment is prepared when possible; otherwise it ends with that tab's browser session. |
lc:booking-group:<publicRef>:initial-checkoutBrowser sessionStorage | Holds a random retry key so an uncertain booking checkout response can be retried without creating another attempt or charge. | Created in the current tab when booking-group payment is prepared, then sent to cartonium with that request. | Reused after an uncertain response and retained until that tab's browser session ends. |
In production, the three __Host-lc_* cookies above are Secure, HttpOnly, SameSite=Lax, and restricted to the host-wide / path. Local development uses equivalent cookie names without the __Host- prefix so HTTP localhost works.
What the inventory means
- Keeping the checkout field draft in sessionStorage does not itself upload the draft. cartonium receives the current delivery address while loading or updating shipping options, which can happen before the shopper continues or submits. When checkout is bound, cartonium also receives the entered contact values and, when enabled, the marketing choice.
- Card details are entered in Stripe-hosted fields and sent directly to Stripe. cartonium does not receive or store card details.
- Closing the tab ends the sessionStorage entries above, not the cookies. In particular,
__stripe_midcan persist for up to 1 year. - This notice does not ask for or record cookie consent. cartonium checkout currently has no cookie-consent banner or preference control.
- This merchant has configured Google Analytics 4 for checkout. Google receives a page view of the checkout route with the checkout link token removed, a checkout-start event, and a purchase event carrying the order number, totals, and item names and quantities. It never receives the checkout link token, payment details, or your email, phone, or address. Advertising features and Google signals are turned off in the tag, and visitors in the EEA, the UK, and Switzerland are measured without cookies. The merchant's privacy policy describes their use of Google Analytics.
- A tenant-enabled marketing checkbox is unchecked by default and starts a newsletter double opt-in. It is not cookie consent.
Storage inside Stripe's cross-origin payment iframe cannot be read or enumerated by cartonium checkout and is not included here. Stripe controls that technology and may change it. See Stripe's Privacy Center for how Stripe.js works and Stripe's Cookie Settings for its current cookie list.
Storefront analytics choices
The consent-based integration has implemented hosted controls, but adoption and consent-based analytics remain unavailable for live use. Sending a choice to the consent handoff API does not establish that hosted analytics has stopped. The Google Analytics inventory above describes the existing policy for environments that have never adopted the new integration. Opt-in storefronts must keep hosted analytics activation on hold until the required verification and separate authorization are complete.
The new policy requires a usable affirmative analytics choice for the original checkout. Unknown or denied consent must suppress the tag and its requests; a usable grant permits analytics storage in every region, with advertising storage and signals still denied. Once adopted, disabling the integration must keep analytics off instead of restoring the existing notice-based defaults.
Under the consent-based policy, withdrawal is accepted only after the platform durably acknowledges it. A failed or undelivered update remains pending. An active page must stop new analytics requests within thirty seconds of acceptance; background pages must suspend analytics and check current consent before resuming. The original grant cutoff cannot be extended by returning to checkout.
If the storefront cannot confirm your change, it should tell you: “We could not confirm your analytics consent change for this checkout.” See the store's existing Privacy link below, when provided. This notice cannot determine whether the storefront can still submit a change and does not recover that ability. Starting a new checkout does not withdraw permission for an earlier checkout.
For storefront integrations relying on browser-local consent recovery, the selected policy excludes one history: an external restore of a complete persistent browser profile that rewinds all relevant consent records together and hides a later choice. The integration does not claim to detect that history. Ordinary reload, restart with current storage, return to a page, back/forward cache and cooperating tabs remain in scope for current-consent checks. Known denial and missing, inconsistent or unusable storage must still suppress analytics; they are not this exception.
After that excluded restore, an older real Allow may appear current again, including for an otherwise eligible new checkout if a later Deny never reached the platform, or applied only to another checkout authority no longer represented by the restored records. The restored records cannot guarantee that the latest choice applies on this storefront or across future checkouts. A withdrawal already acknowledged for its addressed merchant, environment and checkout remains authoritative, including on return. An old Allow or replay cannot undo it; only a permitted, genuinely newer affirmative choice within the original cutoff can re-grant. A new checkout still needs its own qualified handoff and valid storefront choice, not a copied hosted grant.
These limits describe the selected policy for conforming browser-local integrations, not a verified recovery feature or permission to enable analytics. Required implementation, publication and browser/provider acceptance remain separate.
If this integration is separately enabled, its duplicate-event markers use lc:ga4:adopted:v1:<digest>: checkout starts in sessionStorage and purchases in localStorage. They hold only an expiry and dispatch fact, not checkout links or order details. Use ends at the original consent cutoff; expired markers are removed when storage is next reachable. Closed or inaccessible browser storage has no guaranteed physical deletion time. These markers are not written while consent-based analytics is disabled; the legacy markers in the current inventory remain separate.
Accepted withdrawal requires an attempt to remove only owned, reachable hosted Google Analytics cookies, independently of stopping analytics. Cleanup can be partial or fail because of browser or domain limits. An authorized return to the original expired checkout must still allow that attempt while its original reference remains resolvable; legitimate deletion ends that possibility. Unknown or expiry alone does not trigger withdrawal cleanup. One browser cannot confirm all browsers are clear, and data already transmitted cannot be recalled. Essential checkout and consent records are preserved.
The merchant remains responsible for storefront tags, consent capture and privacy disclosures. This notice is not a consent control or a preference center and does not provide automatic cross-device withdrawal. The consent integration guide describes the implemented controls, remaining activation gates and retention: coarse counts at most 30 days, retry records and post-lifecycle cleanup within 7 days, new control evidence at most 365 days, temporary synthetic proof at most 30 days, and necessary recovery copies at most 90 days. Minimum cleanup-addressable consent facts and current integration configuration have no fixed-day maximum while their authorized lifecycle continues. Existing audit obligations are separate. These are contract limits, not a claim that provider backup settings or actual browser behavior have been verified.
How this inventory was checked
A guest-browser inspection on 19 Aug 2026 recorded names and presence only; no cookie or storage values were captured. On 24 Aug 2026, the cartonium checkout source was checked for application-set cookies, storage keys, purposes, audiences, and upper lifetimes, and the Stripe lifetimes above were checked against Stripe's published Cookie Settings.
The Google Analytics rows describe cartonium checkout source as of 12 Sep 2026 and Google's documented cookie names and default lifetime; they appear only for merchants who have configured a measurement ID.
Those dates identify observations, current application behavior, and current provider documentation. They are not promises that retention or provider behavior will never change.