Is Webflow Good for Ecommerce? A Limits-First Review

TL;DR: Webflow Ecommerce is a good fit for a small catalogue with simple pricing and a single currency, and a bad fit for anything that needs variants at scale, recurring billing or multi-currency checkout. Seven limits decide the answer before design ever enters the conversation, and this Webflow Ecommerce review lists all seven below with the Webflow document each one comes from. Six of the seven are numbers Webflow publishes. The seventh, whether payments work in a given country, is set by Stripe and PayPal rather than by Webflow.

• Ecommerce Standard allows 500 Ecommerce items; Plus allows 5,000 and Advanced allows 15,000, per Webflow's pricing page.
• Ecommerce Standard charges a 2% Webflow transaction fee, while Plus and Advanced charge 0%, also per Webflow's pricing page.
• Each product item can hold 50 variants at most, across 3 option sets, and every variant spends Ecommerce items (Webflow Help Center).
• A Webflow store has one currency, and switching it saves every product as a draft without converting a single price (Webflow Help Center).
• Webflow Ecommerce supports exactly two payment providers, Stripe and PayPal, and availability depends on the merchant's country (Webflow Help Center).
• Automatic tax calculation covers the United States, Canada, the European Union and Australia, and nothing else (Webflow Help Center).
• Native recurring billing is gone, because Webflow subscriptions ran on User Accounts and User Accounts was disabled on 29 January 2026 (Webflow Help Center).

Is Webflow good for ecommerce?

Webflow is good for ecommerce when a catalogue fits inside a 500 to 15,000 Ecommerce item cap, keeps each product under 50 variants, sells in one currency, pays through Stripe or PayPal, ships mainly to the United States, Canada, the European Union or Australia, and needs no recurring billing. Webflow is the wrong tool the moment one of those stops being true, because none of them is a build problem that more development hours can solve.

In the agency builds I take over mid-project, the store that goes wrong is almost never badly designed. Rather, it is a store whose catalogue shape was never checked against those ceilings before the Site plan was bought. Webflow publishes nearly all of the relevant numbers, which makes the fit question answerable in an afternoon rather than discoverable at launch, and where Webflow publishes nothing, as with the countries its payment providers reach, the honest move is to say so and point at the provider's own availability page. The decision rule I apply on client projects: if the catalogue, the billing model and the tax footprint all sit inside the published limits, Webflow Ecommerce is the cheaper and faster build; if any one of them sits outside, the answer is a different cart, not a workaround.

What are Webflow Ecommerce's hard limits on each Site plan?

Webflow Ecommerce runs on three Site plans whose ceilings and fee treatment differ sharply: 500 Ecommerce items with a 2% Webflow transaction fee on Ecommerce Standard, 5,000 items at 0% on Ecommerce Plus, and 15,000 items at 0% on Ecommerce Advanced. Prices, seat counts and page allowances follow below, all taken from Webflow's own pricing page and retrieved 24 October 2026.

Published limit	Ecommerce Standard	Ecommerce Plus	Ecommerce Advanced
Price, billed yearly	$29/mo	$74/mo	$212/mo
Webflow transaction fee	2%	0%	0%
Ecommerce items	500	5,000	15,000
Staff accounts	3	10	15
Static site pages	150	300	Not listed

The 2% fee on Ecommerce Standard is the line most store owners misread, because it reads like a rounding error and behaves like a subscription. The gap between the Standard and Plus yearly-billed prices is $45 per month, or $540 per year, and dividing that gap by the 2% fee puts the crossover at $27,000 of annual gross sales. Both figures are arithmetic on Webflow's published prices rather than numbers Webflow states. Below $27,000 in sales, Standard is cheaper; above it, Standard is a tax on growth.

The decision rule I give agencies pricing a store build is to quote the Site plan at the tier the catalogue will reach in year two, not the tier it launches on. Plan structure and the wider Webflow plan family are covered in my breakdown of Webflow pricing plans, and the separate bandwidth ceilings are in my guide to Webflow bandwidth limits.

How many products can a Webflow Ecommerce store list on each plan?

