Framer for Online Stores: What It Can and Can't Do

Framer is a visual, no-code website builder that publishes production-grade sites directly from a design canvas, and it has become a popular front end for brand marketing sites, landing pages, and content-heavy pages that sit in front of a store. What it is not is a full commerce platform: it has no native product catalog, no order management, no payment processing, no tax or shipping logic, and no fulfillment tooling. The practical answer for most merchants is to use Framer for what it is genuinely excellent at — fast, beautifully animated marketing and content pages — and hand off to a dedicated commerce engine like Shopify for anything involving a cart, a payment, or an order.

This guide breaks down exactly what Framer can and cannot do for an online store, the integration patterns teams actually use to bridge the two, where each pattern breaks down at scale, and how to decide whether Framer belongs in your stack at all. If you build storefronts for a living, or you are choosing a platform for the first time, this is the level of detail you need before committing.

What Framer Actually Is

Framer started as a prototyping tool for designers and evolved into a full website builder and CMS with hosting included. You design visually — moving elements on a canvas, setting breakpoints, wiring up interactions and scroll-based animation — and Framer compiles that into a real, deployed website with its own hosting, CDN, and domain management. It has a built-in CMS for blog posts, case studies, and other structured content, along with a component and variable system that lets design teams build reusable, on-brand blocks without touching code.

The appeal for commerce teams is speed and polish. A marketing or design team can ship a new landing page, seasonal campaign, or lookbook in an afternoon, with animation quality that would otherwise require a front-end engineer and a motion library. For pre-launch pages, brand storytelling, "shop the look" editorial content, and campaign microsites, that speed is a genuine advantage over hand-coding or waiting on a developer queue.

What Framer Cannot Do for Commerce

Where Framer runs out of road is anywhere real commerce logic lives. None of the following exist natively in Framer, and no amount of clever CMS modeling substitutes for them:

• Product catalog with variants and inventory — Framer's CMS can hold structured content, but it has no concept of SKUs, variant matrices (size/color/material), stock levels that decrement on purchase, or backorder logic.
• Cart and checkout — there is no persistent cart state across pages, no multi-step checkout, no address validation, no PCI-compliant payment capture built in.
• Tax, shipping, and duties calculation — real-time tax rates by jurisdiction, carrier-calculated shipping rates, and customs/duties for international orders all require a commerce engine with that logic maintained and kept current.
• Order management and fulfillment — order history, order status webhooks, packing slips, returns/exchange workflows, and integration with a warehouse or 3PL are entirely outside Framer's scope.
• Customer accounts tied to purchase history — login, saved addresses, past orders, and loyalty balances all need a backend that owns the customer-and-order relationship.
• Subscriptions and recurring billing — retry logic on failed cards, dunning emails, plan upgrades/downgrades — this is a specialized problem Framer has no opinion on.

This is not a criticism of Framer — it was never built to be a commerce platform, in the same way a design tool like Figma was never built to run your database. The mistake is expecting a page builder to grow into an order-management system through plugins and workarounds. It generally does not, and the workarounds that exist are worth understanding before you rely on one in production.

The Three Integration Patterns Teams Actually Use

In practice, teams that want Framer's design speed and a real checkout end up choosing one of three patterns. Each has a real, different failure mode — the choice should be deliberate, not accidental.

1. Framer as the marketing shell, checkout lives elsewhere entirely

The cleanest pattern: Framer hosts the brand site, landing pages, and content — everything before the shopper decides to buy — and a "Shop" or "Buy Now" link sends them to a separate, fully independent storefront (a Shopify store on its own domain or subdomain, for example). There is no shared session, no shared cart state, and no attempt to make the two feel like one continuous app. The handoff is a plain link.

This works well when the commerce need is straightforward — a single product line, a small catalog, or a merch/limited-drop model where the "store" is genuinely a distinct experience from the brand site. Its weakness is exactly what it sounds like: the shopper notices the seam. A jump from a beautifully animated Framer page to a visually different checkout domain can read as jarring if the two are not styled to match closely, and you lose any single-cart, cross-page continuity a shopper might expect (add-to-cart from three different landing pages into one cart, for instance).

2. Embedded checkout widgets or Buy Buttons inside Framer

Several commerce platforms — Shopify's Buy Button among them — ship an embeddable widget that can be dropped into any HTML-capable page, including a Framer page via its embed/code component. This gets you an actual add-to-cart and checkout flow without leaving the Framer-hosted page, which closes the seam from pattern one.

The trade-off is control and depth. Buy Button widgets are deliberately simple — they render inside an iframe or a constrained embed, which limits how far you can restyle them to match a highly custom Framer design, and they typically only support a subset of what a full storefront theme can do: complex variant pickers, upsells, subscription options, and bundle logic are often out of reach or require workarounds. For a single hero product or a small set of SKUs, this is a reasonable middle ground. For a full catalog with rich merchandising, it starts to feel constrained fast, and debugging embed-specific CSS/JS conflicts inside a page builder's iframe is its own tax on engineering time.

