Commerce compatibility and scope

Sellerlane supports a large Shopify-style theme and commerce surface, but “compatible” is never used to mean that every Shopify product, first-party app, proprietary network signal, or third-party app contract exists here.

For the exact Liquid, tags, forms, pagination, storefront-filter parameter, localized URL, editor-preview, rendering, asset-storage, consent, and SEO boundary, see Shopify theme compatibility.

This page is the fail-closed scope contract. Unsupported input is rejected rather than accepted and ignored.

Compatibility levels

Level	Meaning
Compatible	The documented request, response, Liquid, or business behavior is supported and regression-tested.
Typed Sellerlane extension	Sellerlane provides an explicit schema with validation; a Shopify app/theme must adapt to it.
Unavailable	The primitive is rejected or hidden. No customer-facing configuration should promise it.
Approximation	A useful Sellerlane calculation exists, but it is labelled and is not claimed to reproduce a proprietary Shopify model.

Cart and line customization

The documented AJAX cart endpoints, section rendering, quantities, discount codes, notes, and typed line modifiers are supported. Sellerlane deliberately does not persist arbitrary Shopify properties[...] or cart-level attributes[...].

Use typed product modifiers for text, choices, files, dates, measurements, price adjustments, validation, and fulfillment snapshots. Unknown free-form fields are rejected so a theme cannot display a promise that disappears from the order. See Cart AJAX API.

Selling plans and subscriptions

selling_plan is unavailable. Products are one-time purchases; subscription contracts, recurring billing, dunning, pause/skip/cancel, recurring-order generation, and customer subscription management are not implied by the product or cart APIs.

Themes must hide subscription selectors. An integration that submits a selling plan receives a validation error instead of silently creating a one-time order.

Markets, currencies, and B2B

Storefront language localization is supported; Shopify Markets country/catalog switching is not.
The launch commerce contract uses the configured store currency. Historical order-time FX conversion and silent cross-currency gift-card/store-credit use are unavailable.
B2B company accounts are available: companies with locations and invited buyers, company- and location-assigned catalogs (product/collection availability, contextual prices, quantity rules, volume breaks), payment terms (Due when invoiced, Net 7–90, Due on fulfillment, and Due on delivery) with credit limits, optional or required PO numbers with merchant draft review, and location-owned tax exemption, all resolved through the ordinary storefront shipping engine.
B2B quotes, invoice deposits, and company location store credit are available as independently enabled modules rather than default behavior. Deposits are a single location-level percentage computed on the amount due before tenders — there are no milestone schedules and no per-line deposits, and store credit, gift cards and loyalty never apply to a deposit leg. Location store credit is owned by the company location and may be applied in full or in part; it is never interchangeable with a customer’s personal store credit.

See Financial semantics.

Bundles, recommendations, and offers

Fixed catalog bundles, component-derived inventory, build-a-box, cross-sell, typed upsell rules, product-page offers, cart offers, and cart-drawer offers are supported as documented.
Accepting a cross-sell or upsell creates ordinary snapshotted cart/order lines; its rule and placement are attribution provenance, not separate revenue. Any offer reduction is an allocated discount and the line keeps the normal tax, inventory, fulfillment, return, and refund contract.
Nested bundles are unavailable.
Checkout and payment-amending post-purchase upsells are unavailable until reusable payment authorization, inventory/tax/shipping recalculation, order amendment, and fulfillment-hold semantics are complete.
Recommendation operators or sort modes that the server cannot execute are rejected; they are never accepted as decorative configuration.

See Bundles and upsells.

Loyalty, referrals, and reviews

These are native Sellerlane systems, not claims that Shopify core contains the same data model. Points, referral awards, and rewarded reviews follow the documented Sellerlane ledgers and channel policies.

The current typed loyalty surface is points-only on earn. Its published catalog redemptions support amount discounts, percentage discounts, and free shipping; free-product, gift-card, and store-credit loyalty redemption rules are rejected and must remain hidden. This does not limit the separate referral and review engines: those can issue their documented discount or store-credit artifacts. Points are non-monetary units and never inherit an ISO currency merely because a configured redemption rate can produce a separately labelled value estimate.