A Webflow Ecommerce store can list 500 Ecommerce items on Ecommerce Standard, 5,000 on Ecommerce Plus and 15,000 on Ecommerce Advanced, and because every product variant spends items from that allowance, a Standard store holds only ten products carrying a full 50-variant set, or roughly forty products at twelve variants each. Those two product counts are arithmetic on Webflow's published ceilings, not figures Webflow states.

Webflow's documentation on product options states that "You're able to create up to 3 option sets per product" and that "Each product item can have a total of 50 variants", and it is explicit that each variant counts toward the Site plan's item limit (Webflow Help Center, Create product options and variants). A shirt in five sizes and four colours is not one item. Rather, it is up to twenty.

Treat the ten-product figure as an optimistic ceiling rather than a promise. Webflow's Ecommerce Collections documentation says "Variants are created for each combination of options and each variant is a product on its own", and it does not publish whether a parent product consumes an item of its own on top of its variants (Webflow Help Center, Ecommerce Collections overview, updated 30 June 2026). When I audit a store for plan fit, the first number I calculate is total variants, never total products.

What I see agencies get wrong here is treating the variant ceiling as a storage problem when it is a merchandising problem. If a product genuinely needs more than 50 combinations, the fix is to split it into separate products or separate option sets, not to look for a higher plan, because the 50-variant ceiling is per product and does not move with the Site plan.

Which payment providers does Webflow Ecommerce support, and how do you check your country?

Webflow Ecommerce supports two payment providers and no others. Webflow's Help Center states plainly that "Webflow Ecommerce supports two payment providers", naming Stripe and PayPal as the pair, and that wallet payments, specifically "Web payments (Apple Pay, Google Pay, Microsoft Pay)", arrive "through Stripe" rather than as independent integrations (Webflow Help Center, Connect a payment provider, updated 31 October 2025). Any other gateway, whether Adyen, Mollie, Klarna, iDEAL or a regional bank processor, sits outside that supported pair.

Country availability is checked on the providers' own sites, because Webflow publishes no country list of its own. The same Help Center article states only that "Stripe and/or PayPal may not be available in every country", then defers to each provider: Stripe's global availability list and PayPal's worldwide country list. Webflow Ecommerce therefore reaches whichever countries Stripe or PayPal reaches, which means the fit question for a merchant outside the obvious markets is answered on Stripe's site, not Webflow's. For a store in a country neither provider covers, Webflow's documented route is to "use Stripe Atlas to incorporate a U.S. company, open a U.S. bank account, and start accepting payments through Stripe".

Two named geographic cases matter more than the provider list, and both sit in that same document. Merchant accounts in Turkey do not support Webflow's PayPal integration. Separately, "Stripe doesn't support transaction/application fees in Brazil, India, or Malaysia", and Webflow documents two branches for merchants there: the store "must be on an Ecommerce Plus or Advanced site plan", or, as Webflow puts it, "Alternatively, you can use Stripe Atlas to incorporate a U.S. company, open a U.S. bank account, and accept payments through Stripe on an Ecommerce Standard Site plan". For a Brazilian, Indian or Malaysian merchant who does not want to incorporate in the United States, the practical entry price is therefore the $74 Plus tier rather than the $29 Standard tier.

• Stripe and PayPal are the only two supported providers.
• Apple Pay, Google Pay and Microsoft Pay depend on a Stripe connection.
• Turkish merchant accounts cannot use the PayPal integration.
• Brazil, India and Malaysia require Ecommerce Plus or Advanced, unless the merchant incorporates in the United States through Stripe Atlas.
• The PayPal account must be a Business account with a verified email.
• One PayPal account connects to one Webflow Ecommerce site, so a second store needs a second PayPal account.

The rule I apply before quoting any store build is to confirm the merchant's country and provider in the first call, because a provider gap is the one constraint on this list that no amount of build work can close.

Can a Webflow Ecommerce store sell in more than one currency?