3. Headless commerce with Framer (or a Framer-style front end) as one surface among several

The most architecturally ambitious pattern treats commerce as a backend service — a headless platform like Shopify's Storefront API, or a fully headless engine like Medusa — with the actual storefront rendered by something purpose-built for commerce UI: typically a Next.js application. In this pattern, Framer's role, if it has one at all, shrinks to what it is genuinely good at: a marketing microsite, a campaign landing page, or brand-story content that links out to the "real" storefront, rather than trying to host commerce itself.

The reason this pattern wins for serious commerce businesses is that a headless setup gives you a proper server-rendered product page, cart, and checkout with full control over layout, performance, and merchandising logic — things a page-builder embed structurally cannot match. The cost is real: it requires an actual engineering team, a Next.js (or comparable) codebase, and ongoing maintenance of that storefront, which is a different commitment than "a designer builds pages in Framer." It is the right answer when commerce is the business, not a side feature of a marketing site.

A Decision Framework: When Framer Belongs in Your Stack

Rather than treating this as a binary "Framer vs. real store" choice, it helps to separate the question by what part of the experience you are building.

• Pre-launch or waitlist page for a product that does not exist yet — Framer is close to ideal. No commerce logic needed, animation and speed matter, and you will likely rebuild this page anyway once the product ships.
• Brand site with a small "shop" section (under a few dozen SKUs, simple variants) — pattern one or two is reasonable. Keep the storefront simple and don't force Framer to do more than link to it or embed a lightweight buy button.
• Campaign microsites, lookbooks, or seasonal drops that link to an existing store — Framer as the shell (pattern one) is a good fit, since these pages are inherently temporary and content-first.
• A growing catalog with variants, promotions, subscriptions, or international shipping — this is a real commerce platform's job. Use Shopify (or a headless engine) as the actual storefront and reserve Framer, if you keep it at all, for the surrounding marketing content.
• Commerce is the core business and design differentiation matters a lot — this is where the headless pattern earns its cost: a purpose-built Next.js storefront gives you commerce-grade performance and full design control that a page builder's embed model cannot reach.

Where Design Systems Fit In

Whichever pattern you land on, the visual quality of the commerce surface itself still has to hold up — a stunning Framer landing page that hands off to a bare, undecorated checkout undercuts the whole effort. If your commerce layer is Shopify, a theme built with the same attention to typography, spacing, and product presentation as your Framer front end closes that gap; our Shopify theme catalog is built around exactly that principle, with themes designed to feel like a continuation of a polished brand site rather than a generic template bolted on at checkout. And if your team is designing the storefront itself rather than buying a theme outright, a well-structured Figma UI kit gives designers and engineers a shared source of truth for the commerce pages, the same way Framer's component system does for the marketing pages — so the two halves of the stack don't visually diverge.

Teams occasionally ask whether it is worth trying to make Framer itself carry the full storefront through third-party commerce plugins beyond the basic buy-button pattern. In our experience this rarely holds up past a small catalog: the plugins tend to be thinly maintained relative to the pace of change in tax rules, payment methods, and fraud prevention, and you end up debugging commerce-critical logic inside a tool that was not built to expose the level of control that debugging requires. It is a reasonable bet for a small, low-stakes catalog and a risky one for anything with real revenue at stake.

Frequently Asked Questions

Can I run an entire Shopify store's storefront inside Framer?

Not in a way most teams should rely on for a real catalog. You can embed simple Buy Buttons for a handful of products, but full storefront features — rich variant pickers, collection filtering, cart persistence across pages, account pages — are outside what Framer's embed model supports well. Beyond a small catalog, a dedicated Shopify theme or a headless storefront is the more durable choice.

Does Framer have its own payment processing?

No. Framer has no native checkout or payment capture. Any actual payment has to come from an embedded third-party widget (like a Buy Button tied to Shopify) or a link out to a separate commerce platform's checkout.

Is it better to use Framer or Webflow for a store's marketing pages?

Both are visual, no-code builders with similar strengths and the same fundamental limitation for commerce — neither is a checkout platform. Framer tends to have an edge in animation and interaction polish; Webflow has historically had somewhat deeper CMS and e-commerce-adjacent plugin support. For most brand-site-plus-storefront setups, the choice between them matters far less than getting the handoff to a real commerce platform right.

If I'm starting from scratch, should I skip Framer and just build the storefront in Next.js?

If commerce is central to the business and you have engineering resources, a Next.js storefront (headless against Shopify or an engine like Medusa) gives you more control and a more unified experience than stitching Framer to a separate checkout. If you are pre-launch, resource-constrained, or commerce is a small part of a content-heavy brand site, Framer for the marketing pages plus a proper Shopify theme for the store is a faster, lower-risk way to get to market.