Add a shop to a converted Framer site

To add a shop to a Framer site after converting it to code, pick the lightest option that fits what you sell. A few products can use payment links or Stripe Checkout with one webhook. A real catalogue with inventory and fulfilment fits a commerce platform used headlessly, such as Shopify's Storefront API, with your converted pages as the storefront. Either way, the design, components and colour tokens from the converted project become the shop's look, so product pages match the rest of the site.

This post compares the options and walks through the two most common builds. Deframer is an independent tool and is not affiliated with, endorsed or sponsored by Framer. It converts only sites you own or have permission to convert. Payment and commerce products change their features and terms often, so treat the third-party details here as a starting point and check each provider's current documentation.

Why convert before adding a shop?

On Framer, selling usually means embedding someone else's widget or linking to a hosted store. That works, but the cart, product pages and checkout look and behave like the third party's, and you can't run your own logic between "Add to cart" and "Paid". Once the site is a Next.js, TanStack Start, Astro or React Router project, you can build product pages from your own components, call a commerce API on the server and receive webhooks. If you only need a "Buy" button, you may not need to convert at all; the table below says when.

The options at a glance

Two questions decide most cases: how many products, and who manages them. If a developer can maintain the product list, Checkout is simple. If a merchandiser needs a product admin, inventory and order management, use a commerce platform.

Option 1: Payment links

A payment link is a URL the provider hosts. Put it on a converted button and you're done. It works on every target, including a static Vite site, because nothing runs on your server. The limits: no cart, and the confirmation logic lives with the provider. It's a fine first step that you can replace later without touching the design.

Option 2: Stripe Checkout in a converted Next.js project

This suits a small catalogue: courses, templates, tickets, a few physical products. The pieces:

src/
  app/
    api/checkout/route.ts         creates a Checkout Session
    api/stripe/webhook/route.ts   receives payment events
    thanks/page.tsx               a thank-you page
  views/
    thanks.tsx                    built from converted components
  server/
    products.ts                   price IDs, product data

The flow:

1. A converted "Buy" button posts to /api/checkout with a product ID.
2. The route handler looks up the price on the server (never trust a price from the browser), creates a Checkout Session and returns its URL.
3. The browser goes to the hosted checkout.
4. Stripe calls /api/stripe/webhook when the payment completes. The handler verifies the signature with the webhook secret, then records the order or sends the product.
5. The customer lands on /thanks.

Keep the secret key and webhook secret in environment variables (.env.local locally, the host's settings in production), and use test-mode keys on preview deployments.

Where do product pages come from? If the Framer site already had a CMS collection for products, it arrives as src/cms/<collection>.json with a detail page per item, prerendered with generateStaticParams. Add a price ID field to each record and the existing product pages gain a working Buy button. Framer CMS to JSON in Next.js shows the file format.

Option 3: Headless Shopify

Use this when you need what a commerce platform does well: inventory, variants, shipping rates, taxes, discounts, order management and an app ecosystem. Your converted project becomes the storefront:

1. In Shopify, set up products and create a Storefront API access token (Shopify's docs describe the current way to do this; it has changed over time).
2. Add a small client in src/server/shopify.ts that runs GraphQL queries against the Storefront API.
3. Build product pages from the API: either replace the converted product collection's JSON with live queries, or keep the JSON for marketing copy and fetch price and availability from Shopify.
4. Use the Storefront API's cart to add lines, then send customers to the cart's checkout URL, which Shopify hosts.
5. Decide on freshness: prerender product pages and revalidate on a schedule, or render on request.

The converted components do the visual work. A product card designed in Framer, now src/components/product-card.tsx with its CSS module, can take its title, image and price from Shopify instead of the CMS JSON.

Option 4: A hosted cart script

Some services add a cart and checkout to any page through a script and HTML attributes on buy buttons. This works on static sites and needs little code, but the cart UI and checkout belong to the service. Add the script in the root layout and the attributes to converted buttons. If you use a Content Security Policy, allow the service's domains; see security headers.

Option 5: Keep the store separate

If the store is big and already exists, link to it at shop.example.com and keep the converted site as the marketing front. That's often the right call for a brand whose store has its own theme and team. Running a Framer site and an app on one domain covers how to make two systems feel like one.

What about taxes, receipts and compliance?

Hosted checkouts and commerce platforms handle card details, so card data never touches your server. Sales tax and VAT handling depends on the provider and the features you enable, and some providers act as merchant of record while others don't. Decide this before you build, because it changes which provider fits. Don't collect card details in your own forms.

Testing a shop before launch

1. Run every purchase path in test mode on a preview URL.
2. Trigger webhook events with the provider's CLI or dashboard and check your handler's logs.
3. Test a failed payment and a cancelled checkout.
4. Check product pages at 1440, 768 and 390 pixels; new prices and badges can wrap differently from the original design.
5. Add an end-to-end test for the checkout button with Playwright; visual regression tests shows the setup.