A Webflow Ecommerce store has exactly one store currency, chosen before the catalogue exists. Webflow's setup documentation instructs that "You'll need to set the currency of your store before adding products and creating shipping rules", and the chosen currency "will be appended to the price field of your products collection and shipping rates" (Webflow Help Center, Set up your Webflow Ecommerce store, updated 8 October 2025). There is no native presentment currency, no geographic price switching and no per-market price list.

Changing that currency later is the single most expensive reversible mistake in a Webflow store. Webflow documents that "Changing the currency does not change existing price values of products and existing shipping methods", that "all products will be saved as draft", and that "You will need to manually update the price of each product and republish your site". A 300-product catalogue therefore becomes 300 manual price edits plus a shipping reconfiguration, performed while the storefront is unpublished.

One matching requirement sits on the payment side and is easy to miss: Webflow's payment provider troubleshooting expects that the "default currency set in your site's Ecommerce settings matches the default currency used in your PayPal account" (Webflow Help Center, Connect a payment provider). On the projects I lead, store currency is a signed-off decision in the kickoff document, alongside the domain, and the PayPal account currency is confirmed in the same line. If a client sells meaningfully into two currency zones, the honest recommendation is a cart that supports multi-currency natively, because the workaround in Webflow is a second site and a second Site plan.

Does Webflow Ecommerce still support subscriptions?

Webflow Ecommerce subscriptions depended on Webflow User Accounts, and Webflow has sunset User Accounts. Webflow's sunset notice states that "On January 29, 2026, User Accounts functionality will be disabled on all Webflow sites", that after that date "you will not be able to add User Accounts to any new or existing sites, or call Webflow's User Accounts APIs and webhooks", and that "You'll lose access to User Accounts and all User Accounts data, as it will not be migrated to the CMS" (Webflow Help Center, User Accounts sunset, updated 25 February 2026). Webflow's subscriptions documentation ties the feature to that system directly: "The subscriptions element can only be added to the User account page" (Webflow Help Center, Subscriptions, updated 12 December 2024).

The billing consequence is the part store owners miss. Webflow's sunset notice is explicit that existing paid subscriptions live in Stripe and that "subscribers will continue to be charged", and Webflow recommended migrating "to a third party memberships solution before January 29, 2026". A store that did nothing is now charging customers through Stripe with no Webflow-side account page for them to manage, which is a support problem rather than a revenue one, and it does not resolve itself.

Even before the sunset, Webflow's subscription feature carried restrictions worth knowing if you are evaluating the platform for recurring revenue today, and Webflow documents each one in its Subscriptions article. The restrictions explain why so few Webflow stores ran recurring revenue natively even while the feature existed. When a prospective client asks me about recurring billing on Webflow, the first thing I check is whether they already have active subscribers in Stripe, because that determines whether the project is a build or a migration.

• "Discounts can't be applied to subscriptions".
• "subscriptions cannot be bought with other products in the same transaction".
• "Customers can only purchase one of each subscription that you sell".
• "when the subscription renews, no new order is generated", so fulfilment on renewals had to be tracked outside Webflow.
• "Subscriptions count towards your Site plan's Ecommerce item limit".

Which countries does Webflow calculate sales tax for?

Webflow calculates sales tax and VAT automatically for the United States, Canada, the European Union and Australia, and for no other country. Webflow's tax documentation states that "Sales taxes and VAT can be automatically calculated for the United States, Canada, the European Union, and Australia", and that tax-exempt product handling is narrower still, "limited to the US and certain EU countries" (Webflow Help Center, Configure taxes on Ecommerce orders). For an order shipping outside those four regions, the tax has to be handled outside Webflow.

• United States, with tax-exempt product handling available.
• Canada.
• The European Union, with tax-exempt handling in certain member countries.
• Australia.

Webflow does publish the arithmetic it uses for tax-inclusive pricing, which matters for European and Australian stores where the displayed price must include tax: "tax amount = (tax rate * price including tax) / (1 + tax rate)". A store that advertises tax-inclusive prices and then adds tax at checkout is not a configuration quirk, it is a compliance exposure, and Webflow is clear that responsibility for accuracy, filing and payment stays with the merchant.