Shop, Shop Pay, Shopify Protect, and Shopify’s proprietary risk/prediction signals are not re-created from weaker inputs. A Sellerlane prediction or risk score is labelled as Sellerlane’s own model or approximation.

Analytics parity claims

A report can be listed in an observed compatibility manifest without being available. Sellerlane distinguishes defined, executable, and captured-reconciled status. Only the last status proves that a captured production Sellerlane report export matches a captured Shopify export from the same controlled scenario under the declared tolerance. A controlled Sellerlane generator can validate comparator behavior and observed fields, but it is not a substitute for production report output.

An unavailable report, missing field, or proprietary taxonomy is shown as such; the frontend must not turn a disabled manifest entry into an apparently working chart. See Analytics definitions.

Pre-production launch gates

Code support is not proof that an external dependency has been provisioned or that a Shopify comparison has been captured. Before production:

Provision the dedicated, TLS-only, synchronously durable analytics outbox and run infra/aws/ensure-analytics-outbox.sh --check. Production must not share the ordinary cache endpoint or use an evicting memory policy. Alert on both queue depth and oldest-event age. Against a disposable instance of the exact deployed Redis/Valkey version and topology, run the real Lua contract described in Analytics definitions; an in-memory queue test alone does not prove the production claim scripts. The gate includes concurrent-tab session selection, an uncertain-result replay with the identical intent, the exact 30-minute boundary, UTC-midnight rollover, and resolve-before-browser-event ordering. Valkey failure must expose neither a new visit cookie nor an analytics context.
Apply and verify the Cloudflare analytics transforms with infra/cloudflare/ensure-analytics-edge.sh. Enable trust for detailed location and bot headers only after the transform check succeeds, and verify that origin/ALB ingress still accepts only Cloudflare source ranges. Header shape alone is not proxy authentication; direct client copies remain untrusted.
Connect a real malware/content-scanning provider and give it access only to private review-quarantine/ and review-scanned/ paths—not the public reviews/ namespace. Verify the separate durable promotion worker and run infra/cloudflare/ensure-review-media-r2.sh --check. Pending, rejected, scan-failed, and clean-but-not-public-ready media must never have a storefront URL or qualify a photo/video reward. The edge must require the private review-publications/...ready marker as well as the exact canonical source. Exercise scanner failure, audited retry, promotion retry, delete-race cleanup, and both private-prefix lifecycle rules before accepting uploads.
Capture both Shopify CSV exports and production Sellerlane report exports from the identical controlled reconciliation scenarios, and retain their provenance and digests. Synthetic Sellerlane fixtures test internal invariants but cannot substitute for either captured output. Review every expected-difference allowlist entry and keep it narrow, owned, and expiring.
Run authenticated, seeded screenshot regression for Dashboard, Reports, Exploration, Cohorts, Live View, and report lifecycle states. A hand-built golden image is not external parity evidence. Live View also still needs new/returning identity on each map point and cluster; its aggregate identity counts exist, but the current activity-colored map is not that visual split.
Keep every unresolved, disabled, approximate, or executable-unreconciled manifest entry visible as such. Strict parity can be claimed only for the captured-reconciled subset, not for the 187-slot catalog as a whole.

Multi-currency launch additionally requires immutable historical reporting FX and payment/payout conversion facts. Subscriptions, Markets primitives, and payment-amending post-purchase offers require their own complete runtime contracts; hiding them is the correct launch behavior until those contracts exist.

Extending this contract

A new compatibility claim requires all of the following:

a public semantic definition;
fail-closed request validation;
immutable snapshots for order-affecting configuration;
idempotent financial/inventory side effects;
controlled fixtures and edge-case tests;
captured external reconciliation when exact parity is claimed;
customer and merchant UI that does not expose unsupported options.