When I scope a store that ships beyond those four regions, the rule is to treat tax as an integration line item in the quote rather than a setting, because nothing in the Webflow panel will calculate it.

What are the workarounds when Webflow Ecommerce does not fit?

Webflow Ecommerce has three practical workarounds: an external cart embedded on Webflow pages when the item or variant ceiling blocks the catalogue, a third-party memberships or billing tool when the requirement is recurring revenue, and one Webflow site per currency zone when the store must quote in more than one currency. Each one trades Webflow's native checkout for capability. The pattern I build most often keeps Webflow as the front end, where its design and CMS tooling genuinely win, and moves the cart to a platform whose published limits match the catalogue.

What do you do when the variant or item ceiling is the blocker?

A variant or item ceiling is a catalogue-shape problem, so the workaround is a cart built for large catalogues. Embedding an external cart on Webflow pages keeps the design and the CMS-driven content while the product data lives elsewhere, and it removes both the 500-item Standard ceiling and the 50-variant per-product ceiling from the equation. The cost is that Webflow's native product Collections, cart and checkout go unused, so order management moves out of Webflow entirely. My walkthrough of the Webflow and Shopify integration covers that pairing in detail, including how inventory behaves once the cart moves and what running international sales on Webflow actually involves.

What do you do when recurring billing is the blocker?

Recurring billing on Webflow now belongs to a dedicated memberships or billing tool rather than to Webflow. Webflow's own User Accounts sunset notice points site owners at third-party memberships solutions and names Outseta and Memberstack with migration offers, which is an unusually direct admission that the native path is closed. For pure subscription commerce with no physical fulfilment, a Stripe-hosted billing flow linked from a Webflow page is the leanest option, because it keeps the one system that was already holding the subscriptions.

What do you do when multi-currency is the blocker?

Multi-currency is the constraint with the fewest good workarounds inside Webflow. Because store currency is a single site-level setting, the realistic options are a separate Webflow site per currency zone with its own Site plan, or an external cart that handles presentment currency. What I tell clients is that two currency zones usually justify leaving Webflow's native cart, and three almost always do. If a platform switch is on the table, my overview of Webflow alternatives is the better starting point than a workaround.

Which Webflow Ecommerce mistakes cost the most to fix?

Ranked by what they cost to undo, the four mistakes are choosing the wrong store currency at setup, sizing the catalogue by product count instead of variant count, staying on Ecommerce Standard past the fee crossover, and planning recurring revenue on Webflow subscriptions. Each one is a decision taken before launch that becomes costly only after the catalogue is populated or the first customer is billed, and the cost column below uses the same arithmetic on the prices and ceilings from Webflow's pricing page described earlier rather than vendor-published figures.

Failure mode	What it costs	Check before launch
Wrong store currency chosen at setup	Every product reverts to draft and every price is re-entered by hand, so a 300-product catalogue means 300 manual edits plus a shipping rebuild	Confirm the single selling currency in writing before the first product is created
Catalogue sized by product count, not variant count	A Standard store runs out of room at ten products carrying full variant sets, forcing an unplanned tier upgrade or a catalogue cull mid-import	Multiply products by their variants and compare the total against the plan's Ecommerce item ceiling
Staying on Ecommerce Standard past the fee crossover	At $100,000 of annual sales the 2% fee is $2,000 a year against a $540 upgrade to Plus, so the cheaper plan costs about $1,460 more	Compare projected annual gross sales against the $27,000 crossover before renewal
Recurring revenue planned on Webflow subscriptions	Subscribers keep being charged in Stripe with no account page to manage, generating open-ended support load with no native fix	Audit Stripe for active subscriptions and choose a memberships tool before building anything

When is Webflow Ecommerce the wrong choice for a store?

Webflow Ecommerce is the wrong choice when a catalogue breaches any one of the seven limits above, and the breach is almost always visible in the product spreadsheet before the build starts. If you want that checked against your actual catalogue, book a 15-minute call and bring your product count, your variant count and your selling countries. You will leave the call with a plan tier, a yes or no on Webflow's native cart, and a named alternative if the answer is no.