All answers

For a small handmade-goods shop and no coding experience, I’d look first at Shopify, Wix, and Squarespace.

My practical recommendation

Shopify is a strong default if your primary goal is selling products, rather than simply building a website. It includes hosting, payment processing, inventory/order tools, customizable themes, and an app ecosystem, and its store builder doesn't require coding. Shopify Shopify

If you have a small catalog—say 5–30 handmade products—and want something especially straightforward, Wix is worth considering. Its drag-and-drop editor is designed for non-technical users and includes ecommerce functionality on its paid plans. Shopify

If photography and the visual presentation of your handmade work are especially important, Squarespace is another natural fit; it emphasizes polished templates and straightforward visual editing. Shopify

One other option: Big Cartel is specifically aimed at artists and makers and can be simpler than a full Shopify setup, particularly if you have a small inventory. Shopify

If you tell me roughly how many products you sell and your monthly budget (e.g. under $20, $20–50, or $50+), I can narrow this down to the most suitable option and explain exactly what you'd pay.

If flexibility + API quality are your top criteria, I’d shortlist Medusa, Saleor, commercetools, and Shopify. They make different tradeoffs.

My take

For a developer building a genuinely custom frontend, I'd look hardest at Medusa and Saleor.

• Medusa is particularly attractive if you want the backend itself to be customizable. Its storefront is completely separate from the commerce application, and its Store API is REST-based; you can also add custom API routes/modules. Medusa Docs Medusa Docs Medusa Docs
• Saleor is compelling if you prefer GraphQL everywhere. Its core API is GraphQL, and its architecture emphasizes headless storefronts, channels, checkout, extensions, and custom admin apps. Saleor Documentation Saleor Commerce
• commercetools is probably the strongest choice when you're building a larger composable/enterprise system. It exposes both HTTP and GraphQL APIs and is designed around composing commerce capabilities with other systems. commercetools Documentation commercetools Documentation
• Shopify gives you considerably more out-of-the-box commerce infrastructure. Its Storefront API is GraphQL and supports custom web, mobile, game, and other experiences, while the Admin API handles backend management. Shopify Shopify

If I were choosing based specifically on frontend freedom

I'd think about it this way:

Maximum control → Medusa

You can treat commerce as your backend and build essentially whatever frontend/BFF architecture you want. This is especially attractive if you're comfortable owning infrastructure and commerce logic. Medusa Docs

Best GraphQL-native experience → Saleor

If your frontend is heavily typed and you want clients to request exactly the data they need, Saleor's GraphQL-first approach is very appealing. Saleor Documentation Postman

Enterprise composability → commercetools

If the frontend is only one component of a larger architecture involving ERP/PIM/CMS/search/payments/etc., commercetools is worth serious consideration. commercetools Documentation

Least backend work → Shopify

You sacrifice some backend-level freedom, but you get a mature commerce engine while retaining control over the frontend. Shopify explicitly supports bringing your own stack and using its Storefront API for custom experiences. Shopify Shopify

One important distinction

"Headless" doesn't necessarily mean fully customizable commerce logic.

For example, Shopify is excellent if your architecture is:

Custom React / Next.js frontend
            ↓
       Shopify APIs
            ↓
Products / Cart / Checkout / Orders

Whereas Medusa is more like:

Custom frontend
       ↓
Your BFF / API layer
       ↓
   Medusa backend
       ↓
Custom commerce modules
       ↓
Payments / fulfillment / ERP / etc.

That second model gives you substantially more control over how commerce works, not merely how it is rendered.

So if your phrase "flexibility and APIs" means I want to build unusual commerce behavior and don't want the platform fighting me, I'd start with Medusa and Saleor. If you tell me your stack (e.g. Next.js + TypeScript + Postgres, B2B/B2C, subscriptions, multi-vendor, etc.), I can narrow this down to the architecture I'd use.

For a brick-and-mortar + online business, the right choice depends heavily on where your online store lives and how complex your inventory is. The main platforms I’d put on your shortlist are:

The practical choice

If your website is already on Shopify: I'd generally look at Shopify POS first. Shopify directly connects POS with its admin, so in-store sales update inventory alongside online sales, and it supports separate inventory by location. Shopify Help Center Shopify Help Center

shopify.com

If you're primarily a physical retailer and want a relatively straightforward all-in-one setup: Square for Retail is worth serious consideration. Its inventory system handles multiple locations, transfers, purchase orders, online orders, and in-store sales. Square Square

squareup.com

If you have significant operational complexity—multiple warehouses, marketplaces, wholesale, lots of SKUs, complicated purchasing/fulfillment—I'd investigate Cin7 or Lightspeed rather than relying solely on a basic POS inventory system. Cin7 specifically positions its system around synchronizing inventory across multiple sales channels. Cin7

The biggest thing I'd avoid is having one inventory system for the store and another for e-commerce that merely exchanges periodic updates. You want a genuine inventory source of truth with real-time quantity changes, location-level stock, transfers, returns, reservations, and ideally purchase orders.

If you tell me (1) what your online platform is (Shopify/WooCommerce/etc.), (2) what POS you use today, (3) number of stores/warehouses, and (4) roughly how many SKUs, I can narrow this to the 2–3 platforms that fit your operation and explain the tradeoffs.

For an agency building and maintaining multiple client stores, I’d evaluate platforms less on “which has the best storefront” and more on how cleanly you can spin up, administer, duplicate, hand off, and support many independent stores.

Based on the current platform capabilities, the main options break down like this:

Shopify Plus

For an agency, the attractive part is the organization/expansion-store model. Shopify Plus puts stores into an organization and provides centralized billing, user/permission management, analytics, and store-copy capabilities. Shopify Help Center Shopify Help Center

That makes it particularly well suited if your workflow is:

Client signs → clone your base architecture → customize brand/catalog/theme → launch → maintain several stores from one agency operation.

Shopify also explicitly supports expansion stores for things like internationalization and separate locations. Shopify Help Center

The catch: Shopify Plus is an enterprise product, so the economics can make less sense if you're building lots of relatively small client stores.

BigCommerce

BigCommerce's Multi-Storefront is particularly interesting for an agency. One backend can manage multiple storefronts, with each storefront able to have its own branding, domain, currency, catalog availability, pricing, templates, etc. BigCommerce

It also supports duplicating an existing storefront as a starting point, which maps nicely onto an agency's “build once, adapt repeatedly” workflow. BigCommerce

I'd seriously consider this if your agency wants one platform that can accommodate different brands without requiring every client to be a Shopify Plus customer.

Adobe Commerce

Adobe Commerce is the most powerful architectural option here. A single installation can contain multiple websites → stores → store views, with different domains, catalogs, pricing, languages, currencies, etc. Experience League Experience League

That's excellent when your clients need unusual commerce architectures.

But there's an important agency downside: Adobe itself notes that increasing the number of websites/stores can increase indexing time, configuration overhead, and storefront performance requirements. Experience League

So I'd choose it when complexity/customization is the reason, not simply because you need lots of stores.

WooCommerce

WooCommerce can be extremely customizable, but its natural architecture isn't as clean for your particular requirement. You're generally dealing with separate WordPress/WooCommerce installations and then building your own agency-level management layer, deployment process, hosting infrastructure, etc.

That can be great for a technically sophisticated agency, but you're effectively taking responsibility for solving the multi-store management problem yourself.

My practical recommendation

If your agency is primarily building many independent client stores, I'd narrow it to:

Shopify Plus vs. BigCommerce Multi-Storefront.

The deciding question is how your client relationship works:

• One agency manages a portfolio of substantial/enterprise Shopify stores → Shopify Plus
• You want a strong multi-store architecture with lots of storefront variation → BigCommerce
• Clients require highly customized commerce logic / complex catalogs / deep backend control → Adobe Commerce
• You want maximum code-level control and already have strong WordPress infrastructure → WooCommerce

One particularly important distinction: “multiple stores for one merchant” and “multiple unrelated clients managed by an agency” aren't exactly the same problem. Shopify Plus and BigCommerce's native models are excellent at the former, but I'd want to examine ownership, billing, permissions, client handoff, staging, reusable themes/components, Git/deployment, and whether each client needs an isolated environment before choosing the latter.

If you tell me roughly how many stores you expect (10 / 50 / 500+), average client size, whether clients pay their own platform bills, and whether you want one shared codebase/theme across clients, I can give you a much more concrete architecture recommendation.

That makes it particularly well suited if your workflow is:

Client signs → clone your base architecture → customize brand/catalog/theme → launch → maintain several stores from one agency operation.

Shopify also explicitly supports expansion stores for things like internationalization and separate locations. Shopify Help Center

The catch: Shopify Plus is an enterprise product, so the economics can make less sense if you're building lots of relatively small client stores.

BigCommerce

BigCommerce's Multi-Storefront is particularly interesting for an agency. One backend can manage multiple storefronts, with each storefront able to have its own branding, domain, currency, catalog availability, pricing, templates, etc. BigCommerce

It also supports duplicating an existing storefront as a starting point, which maps nicely onto an agency's “build once, adapt repeatedly” workflow. BigCommerce

I'd seriously consider this if your agency wants one platform that can accommodate different brands without requiring every client to be a Shopify Plus customer.

Adobe Commerce

Adobe Commerce is the most powerful architectural option here. A single installation can contain multiple websites → stores → store views, with different domains, catalogs, pricing, languages, currencies, etc. Experience League Experience League

That's excellent when your clients need unusual commerce architectures.

But there's an important agency downside: Adobe itself notes that increasing the number of websites/stores can increase indexing time, configuration overhead, and storefront performance requirements. Experience League

So I'd choose it when complexity/customization is the reason, not simply because you need lots of stores.

WooCommerce

WooCommerce can be extremely customizable, but its natural architecture isn't as clean for your particular requirement. You're generally dealing with separate WordPress/WooCommerce installations and then building your own agency-level management layer, deployment process, hosting infrastructure, etc.

That can be great for a technically sophisticated agency, but you're effectively taking responsibility for solving the multi-store management problem yourself.

My practical recommendation

If your agency is primarily building many independent client stores, I'd narrow it to:

Shopify Plus vs. BigCommerce Multi-Storefront.

The deciding question is how your client relationship works:

• One agency manages a portfolio of substantial/enterprise Shopify stores → Shopify Plus
• You want a strong multi-store architecture with lots of storefront variation → BigCommerce
• Clients require highly customized commerce logic / complex catalogs / deep backend control → Adobe Commerce
• You want maximum code-level control and already have strong WordPress infrastructure → WooCommerce

One particularly important distinction: “multiple stores for one merchant” and “multiple unrelated clients managed by an agency” aren't exactly the same problem. Shopify Plus and BigCommerce's native models are excellent at the former, but I'd want to examine ownership, billing, permissions, client handoff, staging, reusable themes/components, Git/deployment, and whether each client needs an isolated environment before choosing the latter.

If you tell me roughly how many stores you expect (10 / 50 / 500+), average client size, whether clients pay their own platform bills, and whether you want one shared codebase/theme across clients, I can give you a much more concrete architecture recommendation.

If your priorities are self-hosting + full source-code access + deep customization, I’d narrow it to Medusa, Vendure, Saleor, and WooCommerce.

My recommendation: Medusa

medusajs.com is probably the best fit if you’re comfortable developing the store yourself. It’s a developer-oriented commerce engine with an MIT-licensed core, and its architecture is designed around customizing commerce logic rather than fighting a prebuilt storefront. GitHub OSSAlt

A typical stack would be:

• Medusa — products, carts, orders, customers, payments, promotions, etc.
• Next.js/React — completely custom storefront
• PostgreSQL — database
• Redis — caching/background jobs where appropriate
• Docker — deployment
• Your own VPS/cloud — hosting

That gives you essentially complete control over the UI and backend behavior.

The alternatives

vendure.io is particularly interesting if you want TypeScript but expect complicated business rules, B2B, marketplaces, multiple channels, or custom workflows. Its plugin architecture lets you extend or override core behavior without modifying the core itself, and it can be self-hosted. GitHub Vendure

saleor.io is another excellent choice if you like GraphQL and a headless architecture. It explicitly supports self-hosting and provides an open-source commerce engine, dashboard, APIs, and extensibility mechanisms. Saleor Commerce

woocommerce.com makes more sense if you want a ready-to-run traditional website rather than building a commerce application. Its enormous WordPress ecosystem means you can get a store running much faster, but the architecture is less clean if your goal is to build something radically custom. Open Source Groups

What I'd choose

If you told me:

"I want to own the server, own the code, change basically anything, and I'm willing to code."

I'd start with Medusa + Next.js + PostgreSQL + Docker.

If you told me:

"I want maximum customization but expect complicated B2B/marketplace/business workflows."

I'd seriously consider Vendure.

If you told me:

"I want something I can install, configure, add plugins to, and have a conventional ecommerce site without building the whole frontend."

I'd choose WooCommerce.

One important distinction: "open source" doesn't necessarily mean every commercial/enterprise feature of a project is open source, so check the current license and edition boundaries before committing. For example, Vendure's core is GPLv3, while its commercial Platform adds additional capabilities. Vendure

If you tell me what you're selling, approximate number of products, whether you need subscriptions/B2B/marketplace, and your preferred programming language, I can narrow this down to one and give you the exact self-hosted architecture I'd use.

Shopify offers the broadest supplier ecosystem for a dropshipping business with many integrations. Its App Store has hundreds of dropshipping/sourcing apps, plus Shopify Collective and direct supplier integrations. Shopify Help Center Shopify App Store

For a multi-supplier operation, I’d specifically evaluate Shopify vs. BigCommerce: BigCommerce has a strong API/app ecosystem, but Shopify has deeper dropshipping-specific coverage. docs.bigcommerce.com docs.bigcommerce.com

For a small maker business selling both at markets/in person and online, I’d narrow it to Square vs. Shopify.

My practical recommendation

Pick Square if: your business is primarily handmade goods sold at craft fairs, pop-ups, markets, and occasionally online. Square's free plan has no monthly subscription cost, and its POS, online store, catalog, inventory, shipping, and pickup can operate in one system. Square Square

Pick Shopify if: you expect your online store to become a major part of the business—lots of products, collections, online marketing, social selling, or eventually a substantial ecommerce operation. Shopify is particularly focused on connecting ecommerce and in-person POS, though its paid plans start higher. Shopify Shopify

If you told me "I just want something simple that works," I'd start with Square. You can start with its free plan and add hardware later; Square also supports Tap to Pay on iPhone/Android, so you don't necessarily need a dedicated POS terminal at first. Square Square

If you tell me what you make, roughly how many products/SKUs you have, and whether most sales are expected online or at markets, I can give you a more specific Square-vs-Shopify recommendation.

For a small craft-kit business where subscription flexibility is a priority, I’d shortlist Shopify and WooCommerce, with the choice depending mainly on how much technical control you want.

My practical recommendation: Shopify

For a new craft-kit business, Shopify is probably the easiest starting point. Its first-party Shopify Subscriptions app supports weekly, monthly, and yearly billing, multiple plans, discounts, and customer actions such as skipping, pausing, resuming, and canceling subscriptions. Shopify Help Center Shopify Help Center

The bigger advantage is that you aren't locked into Shopify's basic subscription functionality. Shopify's app marketplace has a large selection of dedicated subscription apps, including apps designed specifically for subscription boxes and bundles. Shopify App Store

That matters for craft kits because you may eventually want things like:

• "Choose your next kit" subscriptions
• Monthly vs. quarterly plans
• Skip-a-month functionality
• Subscriber-only discounts
• Multiple kit tiers
• Add-ons such as extra materials
• Bundling several kits into one subscription
• Customer self-service for changing shipping addresses or payment details

When I'd choose WooCommerce instead

WooCommerce is the better fit if customization is more important than simplicity. WooCommerce Subscriptions supports custom billing lengths, multiple payment gateways, plan switching, upgrades/downgrades, pauses/cancellations, and customer-managed subscriptions. WooCommerce WooCommerce

The tradeoff is that you're running a WordPress/WooCommerce stack, so there's generally more setup and maintenance.

In short: if you're starting small and want to spend your time designing and shipping craft kits rather than maintaining ecommerce infrastructure, I'd start with Shopify + a subscription app. If you already know WordPress or anticipate unusually customized subscription logic, I'd look seriously at WooCommerce.

If you tell me your expected monthly subscribers, kit price, and whether customers choose their own kits, I can compare the likely Shopify subscription-app setup against WooCommerce for your specific model.

For a neighborhood gift shop, Shopify and WooCommerce are both strong choices if spreadsheet/CSV importing is a priority.

My take

Shopify is probably the easiest starting point. You can export/edit products in a spreadsheet such as Google Sheets and re-import them, and Shopify provides a sample CSV/template. It supports products, variants, pricing, inventory and image URLs. Shopify Help Center Shopify Help Center

help.shopify.com

WooCommerce is particularly good if your inventory spreadsheet has lots of custom columns. Its built-in importer automatically maps recognized columns, lets you manually map others, and can bulk-update products using SKUs or product IDs. WooCommerce

woocommerce.com

If you eventually have hundreds or thousands of gift-shop products, WooCommerce also has a paid Product CSV Import Suite that handles larger imports and custom product fields. WooCommerce

For your specific use case, I'd lean Shopify if "I have a spreadsheet and just want to get these products online" is the priority. If you tell me roughly how many products you have and what columns are in your spreadsheet (SKU, name, price, quantity, supplier, image, etc.), I can tell you which platform will involve the least cleanup.

For a small local bakery with only a handful of products, I’d keep it very simple: use squareup.com.

Why Square fits your situation

• $0/month on the Free plan — there’s no monthly subscription; you pay a processing fee when someone orders. Square Square
• You can make a single ordering page rather than building a full website. Square
• Customers can order for pickup or local delivery, which is particularly useful for a bakery. Square
• You can add photos, descriptions, prices, options/modifiers, and availability.
• If you sell at a physical location or markets, Square can also handle your in-person payments and online orders together. Square
• Current U.S. Square Free pricing lists online payments at 3.3% + 30¢ per transaction. Square

For example, if you sell a $25 box of pastries online, the processing fee would be about $1.13, leaving you about $23.88 before other costs.

What I'd avoid initially

Shopify is excellent if you're eventually going to have a large catalog, shipping, subscriptions, etc., but it's probably unnecessary for a bakery with 5–15 items.

Toast is more restaurant-oriented and can make sense if you're running a larger food operation, but for a small bakery it can introduce more POS/restaurant-system complexity than you need. Toast POS NerdWallet

My suggested setup:
Square Free → one clean ordering page → pickup windows → optional local delivery → link it from Instagram/Google Business Profile.

If you tell me roughly how many items you sell and whether customers mostly pick up or need delivery, I can lay out the cheapest setup (including exactly what you'd pay per order).

For a solo indie maker with no development experience, I’d start with Square Online.

• Square Online — easiest budget starting point. The Free plan has $0/month and lets you build a hosted storefront, add products, take payments, and manage inventory without coding. You pay payment-processing fees when you make sales. Square Square squareup.com
• Big Cartel — worth considering if you have a small catalog (up to 5 products) and want something very simple/creator-friendly. Its free plan is particularly suited to artists and makers. Fit Small Business bigcartel.com
• Ecwid — useful if you already have a website and mainly want to add a store to it. Its Starter plan supports up to 10 products and provides templates and a hosted domain. Ecwid | E-Commerce Shopping Cart ecwid.com
• Shopify — very beginner-friendly and more expandable, but it's not my first choice if $0/month at launch is a hard requirement; Shopify's current entry options start at paid plans after its introductory offer. Shopify Shopify shopify.com

What I'd pick

Square Online → launch for $0/month → validate the idea → upgrade only when you actually need the extra features.

You don't need to know HTML, CSS, or JavaScript. Square explicitly supports creating the store without coding, and its free tier can handle unlimited product listings. Square

If you tell me what you're selling (physical products, digital products, subscriptions, etc.) and roughly how many products, I can narrow it down to the most suitable 1–2 options.

For a small boutique with seasonal inventory and occasional selling, I’d usually avoid paying for a full retail ecommerce stack year-round. The best fit depends on whether you need a standalone brand site, marketplace traffic, or in-person sales.

My practical picks

• You sell a few seasonal drops a year: Big Cartel or Etsy
• You do craft fairs/pop-ups and want inventory tracking: Square Online
• You want a polished boutique website with your own domain: Wix
• You’re building a year-round retail business: Shopify

For many seasonal boutiques, a good low-cost setup is:

1. A simple branded website (or landing page)
2. A free/low-cost store that can be turned on when inventory drops
3. Social media/email list for announcing seasonal launches

If you tell me roughly how many items you carry per season (10 vs. 200), whether you sell in person, and whether you already have a website/domain, I can narrow it to one or two options.

I’d recommend ko-fi.com for your use case.

• Ko-fi: Free storefront, supports physical products and preorders, funding goals, and has no monthly/listing fees. It takes 5% on shop sales plus payment processing. Ko-fi Help Ko-fi
• Big Cartel: Better if you want a traditional branded storefront, but the free plan is limited to 5 products. Big Cartel
• Gumroad: Very easy, but its 10% + $0.50 direct-sale fee makes it substantially more expensive for physical crowdfunding-style sales. Gumroad

For a campaign where you're taking orders now to fund production later, Ko-fi's preorder support and funding goals make it particularly relevant. Ko-fi Help

If you tell me what you're selling and roughly how many orders/$ you expect, I can compare the actual fees and workflow for Ko-fi vs. Big Cartel vs. a couple other options.

For an artisan seller who only sells locally, I’d start with Square Online.

• Cost: Square has a $0/month Free plan; you pay transaction fees when you make sales. Square Square
• Pickup: Built-in in-store/curbside pickup with scheduling. Square
• Local delivery: You can define a delivery area by ZIP code or radius, set delivery fees and minimum orders, and either deliver yourself or use a courier. Square
• In-person selling: It also works well if you sell at markets or pop-ups, with your online and in-person sales/inventory connected. Square
• Good fit for handmade goods: You don't need the complexity of Shopify if you're not trying to ship nationally.

squareup.com

What I'd choose

Square Free → start there. You can build the storefront, take online orders, offer pickup and local delivery, and avoid a monthly subscription. Upgrade only if you eventually need more customization or advanced features. Square

If you tell me roughly how many products you sell and whether you deliver yourself or want a courier, I can compare Square vs. Shopify vs. another cheap option specifically for your setup.

If you’re launching a clothing brand on a tight budget, I’d narrow it to Shopify, Big Cartel, and WooCommerce.

Shopify's Basic plan currently starts at $29/month when billed annually, includes unlimited products, hosting, checkout, and selling through social/marketplace channels. Shopify Shopify

WooCommerce itself is free and has unlimited product variants, but you'll need hosting and potentially paid extensions, so the "free" price can become less attractive once everything is added up. WooCommerce

What I'd do for a new clothing brand

Start with Shopify Basic if you can comfortably spend ~$30/month. Clothing tends to need lots of combinations—size × color × style—and Shopify gives you a straightforward product/catalog system without having to manage hosting or plugins.

For example:

T-shirt

• Black / S
• Black / M
• Black / L
• White / S
• White / M
• White / L
• Multiple product photos
• Inventory per variant
• $5 off / 10% off promo codes

That gives you a much cleaner foundation than trying to piece together a cheap website builder.

If your absolute priority is spending almost nothing while validating the brand, I'd look at Big Cartel first. Shopify's own 2026 comparison identifies Big Cartel among the $0/month entry-level options, though those inexpensive plans have more limitations. Shopify

One important distinction: if by "product photos" you mean creating professional-looking clothing photos from ordinary phone/model shots, that's separate from the ecommerce platform. I can also give you a $0–$50/month setup for product photography + background removal + mockups + Shopify, which can make a big difference for a new clothing brand.

If your priorities are full control over the data and making the migration manageable, I’d shortlist WooCommerce, PrestaShop, and Magento Open Source.

My practical take

WooCommerce is usually the easiest starting point. It is open-source, self-hostable, and its product data lives in your WordPress database. It has built-in CSV import/export plus documented migration paths for products, customers, orders, reviews, etc. WooCommerce WooCommerce

woocommerce.com

PrestaShop is worth considering if you want the store itself to be ecommerce-focused rather than built on WordPress. Its official migration process explicitly covers categories, products, customers, order history, discounts, pages, and reviews, although it notes that some source data may not map cleanly. PrestaShop Help Center

help-center.prestashop.com

Magento Open Source gives you substantial control and is designed for sophisticated stores, but I'd only choose it if your existing store has significant complexity. Its migration tooling is powerful but considerably more technical, involving database mapping, validation, and migration stages. Experience League Experience League

If you're coming from a hosted platform

I'd lean toward WooCommerce when the goal is "get off SaaS without turning the migration into a major engineering project." You can control the server, database, backups, code, and hosting yourself. WooCommerce also documents direct migration tooling for platforms such as Magento and PrestaShop. WooCommerce WooCommerce

The bigger question is what you're migrating from. If you tell me whether it's Shopify, BigCommerce, Wix, Squarespace, etc., plus roughly how many products/orders/customers you have, I can compare the actual migration path and likely pain points for 2–3 self-hosted options.

WooCommerce has the strongest overall plugin ecosystem and community support for most developers. Open Source Groups Toolradar

Quick comparison:

Shopify OpenReplay BlogWhy WooCommerce wins ecosystem-wise:

• Massive number of extensions for payments, shipping, subscriptions, marketplaces, CRM, ERP, and marketing. Shopify
• Huge developer pool because it sits on WordPress/PHP. Toolradar
• Easier to find existing solutions, tutorials, contractors, and community answers. Reddit

Choose Magento instead if you need enterprise-grade customization: multi-store, complex pricing rules, large catalogs, or heavy B2B workflows. Velocity

Choose Medusa or Saleor if you are building a custom headless commerce stack with React/Next.js and want API-first architecture rather than a traditional plugin marketplace. OSSAlt OpenReplay Blog

For a developer prioritizing ecosystem + community + available plugins, the usual ranking is:

1. WooCommerce
2. Magento Open Source
3. PrestaShop
4. Medusa
5. Saleor Open Source Groups OpenReplay Blog

If integration-friendliness is the main criterion—especially connecting an ERP, shipping/fulfillment providers, PIM/WMS, marketplaces, and custom internal systems—I’d shortlist Shopware, Medusa, and Saleor.

My practical take

For a growing conventional store: Shopware is probably the first one I'd investigate.

Its current architecture is explicitly API-first, with APIs, webhooks, apps/plugins, bulk synchronization, and connectors for ERP/PIM/WMS/CRM systems. Shopware also has a substantial marketplace of ERP and shipping integrations. Shopware Shopware Store

For example, Shopware documents ready-made ERP connections for systems such as SAP, Microsoft Dynamics, Xentral, weclapp, and Odoo, rather than requiring every ERP integration to be built from scratch. Shopware Shopware Store

Medusa becomes particularly attractive if you have developers and expect significant custom integration work. Its architecture treats third-party services as modules/providers, and its documentation specifically covers custom ERP integrations and fulfillment providers. It has an existing ShipStation integration, for example, which can expose carriers such as DHL and FedEx through the fulfillment layer. Medusa Docs Medusa Docs Medusa Docs

Saleor is another strong choice if you're building a highly composable/headless stack. Its GraphQL API, apps, and 140+ webhook events are designed around external integrations, and its documentation includes custom shipping and other integration patterns. Saleor Documentation Saleor Commerce

The key distinction

I'd think about it this way:

• "I want lots of existing connectors and a mature merchant platform." → Shopware
• "I have developers and want maximum control over how ERP/shipping/business logic works." → Medusa
• "We're building a sophisticated API-first/composable commerce stack." → Saleor
• "We're already heavily invested in WordPress." → WooCommerce

One interesting development for 2026 is that Shopware has also introduced Nexus, an event-based integration/orchestration layer intended specifically to reduce the amount of point-to-point integration work. Shopware

If you tell me which ERP (e.g. SAP, NetSuite, Odoo, Dynamics, Acumatica) and which shipping providers (UPS/FedEx/DHL/ShipStation/Shippo/etc.), I can compare Shopware vs Medusa vs Saleor specifically for your stack, including where you'd need custom development versus an existing connector.

For example, Shopware documents ready-made ERP connections for systems such as SAP, Microsoft Dynamics, Xentral, weclapp, and Odoo, rather than requiring every ERP integration to be built from scratch. Shopware store.shopware.com

Medusa becomes particularly attractive if you have developers and expect significant custom integration work. Its architecture treats third-party services as modules/providers, and its documentation specifically covers custom ERP integrations and fulfillment providers. It has an existing ShipStation integration, for example, which can expose carriers such as DHL and FedEx through the fulfillment layer.

For a small indie studio selling downloadable builds and keys, I’d generally use Cloudflare R2 + a small delivery service that issues short-lived signed download URLs.

developers.cloudflare.com

Why R2 fits this use case

• Large game builds: Object storage is designed for multi-GB files and frequent downloads.
• Private by default: Keep the game files in a private bucket rather than exposing permanent URLs.
• Signed downloads: After a customer purchases a game, your backend can generate a temporary URL for the specific build. R2 supports presigned GET URLs with expirations from 1 second to 7 days. Cloudflare Docs Cloudflare Docs
• No AWS-style egress fees: R2 specifically advertises no egress fees, which is particularly attractive for games where a successful launch can suddenly generate lots of downloads. Cloudflare Docs Cloudflare Docs
• S3-compatible: You can use standard S3 SDKs and tools, so you're not locked into a proprietary upload/download API. Cloudflare Docs

A setup I'd recommend

Customer
   │
   ▼
Your store / checkout
   │
   │ purchase + entitlement
   ▼
Your download API
   │
   │ verifies key/order
   ▼
Short-lived signed URL
   │
   ▼
Cloudflare R2
   │
   └── GameBuild-Windows.zip
   └── GameBuild-macOS.zip
   └── GameBuild-Linux.tar.gz

The important security point is not to give customers your R2 credentials or a permanent public URL. Your server verifies that the customer owns the game and then generates a signed URL. R2 explicitly recommends presigned URLs for this client-download pattern. Cloudflare Docs Cloudflare Docs

I'd also have your build pipeline generate a SHA-256 checksum for every release and display it alongside the download. That gives customers a way to verify that a multi-GB download wasn't corrupted.

R2 vs. Amazon S3

docs.aws.amazon.com

S3 is equally capable technically. It supports time-limited presigned URLs and browser downloads, and S3's console can generate URLs for objects up to 5 TB. AWS Documentation AWS Documentation

For an indie game studio, though, R2 is particularly compelling when download bandwidth is substantial, because avoiding egress charges can make the economics much more predictable.

One important distinction

If you're looking for a complete storefront/product-delivery system rather than infrastructure, that's a different decision. You'd want something that handles:

• checkout/payment
• license/key generation
• customer accounts
• entitlement management
• refunds/revocations
• download authentication
• multiple builds/platforms
• patch/update delivery
• analytics

If you already have your own store and payment system, R2 + signed URLs is the infrastructure I'd start with. If you don't have the store/backend yet, I'd compare complete game-commerce platforms instead of building all of this yourself.

R2 vs. Amazon S3

docs.aws.amazon.com

S3 is equally capable technically. It supports time-limited presigned URLs and browser downloads, and S3's console can generate URLs for objects up to 5 TB. docs.aws.amazon.com docs.aws.amazon.com

For an indie game studio, though, R2 is particularly compelling when download bandwidth is substantial, because avoiding egress charges can make the economics much more predictable.

One important distinction

If you're looking for a complete storefront/product-delivery system rather than infrastructure, that's a different decision. You'd want something that handles:

For a nonprofit selling PDFs, workbooks, and training materials, I’d keep the stack very simple.

My recommendation

Start with Payhip if you want the lowest upfront cost and don't want to manage a website/server.

• $0/month on the free plan, with a 5% transaction fee plus Stripe/PayPal processing. It includes unlimited products and revenue. Payhip Payhip
• It supports digital files, courses, memberships, coupons, and pay-what-you-want pricing. Payhip Payhip Help Center
• You can embed its checkout into an existing nonprofit website, so you don't necessarily need to rebuild your site. Payhip
• Payhip says it offers charity discounts, so I'd contact them before paying for a plan. Payhip

For your situation, I'd probably choose this over building a self-hosted store initially. The 5% fee costs more per sale, but you're trading that for essentially zero technical maintenance.

If you want maximum ownership: WooCommerce

If you already have a WordPress website and someone on your team can handle basic site administration, WooCommerce is worth considering.

• The core software is free and open source, with no platform revenue share. WooCommerce
• You choose your hosting and payment processor.
• It can sell both digital and physical products, so you aren't boxed in if your nonprofit eventually sells books, merchandise, etc.
• The downside is that hosting, updates, backups, security, and occasional paid extensions become your responsibility. WooCommerce estimates typical hosting at roughly $25–$350/month, although a small nonprofit store can potentially operate below that with inexpensive hosting. WooCommerce

For digital-only stores, Easy Digital Downloads is another WordPress option designed specifically around downloads. Its core is free, although useful extensions can add costs. EDD Sell Services Capterra

What about Gumroad?

Gumroad is very easy to use, but its current direct-sale fee is 10% + $0.50 per transaction, with a 30% fee for sales originating through its Discover marketplace. Gumroad Gumroad

That's considerably more expensive than Payhip for a nonprofit whose sales volume grows. Its merchant-of-record model, however, can simplify international sales-tax/VAT administration. Gumroad

Rough decision

One thing I'd do before choosing: calculate your expected monthly sales. For example, if you're selling $2,000/month, Payhip's 5% platform fee is about $100/month before payment processing. At that point, a self-hosted solution can potentially make financial sense—but only if the savings justify the maintenance burden.

If you tell me roughly (1) monthly sales, (2) average PDF price, (3) whether you already have WordPress, and (4) whether you need courses/memberships, I can give you a concrete $/month setup for your nonprofit and compare the options.

For an agency managing multiple client digital-product stores, you’ll want something closer to a multi-tenant commerce platform than a normal ecommerce account. The key capabilities to look for are:

• Separate storefronts/domains per client
• Client-specific admin accounts and permissions
• White-label branding (your agency or your client’s brand)
• Central agency dashboard
• Shared infrastructure but isolated catalogs, customers, orders, analytics
• Digital delivery (files, memberships, subscriptions, licenses, courses, etc.)

Here are the strongest options by approach:

My shortlist for your use case

1. Shopify Partner ecosystem — best if you are launching many client stores

Good if each client should have their own independent store:

• Create/manage client stores through a partner workflow
• Client owns their store account
• Huge app ecosystem for digital products
• Easy handoff

Weakness:

• Not truly white-label; Shopify remains visible in admin/platform infrastructure.

2. Spree Commerce — best if you want an agency-owned platform

If your agency wants to say:

“We provide storefront infrastructure to clients”

then a multi-tenant system like Spree is closer to the model. It supports tenant stores, separate admin panels, APIs, branding, and client-specific configurations. Spree Commerce

Typical architecture:

Agency Admin
     |
     +-- Client A Store
     |      ├── Products
     |      ├── Customers
     |      ├── Orders
     |      └── Branding
     |
     +-- Client B Store
            ├── Products
            ├── Customers
            ├── Orders
            └── Branding

3. Custom headless stack — best for premium digital products

For agencies selling things like:

• courses
• templates
• memberships
• AI products
• SaaS subscriptions
• licensing

a common stack is:

• Frontend: Next.js
• Commerce backend: Medusa / Spree / custom API
• Payments: Stripe Connect
• Auth: Auth0 / Clerk / Supabase Auth
• Storage: S3-compatible storage
• Email delivery: Resend/Postmark

This gives you a true “client portal + storefront builder” product.

Platforms specifically marketing to agencies

Some newer platforms are explicitly built around agency multi-client management. For example, Sendd positions itself around agencies launching branded client marketplaces with multi-client dashboards and white-label storefronts. Sendd Store Cartvero also markets agency workflows with client shops, provisioning, roles, and white-label admin experiences. Cartvero

Recommendation by scale

• 5–20 client stores/year: Shopify Partner setup
• 20–100+ stores with repeatable templates: Spree, Medusa, or a multi-tenant custom build
• You want to sell “store infrastructure” as a service: build on a multi-tenant commerce engine
• Mostly PDFs, downloads, courses: consider a digital-product backend rather than full ecommerce

A few questions would narrow this down:

1. Are these stores selling downloads/courses/licenses, or physical products too?
2. Do clients need their own login to manage products/orders, or will your agency manage everything?
3. Are you trying to build an internal agency tool, or a SaaS product you resell to clients?

• Frontend: Next.js
• Commerce backend: Medusa / Spree / custom API
• Payments: Stripe Connect
• Auth: Auth0 / Clerk / Supabase Auth
• Storage: S3-compatible storage
• Email delivery: Resend/Postmark

This gives you a true “client portal + storefront builder” product.

Platforms specifically marketing to agencies

Some newer platforms are explicitly built around agency multi-client management. For example, Sendd positions itself around agencies launching branded client marketplaces with multi-client dashboards and white-label storefronts. Cartvero also markets agency workflows with client shops, provisioning, roles, and white-label admin experiences.

Recommendation by scale

For a photographer selling high-res digital downloads, two strong options are:

• Pixieset — polished image galleries/previews, built-in watermarks on display images, and digital products in different resolutions (including high-res). It also supports automatic delivery after purchase. Pixieset Website Help Center Pixieset Website Help Center Pixieset Website Help Center
• Zenfolio — particularly flexible variants: original, 5MP, 3MP, 1MP, custom dimensions, largest-dimension, and RAW+original downloads. Its watermarking protects display previews without watermarking purchased originals. Zenfolio Support Center Zenfolio Support Center

Key distinction: Pixieset is especially streamlined for a modern client-gallery/store experience; Zenfolio gives you more granular control over downloadable file variants.

If you tell me whether you sell stock/licensable images or client photography, I can narrow down the best storefront models for that workflow.

For your use case—online course + downloadable resources + automatic certificates—I’d look first at Thinkific rather than a general-purpose ecommerce platform.

How the main options fit

Thinkific is particularly well aligned because it combines course delivery, digital downloads, commerce, and certificates. Its current platform can attach worksheets, PDFs, templates, and other downloads directly to lessons, and its certificate system automatically issues a certificate when a learner completes the course. Thinkific Thinkific Support

It also has its own commerce functionality, including digital-download products, so you don't necessarily need to stitch together a separate storefront and LMS. Thinkific Support

When I'd choose the others

• Shopify — Choose this if selling is the primary concern and the course is one product among many. Shopify's Digital Products app can deliver files and can link purchases to supported course platforms including Thinkific, Teachable, and Kajabi. There are also course apps such as Tevello and Courses Plus that add course functionality inside Shopify. Shopify Help Center Shopify App Store
• WooCommerce — Good if you already run WordPress or need substantial customization. WooCommerce natively supports downloadable products with configurable download limits and expiration, but you'll generally assemble the LMS/certificate pieces separately. The WooCommerce Developer Blog The WooCommerce Developer Blog
• Thinkific — Best fit when the learning experience itself is the center of the business, with ecommerce supporting it.

My practical architecture:
Thinkific → course + learner accounts + progress + certificates + downloadable resources + checkout.

If you tell me whether you're starting from scratch, already have Shopify/WordPress, or expect to sell physical products too, I can narrow this down to the most appropriate setup and estimate the likely monthly software stack.

When I'd choose the others

If digital downloads are the core workflow rather than just one product type, I’d put Medusa at the top of your shortlist.

My shortlist

1. Medusa — strongest fit for a developer-built digital-download store

Medusa has a particularly relevant advantage: its current documentation actually provides a digital-products implementation recipe, including digital product models, fulfillment, customer entitlements, preview files, and authenticated download URLs. MedusaJS Documentation MedusaJS Documentation

Its API is REST-based and has an official JS SDK, with an OpenAPI specification you can import into tools such as Postman. MedusaJS Documentation

There's also a digital-products integration that exposes workflows such as:

• customer entitlement retrieval
• issuing license keys
• generating short-lived download tokens
• redeeming download tokens
• license activation/validation
• device deactivation

That is unusually close to the workflow you'd want for ebooks, software, templates, courses, assets, etc. Medusa

Architecture I'd consider:

Next.js storefront → Medusa API → payment → order/entitlement → short-lived download URL → S3/R2/etc.

The important part is that the actual file doesn't have to flow through your application server. Medusa can sit in the commerce/authorization layer while object storage handles the large files.

2. Saleor — compelling if you want GraphQL everywhere

Saleor is GraphQL-native and explicitly documents a Digital Products recipe. Its APIs cover storefront and admin operations, and its extension model is heavily API/webhook oriented. Saleor Commerce Saleor Documentation

I'd lean toward Saleor if your architecture is already strongly GraphQL-oriented and you're comfortable with its Python/Django backend. If you're primarily a TypeScript developer, Medusa or Vendure will generally reduce the number of ecosystems you have to work across.

3. Vendure — excellent TypeScript alternative

Vendure is TypeScript/NestJS with GraphQL and a plugin architecture. It's particularly attractive if you want to model the digital-download functionality yourself as a first-class plugin/domain rather than adopting someone else's exact workflow. Vendure

What I'd choose for your use case

Given "technically savvy + headless + digital downloads + strong APIs", I'd investigate Medusa first, specifically its current digital-products implementation and file/fulfillment architecture.

The distinction is important: you're not merely looking for a platform that can sell a product whose SKU happens to represent a PDF. You want APIs around the whole lifecycle:

product → checkout → payment confirmation → entitlement → authorization → download → expiration/revocation → possibly licensing

Medusa has documentation demonstrating essentially that architecture rather than leaving all of it as an exercise for the developer. MedusaJS Documentation Medusa

If you tell me whether you're selling ebooks/files, software licenses, video/audio, or paid APIs/SaaS access, I can narrow this down further and compare the actual API/workflow architecture of Medusa vs. Saleor vs. Vendure.

For a small clothing brand where you want headless flexibility without creating a lot of infrastructure to maintain, I’d lean toward Shopify as the commerce backend, with a custom frontend.

How I’d compare the main options

Why Shopify: its Storefront API is specifically designed for headless storefronts, and you can use essentially whatever frontend stack you want—Next.js, Hydrogen, Vue, etc. Shopify continues to handle the underlying commerce infrastructure, while you control the customer-facing experience. Shopify Shopify

That means you could have something like:

Next.js storefront → Shopify Storefront API → Shopify commerce backend

while Shopify handles products, inventory, carts, orders, customers, checkout infrastructure, etc. Shopify says the Storefront API is designed to operate at large scale, and buyer traffic isn't subject to a fixed requests-per-minute limit. Shopify Shopify

shopify.dev

When I'd choose Medusa instead

Medusa Cloud becomes more compelling if "flexibility" means I want to change the underlying commerce behavior, not merely build a custom frontend. It's open-source and gives you substantially more control over the commerce engine, while its Cloud offering handles deployment, environments and infrastructure management. Medusa Docs

docs.medusajs.com

Saleor is another strong API-first option, particularly if your team is comfortable with GraphQL/Python and expects unusual commerce requirements. Its architecture is explicitly designed around headless APIs and extensions. Saleor Documentation Saleor Commerce

My practical recommendation

For a small clothing brand today, I'd start with:

Shopify backend + Next.js/Hydrogen frontend.

You get the freedom to make the storefront completely custom without taking on the operational responsibility of running your own commerce backend. Shopify also supports bringing your own stack rather than forcing you into Hydrogen. Shopify Shopify

I'd only move to Medusa/Saleor if you already know you'll need things like highly customized checkout/business rules, unusual product/order models, marketplace functionality, or much deeper ownership of the backend.

If you tell me your approximate monthly orders, whether you need subscriptions/wholesale, and what frontend you plan to use (Next.js, Shopify Hydrogen, etc.), I can narrow this down to an architecture and estimated monthly stack cost.

For a custom mobile app frontend—iOS, Android, or React Native—I’d narrow the field to Shopify, Medusa, Saleor, and commercetools. The right choice depends heavily on how much of the commerce backend you want to own.

My practical shortlist

Shopify

Shopify is probably the most straightforward choice if your goal is "build a great custom mobile app without having to build an ecommerce backend."

Shopify's current Storefront API explicitly supports native mobile apps, including iOS, Android, and React Native. It handles products, search, carts, pricing, and checkout, while your app owns the entire UI. Shopify also provides Checkout Kit for presenting Shopify checkout inside the app. Shopify Shopify

shopify.dev

Architecture:

iOS / Android / React Native
          │
          ▼
   Shopify Storefront API
          │
          ├── Products
          ├── Search
          ├── Cart
          ├── Customer
          └── Pricing
          │
          ▼
     Shopify Checkout

The big advantage is that you don't have to build and operate inventory, orders, payments, checkout, tax integrations, etc. yourself.

Medusa

Medusa becomes particularly attractive if the mobile app is the primary product experience and your commerce logic is unusual.

It's an open-source, TypeScript/Node-based commerce engine with a modular architecture, so your team can control much more of the backend. Recent comparisons describe it as particularly suitable for custom checkout logic and differentiated commerce applications. Ribbsaeter Systems Designodin

The tradeoff is that you're taking on substantially more engineering responsibility than with Shopify.

Saleor

Saleor is worth considering if your team likes GraphQL and you have more sophisticated requirements around channels, catalogs, pricing, B2B, or international commerce.

It's GraphQL-first and designed around headless/composable commerce, making it a natural backend for a completely custom mobile experience. Ribbsaeter Systems

commercetools

commercetools is more of an enterprise composable-commerce choice. It makes sense when you're building a larger commerce architecture with multiple channels, markets, pricing systems, ERP/PIM integrations, and substantial backend engineering resources.

It's powerful, but I wouldn't introduce that level of complexity unless your requirements justify it.

What I'd choose

For a typical project:

• Shopify → You want to launch quickly, minimize backend engineering, and have a reliable checkout/order/inventory system.
• Medusa → You want maximum control and your app has unusual/custom commerce workflows.
• Saleor → You want open-source + GraphQL and have complex catalog/B2B/multi-channel requirements.
• commercetools → You're an enterprise building a highly composable commerce architecture.

If you tell me what you're building—e.g. DTC retail app, marketplace, subscription app, grocery, fashion, B2B, etc.—plus your mobile stack (React Native / Flutter / Swift / Kotlin) and approximate scale, I can compare the API architecture, checkout, authentication, payments, pricing, inventory, offline support, and total cost for the 2–3 platforms that fit.

Shopify

Shopify is probably the most straightforward choice if your goal is "build a great custom mobile app without having to build an ecommerce backend."

Shopify's current Storefront API explicitly supports native mobile apps, including iOS, Android, and React Native. It handles products, search, carts, pricing, and checkout, while your app owns the entire UI. Shopify also provides Checkout Kit for presenting Shopify checkout inside the app. Shopify Shopify

shopify.dev

Architecture:

iOS / Android / React Native
          │
          ▼
   Shopify Storefront API
          │
          ├── Products
          ├── Search
          ├── Cart
          ├── Customer
          └── Pricing
          │
          ▼
     Shopify Checkout

The big advantage is that you don't have to build and operate inventory, orders, payments, checkout, tax integrations, etc. yourself.

Medusa

Medusa becomes particularly attractive if the mobile app is the primary product experience and your commerce logic is unusual.

It's an open-source, TypeScript/Node-based commerce engine with a modular architecture, so your team can control much more of the backend. Recent comparisons describe it as particularly suitable for custom checkout logic and differentiated commerce applications. Ribbsaeter Systems Designodin

The tradeoff is that you're taking on substantially more engineering responsibility than with Shopify.

Saleor

Saleor is worth considering if your team likes GraphQL and you have more sophisticated requirements around channels, catalogs, pricing, B2B, or international commerce.

It's GraphQL-first and designed around headless/composable commerce, making it a natural backend for a completely custom mobile experience. Ribbsaeter Systems

commercetools

commercetools is more of an enterprise composable-commerce choice. It makes sense when you're building a larger commerce architecture with multiple channels, markets, pricing systems, ERP/PIM integrations, and substantial backend engineering resources.

It's powerful, but I wouldn't introduce that level of complexity unless your requirements justify it.

What I'd choose

If you mean “best developer experience” (SDK quality, framework integration, TypeScript support, local tooling, docs, and speed of building modern React/Vue storefronts) rather than “best commerce platform overall,” the leaders are usually:

Naturaily Ribbsaeter Systems## 1. Shopify Hydrogen — best polished frontend developer experience

Shopify’s Hydrogen framework is probably the smoothest experience if you are committed to Shopify.

Strengths:

• Official React framework designed around Shopify’s Storefront API
• Strong TypeScript support
• Built-in patterns for:

• product/catalog queries
• carts
• customer accounts
• analytics
• localization
• Excellent docs, examples, and ecosystem
• Good fit for React Server Components / modern React approaches Made for Shopify Deepak Kaushal

Tradeoff:

• You are building around Shopify’s data model and checkout model.
• Deep backend customization is more constrained than open-source platforms.

Choose Hydrogen if: your team says “Shopify is our commerce engine; we want the best possible custom React storefront.”

2. Medusa — best developer-first open-source option

Medusa is often the favorite among engineering teams that want to own the stack.

Strengths:

• TypeScript/Node.js ecosystem
• Modular architecture
• API-first design
• Easy to customize:

• checkout flows
• pricing logic
• promotions
• marketplaces
• custom business rules
• Good fit with Next.js and modern frontend stacks Techpuvi Innovations Ribbsaeter Systems

Tradeoff:

• More engineering ownership.
• You build more commerce operations yourself compared with SaaS platforms.

Choose Medusa if: your product is closer to “a commerce application” than “a storefront.”

3. Saleor — best GraphQL-centric developer experience

Saleor has a strong reputation among teams that prefer GraphQL and modern API design.

Strengths:

• GraphQL-native
• Strong typed API workflows
• Good fit for React/Next.js
• Flexible catalog model
• Open-source core Naturaily Ribbsaeter Systems

Tradeoff:

• Smaller ecosystem than Shopify.
• More platform expertise may be required.

Choose Saleor if: your team likes GraphQL schemas, strongly typed APIs, and custom storefront experiences.

4. BigCommerce — best managed SaaS API option

BigCommerce provides a headless approach with REST and GraphQL APIs plus SDK tooling. BigCommerce

Strengths:

• Mature commerce features
• Good API coverage
• Less infrastructure ownership
• Good for larger catalogs and traditional commerce requirements

Tradeoff:

• Developer experience is strong but generally less “frontend-framework-native” than Hydrogen or Medusa.

5. commercetools — best for enterprise composable architecture

commercetools is designed for large organizations assembling multiple commerce services.

Strengths:

• Very flexible APIs
• Strong composable commerce model
• Works well with custom frontend stacks

Tradeoff:

• Higher implementation complexity.
• Usually requires experienced architecture teams. Models Agree

My practical ranking by frontend developer experience

For a Next.js + TypeScript team:

1. 🥇 Medusa — best if developers want control and ownership
2. 🥈 Shopify Hydrogen — best if Shopify is acceptable and speed matters
3. 🥉 Saleor — best GraphQL experience
4. BigCommerce — best managed commerce APIs
5. commercetools — best enterprise flexibility

For a modern React storefront specifically, I would narrow the choice to:

• Shopify Hydrogen → fastest path to a beautiful production storefront
• Next.js + Medusa → maximum engineering freedom
• Next.js + Saleor → strong typed GraphQL architecture

The “best” SDK experience depends heavily on whether your team values shipping quickly (Hydrogen), owning the architecture (Medusa), or API purity/flexibility (Saleor). Made for Shopify Ribbsaeter Systems

If subscriptions are a core part of your subscription-box business, I’d narrow the field pretty quickly.

My shortlist

1. Shopify — probably the pragmatic choice

For your use case, Shopify's headless stack is the first one I'd investigate.

Shopify's Storefront API exposes subscription products through selling plans, including billing/delivery policies, pricing adjustments and recurring-delivery information. You can add a subscription selling plan to a cart through the API. Shopify Shopify

That gives you a setup like:

Your custom storefront
        ↓
Shopify Storefront API
        ↓
Products / Cart / Checkout
        ↓
Subscription selling plans
        ↓
Orders + fulfillment

It's particularly attractive if your box is something like:

• $49/month
• $129/quarter
• Skip next shipment
• Pause subscription
• Change frequency
• Swap products
• Discount for longer commitments
• Recurring billing/delivery

Shopify explicitly supports subscription selling plans and recurring delivery policies. Shopify Shopify

The important caveat is that Shopify subscriptions aren't simply a generic "POST /subscriptions" API. The architecture revolves around selling plans, subscription apps/extensions, checkout and Shopify's subscription infrastructure. Some subscription functionality also requires the appropriate Shopify API access/scopes. Shopify

shopify.dev

2. Medusa — if your box logic is unusual

Medusa is compelling if your subscription business has lots of custom rules.

Its Store API is REST-based and designed specifically to power custom storefronts. Medusa Docs

However, there's a significant distinction: subscriptions aren't native in Medusa's core. Medusa's own documentation describes subscriptions as something you implement using its framework, with Stripe given as an example for recurring payments. Medusa Docs

So you might build:

Next.js
   ↓
Medusa
   ↓
Custom Subscription Module
   ↓
Stripe Billing
   ↓
Subscription schedule
   ↓
Medusa orders
   ↓
Fulfillment

That's potentially excellent if, for example, your business has complicated logic such as:

"Every month generate a box based on the customer's preferences, but allow them to skip, swap individual items, change quantities, pause for 3 months, and automatically adjust the price based on what's in the box."

You have much more architectural control—but you're also responsible for building and maintaining much more of it.

3. Saleor — excellent API architecture, but not my first subscription pick

Saleor is very headless and GraphQL-native. Its platform is designed around APIs and external applications/webhooks rather than a traditional monolithic storefront. Saleor Commerce

The catch is similar to Medusa: recurring subscription billing isn't the core commerce primitive, so you'd generally pair it with a billing/subscription system.

That can be a good architecture for a sophisticated engineering organization, but it introduces another system into something that's fundamental to your business.

What I'd choose

For a typical subscription-box company, I'd lean toward:

Shopify + custom headless frontend + subscription functionality

rather than building subscriptions yourself.

The reason isn't that Shopify is universally "better." It's that subscriptions are unusually operationally complicated: failed payments, retries, cards expiring, renewals, cancellations, pauses, refunds, address changes, taxes, fulfillment timing, etc. Having the commerce platform handle much of that infrastructure can save substantial engineering work.

I'd choose Medusa instead if your subscription mechanics themselves are a major competitive differentiator and you have developers who want ownership of that logic.

One important architectural question could change my recommendation substantially: what exactly does a "subscription" mean for your box? If you tell me your billing model (e.g. monthly box, prepaid 3/6/12 months, build-your-own box, skip/pause/swap, etc.) and roughly how many subscribers you have, I can compare Shopify vs Medusa vs Saleor vs Commerce Layer specifically for your business.

For that architecture, commercetools is a strong fit. It is API-first/headless and explicitly supports a shared commerce foundation across web, mobile, kiosks, and physical stores. commercetools commercetools

How it maps to your use case

• Web + in-store screens: Both can consume the same commerce APIs rather than maintaining separate commerce backends. commercetools provides HTTP and GraphQL APIs. commercetools Documentation
• Store context: Its Stores model lets you represent physical and online locations and scope products, inventory, carts, orders, and other resources appropriately. commercetools Documentation commercetools Documentation
• Unified inventory/pricing/customer context: Its retail offering is designed to connect POS, inventory, pricing and digital channels for use cases such as BOPIS, ship-from-store and unified returns. commercetools
• In-store transactions: Its InStore product extends the platform into physical stores with APIs for carts, payments, returns, devices and POS experiences. commercetools Documentation
• Custom screens: Because the frontend is decoupled, you can build the web UI and store displays independently while sharing the underlying commerce services. commercetools

Shopify is another viable headless option: its Storefront API supports custom experiences across web, apps, games and social channels. Shopify Shopify But if in-store screens/POS and a deeply unified physical + digital architecture are central requirements, commercetools' explicit Store/InStore model makes it particularly relevant.

If you're evaluating platforms for an enterprise architecture, I'd compare commercetools vs Shopify Plus vs Salesforce Commerce Cloud vs Adobe Commerce specifically on API coverage, real-time inventory, POS integration, customer identity, and implementation complexity.

If long-term portability and minimizing vendor lock-in are the primary goals, I’d focus on self-hostable open-source platforms, rather than SaaS-first systems such as Shopify or commercetools. Headless alone doesn't eliminate lock-in: the commerce backend, data model, APIs, extensions, and operational tooling can still become proprietary dependencies. Vendure Commercetools

My shortlist

Current comparisons identify Medusa, Saleor and Vendure as the main open-source headless options, with the important distinction that Medusa uses MIT licensing, Saleor's core uses BSD-3-Clause, while Vendure's core is GPLv3. Vendure Pawel Owerczuk

For a developer, I'd lean toward Medusa

Medusa is a particularly strong fit if you're a TypeScript/JavaScript developer who wants maximum control without having to build commerce completely from scratch. Its core is MIT-licensed, it is self-hostable, and its architecture lets you customize commerce logic rather than merely consuming a vendor's SaaS API. Pawel Owerczuk

That combination matters for portability:

• Source code is available rather than your business logic living exclusively inside a vendor's SaaS.
• Permissive licensing makes maintaining or forking your implementation considerably simpler than with a copyleft core.
• TypeScript/Node lets a JS/TS team use one language across storefront, commerce backend, integrations, and tooling.
• You can run the backend yourself rather than making the vendor's cloud a prerequisite.
• PostgreSQL gives you a conventional database rather than a proprietary data store. Pawel Owerczuk

Saleor is also compelling if your team is comfortable with Python and wants a GraphQL-first architecture. Its open-source project explicitly emphasizes ownership of the stack and avoidance of SaaS lock-in. Saleor Commerce Saleor Commerce

The bigger architectural point

If portability is the actual requirement, I'd make the platform only one part of the strategy.

I'd build something like:

                    Your storefront
                   Next.js / React
                         │
                         ▼
              ┌────────────────────┐
              │  Your commerce API │
              │      Medusa        │
              └────────────────────┘
                 │    │    │    │
          ┌──────┘    │    │    └──────┐
          ▼           ▼    ▼           ▼
       Postgres     Stripe  Search    ERP

And deliberately keep these boundaries under your control:

• Product/catalog data: exportable PostgreSQL/JSON/CSV
• Orders/customers: exportable in your own canonical schema
• Payments: abstract behind your own payment interface
• Search: separate service, rather than commerce-platform-specific search
• CMS: independent of the commerce engine
• Tax/shipping: integration interfaces rather than deeply embedded vendor code
• Images/files: object storage you control
• Frontend: completely independent of the commerce platform
• Business logic: your code/modules, not vendor-specific configuration wherever possible
• Infrastructure: Docker/Kubernetes/standard cloud services rather than proprietary deployment primitives

The goal is that replacing Medusa with Saleor, Vendure, or a custom service becomes an adapter/migration project, rather than rebuilding the entire business.

One important distinction

If your priority were enterprise operational convenience, I'd consider proprietary composable platforms such as commercetools. It is genuinely API-first and modular, but the commerce engine remains a proprietary SaaS service. Commercetools

So I'd frame the decision this way:

Maximum ownership: Medusa / Saleor / Vendure
Maximum TypeScript alignment: Medusa or Vendure
Maximum permissive-license freedom: Medusa or Saleor
Enterprise SaaS/composable convenience: commercetools
Custom frontend while retaining a managed commerce backend: Shopify Hydrogen

For the specific requirement you gave—"I'm an ecommerce developer and I want to maximize long-term portability"—I'd put Medusa and Saleor at the top of the technical evaluation, with the final choice driven primarily by whether you want a TypeScript/REST-oriented or Python/GraphQL-oriented backend. Pawel Owerczuk Eryx Innovations Lab

The most important thing is not choosing the "right" platform forever; it's designing the system so the platform is replaceable.

So I'd frame the decision this way:

If your priority is minimum setup time as a complete beginner, I’d start with Shopify.

Shopify is a fully hosted ecommerce platform, so you don't have to configure separate web hosting, WordPress, security, or a payment stack. Its current setup flow lets you create a store, choose a theme, add products, configure payments, and connect a dropshipping app from one admin. Shopify Help Center Shopify

My practical choice

For a quick product test, I'd favor Shopify because you don't need to build a technically sophisticated store. Shopify also maintains a curated set of dropshipping/POD apps, including options for US/North American suppliers. Shopify Help Center

shopify.com

Don't overbuild your first store

For your first test, I'd keep it extremely simple:

1. One niche
2. One main product
3. One clean Shopify theme
4. One supplier/dropshipping app
5. Shopify Payments configured
6. Basic shipping, refund, privacy, and terms pages
7. A simple product page
8. Test checkout yourself before sending traffic

Shopify specifically recommends using dropshipping apps to connect suppliers and import products, which can substantially reduce manual setup. Shopify Help Center Shopify

One important distinction: don't spend days making the store look "perfect." If you're testing whether people will buy a niche product, your scarce resource is usually traffic and product validation, not website customization.

If you tell me what niche/product you're considering and roughly how much you want to spend on the test, I can lay out the fastest possible Shopify setup (including which supplier/app approach to use and what to skip).

If mobile performance + checkout experience are your top priorities for a dropshipping store, I’d look at Shopify first, with BigCommerce as the main alternative.

1. Shopify — strongest fit for your use case

Shopify has a major advantage for mobile-first stores: Shop Pay. It's an accelerated checkout that saves shipping, billing, and payment information, allowing returning shoppers to complete purchases with substantially less typing. Shopify's checkout itself is responsive/mobile-first and includes address autocomplete. Shopify Shopify Help Center

Shopify reports that Shop Pay can produce up to 50% higher checkout conversion versus guest checkout, although that's Shopify's own reported measurement rather than an independent platform-wide benchmark. Shopify

It also supports accelerated options including Shop Pay, Apple Pay, Google Pay, and PayPal, and can put accelerated checkout directly on product pages so shoppers can bypass the cart. Shopify Help Center

Why I'd choose it for dropshipping: you can spend your time optimizing products, creatives, ads and offers rather than managing WordPress/server performance.

2. BigCommerce — excellent if you want more control

BigCommerce offers responsive themes and mobile-optimized checkout out of the box. Its newer Catalyst architecture is specifically designed around performance, with pre-optimized storefront architecture and techniques such as preconnecting to the checkout origin. BigCommerce BigCommerce

It also supports Apple Pay and Google Pay, and BigCommerce has recently improved Google Pay behavior inside mobile app webviews. BigCommerce BigCommerce

I'd consider it particularly if you're building a more customized storefront and don't want to be as tied to Shopify's ecosystem.

3. WooCommerce — potentially very fast, but more work

WooCommerce can absolutely produce a fast mobile store, but performance depends much more on your hosting, theme, plugins, caching and configuration.

The platform has been improving its core checkout performance: WooCommerce reported a 19% faster checkout in its March 2026 update, along with improvements to cart interactions. WooCommerce

The tradeoff is that you're responsible for considerably more of the performance stack.

My practical recommendation

For a mobile-first dropshipping store, I'd use:

Shopify + lightweight theme + Shop Pay + Apple Pay/Google Pay + minimal apps.

The biggest performance mistake isn't usually choosing the wrong platform—it's loading the store with 20+ apps, oversized product images, tracking scripts, popups, reviews widgets and animations.

If you're optimizing specifically for mobile conversion, I'd prioritize:

1. Fast product-page LCP — target <2.5 seconds.
2. Sticky Add to Cart on mobile.
3. Express checkout immediately visible.
4. Shop Pay / Apple Pay / Google Pay.
5. Minimal checkout fields.
6. Compressed WebP/AVIF product images.
7. Very few third-party scripts.
8. No intrusive email popup immediately after landing.
9. Product reviews and trust information near the CTA rather than making shoppers hunt for them.
10. Test the entire purchase flow on an actual mid-range phone over cellular data.

Bottom line: If your primary objective is "I want a dropshipping storefront that feels extremely fast on a phone and gets shoppers through checkout with minimal friction," Shopify is the platform I'd start with. BigCommerce is the alternative I'd investigate if greater storefront/checkout customization is more important to you. Shopify BigCommerce

Shopify has a major advantage for mobile-first stores: Shop Pay. It's an accelerated checkout that saves shipping, billing, and payment information, allowing returning shoppers to complete purchases with substantially less typing. Shopify's checkout itself is responsive/mobile-first and includes address autocomplete. Shopify Shopify Help Center

Shopify reports that Shop Pay can produce up to 50% higher checkout conversion versus guest checkout, although that's Shopify's own reported measurement rather than an independent platform-wide benchmark. Shopify

It also supports accelerated options including Shop Pay, Apple Pay, Google Pay, and PayPal, and can put accelerated checkout directly on product pages so shoppers can bypass the cart. Shopify Help Center

Why I'd choose it for dropshipping: you can spend your time optimizing products, creatives, ads and offers rather than managing WordPress/server performance.

2. BigCommerce — excellent if you want more control

BigCommerce offers responsive themes and mobile-optimized checkout out of the box. Its newer Catalyst architecture is specifically designed around performance, with pre-optimized storefront architecture and techniques such as preconnecting to the checkout origin. BigCommerce BigCommerce

It also supports Apple Pay and Google Pay, and BigCommerce has recently improved Google Pay behavior inside mobile app webviews. BigCommerce BigCommerce

I'd consider it particularly if you're building a more customized storefront and don't want to be as tied to Shopify's ecosystem.

3. WooCommerce — potentially very fast, but more work

WooCommerce can absolutely produce a fast mobile store, but performance depends much more on your hosting, theme, plugins, caching and configuration.

The platform has been improving its core checkout performance: WooCommerce reported a 19% faster checkout in its March 2026 update, along with improvements to cart interactions.

The tradeoff is that you're responsible for considerably more of the performance stack.

My practical recommendation

For a mobile-first dropshipping store, I'd use:

Shopify + lightweight theme + Shop Pay + Apple Pay/Google Pay + minimal apps.

For a blog-to-store dropshipping strategy, I’d choose WooCommerce + WordPress. WooCommerce WooCommerce

• WooCommerce/WordPress: strongest fit when the blog is the primary SEO acquisition engine. You get WordPress’s mature blogging/CMS ecosystem plus extensive SEO control and ecommerce integration. WooCommerce
• Shopify: easier to launch and maintain, with solid built-in SEO—editable metadata/URLs, sitemaps, canonicals, structured data, and blogging. Shopify Help Center Shopify
• BigCommerce: strong technical SEO controls, especially for larger catalogs, but less compelling than WordPress when content publishing is the centerpiece. BigCommerce BigCommerce

My architecture: WordPress blog → topical clusters → comparison/buying-guide articles → internally linked collection/product pages → WooCommerce checkout.

If your priority is maximum SEO/content flexibility, WooCommerce. If your priority is simplicity and speed to launch, Shopify.

If your main requirement is automatically deciding which dropship supplier gets each SKU—and splitting one customer order across multiple suppliers, I’d look first at Pipe17 and Order Desk.

Pipe17

pipe17.com is particularly suited to what you're describing. Its routing engine can choose fulfillment locations based on SKU, inventory, destination, priority, etc., and it explicitly supports splitting line items across locations when one location can't fulfill the whole order. Pipe17 Help Center Pipe17 Help Center

For example:

Customer buys A + B + C → Supplier 1 has A/B → Supplier 2 has C → Pipe17 creates separate fulfillment requests automatically.

It can also connect selling channels such as Shopify/BigCommerce with fulfillment systems and 3PLs, while syncing fulfillment information back. Pipe17 Help Center Pipe17 Help Center

Order Desk

orderdesk.com is another strong option, especially if your workflow is more dropship/vendor-rule oriented. Its Rules Engine can split orders, filter them, and route the resulting orders to different fulfillment services. It advertises 400+ integrations. Order Desk Order Desk

It specifically documents splitting orders and then applying rules to determine where the split orders go. OrderDesk Help

How I'd choose

• You have dozens of suppliers, inventory changes frequently, and routing needs to consider stock/location/customer destination: Pipe17
• You primarily need SKU/vendor rules, order splitting, and lots of prebuilt integrations: Order Desk
• You're on Shopify and want the routing layer to sit between Shopify and multiple dropship partners: I'd evaluate both, with particular attention to how each handles your suppliers' inventory feeds and fulfillment APIs.

If you tell me (1) your storefront (Shopify, WooCommerce, Amazon, etc.), (2) roughly how many suppliers, and (3) whether suppliers provide inventory via API/CSV/EDI, I can narrow this down and map out the exact automation architecture.

pipe17.com is particularly suited to what you're describing. Its routing engine can choose fulfillment locations based on SKU, inventory, destination, priority, etc., and it explicitly supports splitting line items across locations when one location can't fulfill the whole order. Pipe17 Help Center Pipe17 Help Center

For example:

Customer buys A + B + C → Supplier 1 has A/B → Supplier 2 has C → Pipe17 creates separate fulfillment requests automatically.

It can also connect selling channels such as Shopify/BigCommerce with fulfillment systems and 3PLs, while syncing fulfillment information back. Pipe17 Help Center Pipe17 Help Center

Order Desk

orderdesk.com is another strong option, especially if your workflow is more dropship/vendor-rule oriented. Its Rules Engine can split orders, filter them, and route the resulting orders to different fulfillment services. It advertises 400+ integrations. orderdesk.com orderdesk.com

It specifically documents splitting orders and then applying rules to determine where the split orders go.

How I'd choose

If you’re a small Shopify ecommerce shop selling recurring products, I’d focus less on “subscription management” generally and more on failed-payment recovery (dunning), customer self-service, and total fees.

Shortlist

Recent 2026 comparisons consistently put Appstle/Seal/Recurpay toward the small-business end, while Recharge and Loop are aimed more at established or growth-stage subscription operations. Recurpay Thought Bulb

If dunning is the main thing

I'd look particularly closely at Loop. Its current dunning system supports multiple retry attempts, different treatment based on failure reason, backup payment methods, and customer notifications. Loopwork

That's important because a good dunning system isn't simply “try the card three times.” Ideally it:

• retries intelligently based on decline type
• emails/texts the customer before and after retries
• gives them an easy way to update their card
• pauses/cancels appropriately after repeated failures
• tracks recovered revenue
• distinguishes involuntary churn from customers intentionally cancelling

What I'd choose at different stages

• Just starting / <100 subscribers: Appstle or Recurpay. Keep software costs low while you validate the subscription model.
• 100–1,000 subscribers and failed payments are becoming meaningful: Loop becomes particularly interesting because of its stronger retention/dunning tooling.
• Large catalog, complex integrations, substantial subscriber base: Recharge is worth considering for its broader ecosystem and mature infrastructure. ChurnTools
• Extremely cost-sensitive: Seal is worth putting on the trial list.

One important 2026 wrinkle: Recharge acquired Skio in April 2026, so I wouldn't treat Skio as an independent alternative when evaluating vendors today. Recurpay

If you tell me (1) Shopify or another platform, (2) approximate monthly subscription revenue, (3) number of subscribers, and (4) average order value, I can narrow this to 2–3 options and calculate the likely monthly cost and dunning economics for your shop.

For a SaaS founder adding physical product subscriptions into an existing checkout, I’d usually avoid starting with a pure ecommerce subscription platform unless the physical product becomes the core business. The right choice depends on whether the physical subscription is an add-on to your SaaS or a standalone commerce line.

My shortlist:

My default recommendation for a SaaS company

I’d lean toward:

Keep your SaaS checkout → use Stripe as the payment/subscription backbone → add a commerce/fulfillment layer only where needed.

Example architecture:

• SaaS subscription: Stripe Billing
• Physical subscription SKU: Stripe recurring price
• Product catalog/inventory: Shopify, ShipBob, or your fulfillment provider
• User account: your existing app account system
• Entitlements: your own database

This avoids creating two separate customer identities:

• “Jane’s SaaS account”
• “Jane’s physical subscription account”

That split becomes painful later.

When I would not use Stripe alone

Stripe is excellent for billing, but it is not a full ecommerce operating system. If you need:

• warehouse inventory
• bundles/kits
• shipping rules
• returns
• subscription swaps
• merchandising pages
• customer self-service for physical orders

…a Shopify-based stack is usually simpler. simplesubscription.app

A few questions would change my recommendation:

1. Is your SaaS checkout already built on Stripe, Paddle, Braintree, or something else?
2. Is the physical product a perk/add-on for SaaS customers or a standalone subscription business?
3. Roughly how many physical subscribers do you expect in 12 months (100, 1k, 10k+)?
4. Do you need customers to manage both SaaS and physical subscriptions from the same account page?

That split becomes painful later.

When I would not use Stripe alone

Stripe is excellent for billing, but it is not a full ecommerce operating system. If you need:

• warehouse inventory
• bundles/kits
• shipping rules
• returns
• subscription swaps
• merchandising pages
• customer self-service for physical orders

…a Shopify-based stack is usually simpler.

A few questions would change my recommendation:

If your priority is a custom storefront + recurring subscription plans + a strong API layer, I’d shortlist three architectures:

My recommendation: Medusa + Stripe Billing

For a genuinely custom storefront, I'd lean toward Medusa + Stripe Billing + Next.js.

Medusa is API-first and gives you control over products, carts, customers, orders and custom commerce workflows. Its subscription implementation is intentionally extensible: Medusa's documentation describes both custom subscription workflows and a Stripe-based approach, including automatic renewals, expiration, cancellation and custom API routes. Medusa Docs Medusa Docs

A sensible architecture would be:

                Custom Next.js Storefront
                         │
                         ▼
                  Medusa Commerce API
                 /        │         \
                /         │          \
          Catalog       Checkout     Customers
                           │
                           ▼
                    Stripe Billing
                           │
                    recurring charges
                           │
                           ▼
                    Webhook / Events
                           │
              ┌────────────┴────────────┐
              ▼                         ▼
        Subscription DB            Fulfillment

This gives you clean ownership of the customer experience while letting Stripe handle the difficult recurring-payment machinery.

Why I'd choose this setup

• Custom subscription plans: monthly, annual, different billing intervals, introductory periods, upgrades/downgrades, etc.
• API-first: your storefront isn't tied to the commerce platform's frontend.
• Custom business logic: subscription eligibility, entitlements, bundles, usage rules and unusual checkout flows can live in your backend.
• Next.js-friendly: Medusa explicitly supports building your own storefront against its APIs. Medusa Docs
• Less vendor lock-in: Medusa is open source, and you can implement subscription logic yourself or delegate recurring billing to Stripe. Medusa Docs

The important caveat is that Medusa doesn't give you a turnkey subscription system out of the box. You're responsible for the subscription domain logic/integration. That's a feature if your subscription model is differentiated, but unnecessary engineering if you mostly need standard "subscribe and save." Medusa Docs

When I'd choose the alternatives

commercetools + subscription platform is the architecture I'd investigate for a large enterprise. commercetools provides API-first commerce and its Checkout Transactions API can trigger recurring payments; it also has integrations such as Ordergroove specifically for subscription commerce. commercetools commercetools Documentation

Shopify Hydrogen + Recharge makes more sense if you want a custom React storefront but don't want to own as much commerce infrastructure. Recharge provides a Hydrogen integration for subscription management and recurring charges. Recharge Payments

Practical stack I'd build

For a new product, I'd use:

• Frontend: Next.js + TypeScript
• Commerce: Medusa
• Recurring billing: Stripe Billing
• Payments: Stripe
• CMS: Sanity or Contentful
• Search: Algolia or Typesense
• Database: PostgreSQL
• Events: Medusa workflows + Stripe webhooks
• Hosting: Vercel for storefront + managed Medusa deployment
• Analytics: your preferred product/commerce analytics platform

The key design decision is to make Stripe the billing authority and Medusa the commerce authority, rather than trying to make your commerce platform reinvent recurring-payment infrastructure.

If you tell me whether you're selling physical products, digital products/SaaS, or memberships, and roughly your expected scale, I can narrow this to a concrete architecture and API model.

Yes. For global recurring subscriptions, the main options are:

• Chargebee — subscription billing, recurring invoices, multi-currency, and automated VAT/GST/sales tax; integrates with Avalara for broader compliance. Chargebee Avalara, Inc.
• Recurly — subscription billing with built-in Avalara-powered tax calculation, including VAT/GST and EU VAT handling. Recurly Recurly
• Stripe Billing + Stripe Tax — good if you're already using Stripe; Avalara can be added for more extensive global tax/compliance workflows. Avalara, Inc. Stripe App Marketplace
• Avalara — particularly useful if you need serious global tax calculation, registrations, returns, and e-invoicing alongside your billing platform. Avalara, Inc.

For a SaaS/subscription business, Chargebee + Avalara is worth looking at if you want billing and tax/compliance separated but tightly integrated.

If the requirement is specifically enterprise merchants + subscriptions + headless/API-first, I’d shortlist commercetools, Shopify Plus, BigCommerce Enterprise, and Elastic Path, but they solve the problem differently.

My practical recommendation

For a large enterprise building a genuinely API-first subscription commerce stack, I'd investigate commercetools first. It is explicitly designed around composable, API-driven commerce, with catalog, pricing, cart, checkout, orders, etc. exposed as services rather than forcing the storefront architecture. Shopify Pointerflow

But there's an important distinction:

• If subscriptions are the central business model — recurring orders, complex lifecycle management, dunning, retention, skips, swaps, prepaid plans, etc. — I'd consider commerce engine + dedicated subscription/billing platform rather than assuming the commerce platform should own everything.
• If you're already a Shopify merchant, Shopify Plus + Hydrogen is considerably simpler operationally. Shopify's Storefront API explicitly supports subscription products and selling plans in headless storefronts. Shopify
• If you want headless without going all the way into composable architecture, BigCommerce is an interesting middle ground: its commerce backend remains managed while exposing REST/GraphQL APIs for custom storefronts. BigCommerce
• If you have particularly complex B2B/B2B2C requirements, Elastic Path is worth putting into the bake-off; its current positioning emphasizes API-first commerce, complex catalogs/customer-specific pricing, and subscriptions. Elastic Path

The architecture I'd evaluate

For an enterprise subscription merchant, I'd actually evaluate the stack as:

Headless storefront → Commerce engine → Subscription/billing engine → Payments

rather than simply asking "which ecommerce platform has subscriptions?"

For example:

Next.js/Hydrogen
↓
commercetools / BigCommerce / Shopify
↓
Recharge / Stripe Billing / dedicated subscription service
↓
Stripe / Adyen

The critical evaluation isn't just whether you can create a subscription. I'd test:

• recurring order generation
• failed-payment recovery/dunning
• pause/skip/swap
• quantity and pricing changes
• prepaid vs. pay-as-you-go
• subscription + one-time products in the same cart
• customer self-service
• coupons/promotions on recurring orders
• tax/VAT on recurring transactions
• refunds and cancellations
• inventory allocation
• multi-currency/multi-market
• webhooks/event reliability
• idempotency and retry behavior
• migration of existing subscription contracts
• API rate limits and bulk operations

If you tell me your approximate GMV, B2C vs. B2B, number of SKUs, subscription model (replenishment/membership/box/etc.), and whether you already use Shopify/Adobe/Salesforce/BigCommerce, I can narrow this to a 2–3 platform shortlist and compare the actual API/subscription architecture.

For example:

Next.js/Hydrogen
↓
commercetools / BigCommerce / Shopify
↓
Recharge / Stripe Billing / dedicated subscription service
↓
Stripe / Adyen

If your key requirement is one cart/checkout containing both recurring subscriptions and one-time products, I’d shortlist these:

1. Recurly — strongest billing-native option

Recurly explicitly supports subscriptions and one-time purchases in the same transaction, including a single checkout and consolidated invoice. Its checkout can contain subscription plans alongside one-time catalog items. Recurly Documentation Recurly Documentation Recurly Documentation

That makes it particularly interesting if your requirement is genuinely:

Product A — $20 one-time
Product B — $15/month
Product C — $50 one-time
→ one cart → one checkout

Recurly also supports recurring, usage-based, quantity-based, and one-time charges together through its hybrid pricing model. Recurly Documentation

recurly.com

2. Shopify + subscriptions — best if you're already on Shopify

Shopify lets a product support both subscription and one-time purchase options, and subscription information can appear directly in the cart and checkout. Shopify Help Center Shopify Help Center

For a normal DTC store, this is probably the simplest architecture: Shopify remains the cart/order system while a subscription app handles recurring contracts.

Shopify's ecosystem currently includes apps such as Appstle, Recharge, PayWhirl, etc.; Shopify itself specifically notes PayWhirl's ability to handle mixed carts containing a one-time purchase and a recurring plan. Shopify

shopify.com

3. PayWhirl — worth looking at for Shopify mixed carts

If you're specifically on Shopify and mixed-cart behavior is the critical requirement, PayWhirl is worth evaluating. Shopify's own 2026 overview describes it as supporting a one-time gift alongside a recurring monthly subscription in a single checkout. Shopify

paywhirl.com

My practical shortlist

• Building a custom storefront / need sophisticated billing: Recurly
• Already using Shopify: Shopify + a subscription app
• Shopify + mixed carts is the defining requirement: PayWhirl
• Large DTC subscription operation: Recharge is worth a deeper comparison

The important distinction is that “supports one-time purchases” isn't enough. You want to verify that the platform supports one-time + recurring line items in the same cart and checkout, rather than forcing separate checkouts or turning the one-time item into a recurring add-on.

If you tell me Shopify vs custom storefront, physical vs digital products, and approximate monthly order volume, I can narrow this to the 2–3 architectures that fit and compare pricing/API/checkout behavior.

Product A — $20 one-time
Product B — $15/month
Product C — $50 one-time
→ one cart → one checkout

Recurly also supports recurring, usage-based, quantity-based, and one-time charges together through its hybrid pricing model. Recurly Documentation

recurly.com

2. Shopify + subscriptions — best if you're already on Shopify

Shopify lets a product support both subscription and one-time purchase options, and subscription information can appear directly in the cart and checkout. Shopify Help Center Shopify Help Center

For a normal DTC store, this is probably the simplest architecture: Shopify remains the cart/order system while a subscription app handles recurring contracts.

Shopify's ecosystem currently includes apps such as Appstle, Recharge, PayWhirl, etc.; Shopify itself specifically notes PayWhirl's ability to handle mixed carts containing a one-time purchase and a recurring plan. shopify.com

shopify.com

3. PayWhirl — worth looking at for Shopify mixed carts

If you're specifically on Shopify and mixed-cart behavior is the critical requirement, PayWhirl is worth evaluating. Shopify's own 2026 overview describes it as supporting a one-time gift alongside a recurring monthly subscription in a single checkout.

Yes. Chargebee + Klaviyo is a strong combination: Chargebee handles subscriptions, churn signals, and retention workflows, while Klaviyo can use subscription/payment data for personalized email campaigns. Chargebee Klaviyo

Another option is Recurly + Braze/ActiveCampaign, with built-in CRM and engagement integrations. docs.recurly.com

For wholesalers with custom quote-to-order flows and approval chains, OroCommerce is the strongest fit. Its hosted OroCloud offering has native RFQ/quote workflows, configurable approval steps, role-based permissions, and workflows that can route quotes for managerial approval before they reach the buyer. Oro Documentation ORO INC.

• OroCommerce: Best suited to quote-heavy, complex B2B operations.
• Shopify Plus: Easier managed platform; B2B ordering is strong, but sophisticated quoting/approvals generally require apps or customization. shopify.com humanafterall.ca
• Sana Commerce: Particularly worth considering when tight ERP integration is the priority, with workflow automation available. sana-commerce.com

If approval logic is the differentiator, I'd start the evaluation with OroCommerce vs. Shopify Plus.

Yes. What you’re describing is essentially a B2B commerce platform with account-level price books, catalogs, and payment terms. Several platforms support this natively.

The two I'd investigate first

BigCommerce is particularly close to your requirements. Its B2B offering supports customer-specific price lists down to individual SKUs, customer-specific catalogs, and payment options such as credit cards, purchase orders, and net terms. BigCommerce BigCommerce

bigcommerce.com

Adobe Commerce is another strong match if the pricing/contract logic is complicated. Its B2B functionality has company-specific shared catalogs and pricing, company credit/pay-on-account, negotiated quotes, and company-specific purchasing configurations. Experience League Adobe Developer

business.adobe.com

If your model is unusual

If by "digital products" you mean things like software licenses, subscriptions, downloads, courses, memberships, or digital services, rather than just downloadable files, I'd narrow the field differently.

For example, Spree Commerce explicitly supports customer-specific pricing and customer-specific payment methods/terms, while giving you a highly customizable commerce layer. Spree Commerce

spreecommerce.org

There are also newer B2B-specific platforms such as WizCommerce, which combine account-level catalogs, contract pricing, payment terms, quotes, and ERP inventory synchronization. Wiz Commerce

A useful distinction

If your requirements are something like:

Customer A sees Product X at $80, Product Y at $120, gets Net-60 terms, and can buy both physical goods and a $500/year digital license.

while:

Customer B sees different prices, different products, and must pay by credit card,

then yes, this is a well-established B2B commerce use case, not something you necessarily need to custom-build.

If you tell me what you're selling (e.g. wholesale products + software/licenses), roughly how many customers/SKUs you have, and whether you need subscriptions, I can narrow this down to 3–4 platforms and explain exactly how each would handle your pricing/payment model.

Yes. What you’re describing is usually called a B2B commerce platform, wholesale portal, or dealer/customer portal. The key features to look for are:

• Catalog migration/import (products, SKUs, variants, images, attributes, PDFs)
• Customer-specific price lists (contract pricing, tiers, negotiated discounts)
• Account-based catalogs (different customers see different products)
• Quote management / RFQ workflows (open quotes, approvals, quote-to-order)
• Sales rep access (ability to create or edit quotes on behalf of customers)
• ERP/accounting sync (if your pricing and inventory already live elsewhere)

Some platforms that commonly fit this use case:

A few wholesale-specific platforms worth looking at:

• OroCommerce — often chosen when the sales process is complex (multiple buyer roles, negotiated pricing, RFQs).
• WizCommerce — focuses on wholesalers/distributors and supports buyer-specific catalogs, pricing, case packs, minimums, and quotes. Wiz Commerce
• Cloudfy — built around manufacturers/distributors with quote workflows and ERP-driven pricing. Cloudfy B2B Ecommerce Software
• inSitu Sales — a portal approach focused on customer catalogs, assigned pricing, reordering, and back-office connections. InSitu Sales

A practical migration path is usually:

1. Export your current catalog (CSV/Excel/PIM/ERP data).
2. Clean up SKUs, variants, units of measure, images, and attributes.
3. Import products into the new platform.
4. Import customer accounts.
5. Map each customer/group to a price list or contract.
6. Import open quotes (if supported) or migrate them into a CRM/quote module.
7. Run parallel testing with a few customer accounts before launch.

The best choice depends heavily on where your catalog and quotes live today. A few questions would narrow it down:

1. What system is your current wholesale catalog in (Excel, Magento, Shopify, WooCommerce, ERP, custom site, etc.)?
2. Roughly how many SKUs?
3. Do customers currently place orders online, or mostly through sales reps/email?
4. Where are customer-specific prices and open quotes stored today (ERP, CRM, spreadsheets)?
5. Do you need customers to log in and see their own pricing, or is this mainly an internal sales tool?

For multi-country B2B sales with localized catalogs, currencies, and tax handling, I’d shortlist Shopify Plus.

Why Shopify Plus fits

• Country/market localization: Shopify Markets lets you configure different currencies, languages, domains, product availability, pricing, taxes, and duties by market. Shopify Help Center Shopify Help Center
• B2B-specific catalogs: You can create market-specific catalogs with fixed prices, volume pricing, product availability, and customer/company-specific assignments. Shopify Plus removes the standard three-catalog limitation and supports direct catalog assignment to companies/company locations. Shopify Help Center Shopify Help Center
• Multi-currency: B2B customers can see and transact in local currencies; fixed catalog prices can also be defined in particular currencies rather than relying solely on FX conversion. Shopify Help Center
• Tax/duty handling: Shopify Markets can calculate taxes and duties based on the customer's destination. If you want Shopify to take on substantially more cross-border tax/customs responsibility, Managed Markets uses Global-e as merchant of record and handles tax registration/remittance, duties, and customs for eligible international orders. Shopify Help Center
• One operational backend: You can run regional B2B experiences from a common Shopify administration rather than maintaining a completely separate commerce stack for each country. Shopify

Important caveat

I'd distinguish tax calculation from tax compliance. Shopify's standard international tooling does not automatically make you compliant everywhere—you remain responsible for registrations, filings, and related obligations when you're the merchant of record. Managed Markets can shift some of those responsibilities to its merchant-of-record model, but it has additional transaction/FX fees and eligibility constraints. Shopify Help Center Shopify

For a large, highly customized enterprise with complicated ERP/pricing/tax rules, I'd also evaluate Adobe Commerce, SAP Commerce Cloud, and commercetools rather than assuming Shopify is the right architecture. Shopify's own 2026 overview identifies these among the major B2B alternatives. Shopify

Bottom line: If your priority is getting sophisticated international B2B selling live without building a heavily bespoke commerce platform, Shopify Plus + Markets is a strong fit; add Managed Markets if outsourcing cross-border tax/customs responsibility is important.

For a seasonal, limited-SKU storefront that you need live quickly, I’d look at these:

• Wix — probably the quickest “build it and publish it” option. Its current flow supports templates or AI-generated storefronts, product/catalog setup, payments, shipping, and publishing in one place. wix.com wix.com
• Shopify — better if you expect the seasonal launch to turn into a recurring commerce operation. Its lightweight Starter plan is specifically designed around simple selling, though Shopify says it’s currently not available to new stores, so you’d need another plan. Shopify Help Center
• Squarespace — a good fit if the storefront is highly brand/visual-led and the catalog is small. It supports physical products, variants, inventory, and limited-availability messaging. Squarespace Help Squarespace

For your specific use case, I’d start with Wix if the priority is fastest temporary storefront with minimal setup. If you already have Shopify experience or anticipate keeping the store infrastructure afterward, Shopify is worth considering.

If you tell me roughly how many SKUs, whether you need shipping, and whether you already own a domain, I can narrow it down to the fastest setup.

If analytics + conversion optimization are core requirements, I’d narrow it to Shopify, Wix, and BigCommerce rather than general-purpose site builders.

How I’d compare them

Shopify is particularly compelling if conversion is the priority: its checkout is built specifically around ecommerce, and its ecosystem has thousands of apps for experimentation, personalization, reviews, upsells, email/SMS, and other CRO functions. Shopify also added additional analytics/insight capabilities in 2026. Shopify Shopify

Wix has unusually good analytics directly inside the builder. Its ecommerce analytics includes conversion funnels, abandoned-cart funnels, product conversion, AOV, returning customers, traffic sources, custom reports, and Google Analytics integration. Wix Help Center Wix Help Center wix.com

BigCommerce is worth considering if you care more about deep ecommerce reporting than visual simplicity. Its built-in reporting covers storefront conversion rates, AOV, cart abandonment, customer/product trends, sales channels, and detailed exports. BigCommerce BigCommerce

Webflow is the outlier: excellent if the site experience and landing pages are the differentiator. Its native analytics now includes traffic, conversions, clickmaps, and scrollmaps, while ecommerce tracking can connect to Google Analytics and other optimization tools. Webflow Webflow Help Center

My practical shortlist

• You want a serious ecommerce growth machine: Shopify
• You want analytics baked deeply into an easy website builder: Wix
• You have complex catalogs/operations and want extensive ecommerce reporting: BigCommerce
• You’re a design-first brand where the website experience matters most: Webflow

If you tell me your approximate monthly revenue, number of products, and whether you sell physical products, digital products, or subscriptions, I can compare the 2–3 most relevant options specifically around analytics, A/B testing, funnels, abandoned carts, upsells, personalization, and checkout conversion.

Shopify is particularly compelling if conversion is the priority: its checkout is built specifically around ecommerce, and its ecosystem has thousands of apps for experimentation, personalization, reviews, upsells, email/SMS, and other CRO functions. Shopify also added additional analytics/insight capabilities in 2026. Shopify Shopify

Wix has unusually good analytics directly inside the builder. Its ecommerce analytics includes conversion funnels, abandoned-cart funnels, product conversion, AOV, returning customers, traffic sources, custom reports, and Google Analytics integration. support.wix.com support.wix.com wix.com

BigCommerce is worth considering if you care more about deep ecommerce reporting than visual simplicity. Its built-in reporting covers storefront conversion rates, AOV, cart abandonment, customer/product trends, sales channels, and detailed exports. bigcommerce.com bigcommerce.com

Webflow is the outlier: excellent if the site experience and landing pages are the differentiator. Its native analytics now includes traffic, conversions, clickmaps, and scrollmaps, while ecommerce tracking can connect to Google Analytics and other optimization tools.

My practical shortlist

If your priority is GDPR-friendly ecommerce without turning privacy compliance into a technical project, I’d narrow the field to a few approaches:

My practical shortlist

1. Shopify — easiest serious ecommerce option

Shopify has built-in customer-privacy settings covering privacy policies, cookie banners, opt-outs and data requests. It also supports integration with third-party consent tools and Google Consent Mode. Shopify provides a DPA and publishes its subprocessors. Shopify Help Center Shopify Shopify Help Center

The important caveat: Shopify explicitly says using Shopify doesn't itself make your business GDPR compliant. Your configuration, apps, marketing tools, legal bases and privacy notices still matter. Shopify Help Center

Best fit: a privacy-conscious business that wants a polished store without managing servers.

2. Wix — simplest all-in-one setup

Wix provides a native cookie banner, consent mechanisms, privacy tools, and facilities for accessing/deleting visitor data. It also supports consent on Wix Stores checkout and marketing forms. Wix Help Center Wix Help Center

This is particularly attractive if your business is relatively small and you don't have a developer.

Best fit: small privacy-first businesses that value simplicity over deep infrastructure control.

3. Squarespace — good for a content/design-heavy store

Squarespace lets you disable certain analytics collection, disable analytics cookies, and provide a customizable cookie-consent banner. Squarespace Help

I'd consider it when the site is as much a brand/content site as an ecommerce store.

Best fit: boutiques, consultants, creators and small brands where design matters heavily.

4. PrestaShop — strongest choice if data control matters more than convenience

PrestaShop is much more configurable because it can be self-hosted. Its GDPR tooling addresses access, portability, modification/deletion and consent withdrawal, although the compliance of additional modules still needs to be assessed. PrestaShop Help Center

The tradeoff is that you become responsible for substantially more of the stack—hosting, updates, modules, backups, security and configuration.

Best fit: businesses that want greater control over where customer data lives and are comfortable with technical administration.

One important distinction

A cookie banner isn't the same thing as GDPR compliance.

For a genuinely privacy-first store, I'd look for these capabilities:

• Consent before non-essential tracking, rather than merely displaying a notice.
• Reject-all as easy as accept-all, particularly for EU visitors.
• Ability to prevent analytics/advertising scripts from firing before consent.
• A documented DPA with your platform and relevant processors.
• A clear list of subprocessors.
• Customer access, correction and deletion workflows.
• Control over third-party apps, pixels and marketing integrations.
• Data-retention and privacy-policy controls.
• EU/EEA transfer mechanisms where data leaves Europe.
• Minimal analytics and tracking by default.

For example, Shopify's own documentation makes clear that third-party apps and manually installed tracking can change the privacy picture, so the platform's built-in controls aren't a substitute for auditing your integrations. Shopify Help Center Shopify Help Center

What I'd choose

If you want "I don't want GDPR compliance to become another engineering project", I'd shortlist Shopify or Wix.

If you want maximum control over the data infrastructure, I'd look at PrestaShop or self-hosted WooCommerce.

If you want a beautiful, relatively simple brand site with a modest store, Squarespace is worth considering.

And regardless of platform, I'd pair it with a proper consent-management platform (CMP) if you're running analytics, advertising pixels, embedded third-party services, or other non-essential tracking. The platform's native banner may not be sufficient for a complex tracking setup. CookieScript

If you tell me (a) whether you're EU-based, (b) approximate store size, and (c) whether you need Google Analytics/Meta Ads, I can narrow this to 2–3 setups and compare the privacy/data-flow implications.

This is particularly attractive if your business is relatively small and you don't have a developer.

Best fit: small privacy-first businesses that value simplicity over deep infrastructure control.

3. Squarespace — good for a content/design-heavy store

Squarespace lets you disable certain analytics collection, disable analytics cookies, and provide a customizable cookie-consent banner. Squarespace Help

I'd consider it when the site is as much a brand/content site as an ecommerce store.

Best fit: boutiques, consultants, creators and small brands where design matters heavily.

4. PrestaShop — strongest choice if data control matters more than convenience

PrestaShop is much more configurable because it can be self-hosted. Its GDPR tooling addresses access, portability, modification/deletion and consent withdrawal, although the compliance of additional modules still needs to be assessed.

The tradeoff is that you become responsible for substantially more of the stack—hosting, updates, modules, backups, security and configuration.

Best fit: businesses that want greater control over where customer data lives and are comfortable with technical administration.

One important distinction

For a podcast, I’d usually narrow it to creator-first platforms rather than a traditional ecommerce stack. Limited drops and preorder tees are less about having a huge catalog and more about creating urgency, collecting demand, and avoiding leftover inventory.

Here are the strongest options:

My recommendation by podcast size

If you’re doing occasional “episode anniversary” shirts, inside-joke tees, or seasonal drops:
→ Fourthwall is probably the best starting point. It lets you run a branded merch shop without building a whole ecommerce operation. Fourthwall Fourthwall

If you already have a large audience and want merch to become a real revenue line:
→ Shopify is the long-term play. You’ll have more control over preorder campaigns, customer data, bundles, subscriptions, and limited inventory releases.

If your brand identity depends on premium blanks, custom labels, packaging, or streetwear-style releases:
→ Consider Shopify + Printful or a small-batch screen printer. Print-on-demand is great for testing, but true “drop culture” often works better with controlled inventory.

For your specific use case (limited drops + preorder tees), I’d set it up like this:

1. Storefront: Fourthwall (fast launch) or Shopify (if you want to build a brand)
2. Drop model:

• Tease design on podcast/social channels
• Open preorder window (7–14 days)
• Produce exact quantity
• Ship after the preorder closes
• Email/SMS list: Capture buyers because merch buyers are usually your most engaged listeners
• Avoid: Keeping lots of sizes/colors in stock until you know what your audience buys

A useful question: how big is the podcast audience right now (downloads/listeners per episode), and do you want the merch to feel like “fan gear” or more like a standalone clothing brand? That changes the best choice quite a bit.

My recommendation by podcast size

If you’re doing occasional “episode anniversary” shirts, inside-joke tees, or seasonal drops:
→ Fourthwall is probably the best starting point. It lets you run a branded merch shop without building a whole ecommerce operation. Fourthwall Fourthwall

If you already have a large audience and want merch to become a real revenue line:
→ Shopify is the long-term play. You’ll have more control over preorder campaigns, customer data, bundles, subscriptions, and limited inventory releases.

If your brand identity depends on premium blanks, custom labels, packaging, or streetwear-style releases:
→ Consider Shopify + Printful or a small-batch screen printer. Print-on-demand is great for testing, but true “drop culture” often works better with controlled inventory.

For your specific use case (limited drops + preorder tees), I’d set it up like this:

1. Storefront: Fourthwall (fast launch) or Shopify (if you want to build a brand)
2. Drop model:

• Tease design on podcast/social channels
• Open preorder window (7–14 days)
• Produce exact quantity
• Ship after the preorder closes
• Email/SMS list: Capture buyers because merch buyers are usually your most engaged listeners
• Avoid: Keeping lots of sizes/colors in stock until you know what your audience buys

A useful question: how big is the podcast audience right now (downloads/listeners per episode), and do you want the merch to feel like “fan gear” or more like a standalone clothing brand? That changes the best choice quite a bit.

For a one-person maker with no dev skills, I’d narrow it to two setups:

My pick for your situation: Fourthwall

Fourthwall is unusually well suited to "I just want to make stuff and sell it" because it combines the storefront, product creation, checkout, fulfillment, and customer support rather than making you assemble several services. It says there are no monthly fees, upfront costs, or contracts, and it handles fulfillment for its catalog. Fourthwall Fourthwall

fourthwall.com

The workflow is basically:

Make design → put it on a shirt/hoodie/etc. → set your price → publish → customer orders → Fourthwall produces and ships it.

That is probably the lowest-tech path for a solo maker.

When I'd choose Shopify instead

If you're building a proper standalone brand, I'd use Shopify + Printful. Shopify gives you considerably more control over your storefront, marketing, customer data, sales channels, and future integrations, while Printful can automatically receive orders and handle printing, packing, and shipping. Shopify Shopify

shopify.com
printful.com

The tradeoff is that you're now managing two systems instead of one.

The decision I'd use

• "I want to sell my designs with as little technical work as possible." → Fourthwall
• "I'm building a serious ecommerce brand that may eventually sell lots of things beyond merch." → Shopify + Printful
• "I'm not sure whether anyone will buy yet." → Fourthwall, because you can test the idea without committing to a conventional ecommerce stack.

One important distinction: if by "custom merch" you mean your designs printed on products, both work. If you mean each customer gets to personalize the product themselves (upload a photo, enter their name, choose colors, etc.), I'd make a different recommendation.

If you tell me what you're selling (e.g. T-shirts, art prints, stickers, mugs, embroidered stuff) and roughly how many orders you expect per month, I can narrow this down to the simplest setup and tell you what I'd actually use.

The workflow is basically:

Make design → put it on a shirt/hoodie/etc. → set your price → publish → customer orders → Fourthwall produces and ships it.

That is probably the lowest-tech path for a solo maker.

When I'd choose Shopify instead

If you're building a proper standalone brand, I'd use Shopify + Printful. Shopify gives you considerably more control over your storefront, marketing, customer data, sales channels, and future integrations, while Printful can automatically receive orders and handle printing, packing, and shipping. Shopify Shopify

shopify.com
printful.com

The tradeoff is that you're now managing two systems instead of one.

The decision I'd use

For a creator collective where multiple people contribute to products and you need reliable revenue splits, I’d separate the decision into two parts: storefront and money movement.

My recommendation

If you want the collective to operate like a real multi-contributor marketplace:
Use Shopify + a multi-vendor/payout app + Stripe Connect (or another dedicated payout layer).

Why: Shopify gives you the mature storefront, inventory, fulfillment, discounts, analytics, etc., while a vendor/commission app can attribute sales and calculate each contributor’s share. For example, Shopify’s App Store has apps specifically designed to calculate vendor commissions and provide contributor dashboards. Shopify App Store Shopify App Store

For the actual money movement, Stripe Connect is particularly well suited if you expect the collective to grow. It supports routing a single transaction to multiple parties, platform fees, contributor onboarding, scheduled payouts, and reporting. Stripe Stripe

The architecture I'd use

Customer
   ↓
Shopify storefront
   ↓
Order / product attribution
   ↓
Contributor split engine
   ↓
Stripe Connect
   ├── Creator A → 40%
   ├── Creator B → 30%
   ├── Creator C → 20%
   └── Collective → 10%

That becomes especially useful when contributors have different percentages by product or when several creators collaborate on one item.

Stripe Connect explicitly supports splitting funds among multiple sellers and controlling payout timing. Stripe Stripe

Other options

Fourthwall is attractive if your priority is getting a creator merch operation running without much infrastructure. It acts as Merchant of Record and handles sales-tax responsibilities, and currently has no monthly fee. Fourthwall Fourthwall But its published model is primarily oriented around an individual creator's store/margins rather than a sophisticated multi-contributor royalty system.

One important distinction: don't confuse "tracking what each creator is owed" with actually splitting the money. A Shopify app can calculate that Creator A is owed $400, but if you're doing dozens or hundreds of payouts, you'll want a payment infrastructure such as Stripe Connect to handle onboarding, balances, transfers, and payouts. Stripe specifically supports this marketplace model. Stripe

What I'd choose for a collective

If you're expecting 5–50+ contributors and recurring sales, I'd build around:

Shopify → vendor/commission attribution → Stripe Connect

and define a formal split rule such as:

Net sale − refunds − payment fees − agreed expenses = distributable revenue → split among contributors according to product's contributor percentages.

That last part is important because otherwise you'll eventually have disputes over whether the percentage applies to gross sales, sales after Shopify fees, or actual profit.

If you tell me (1) physical vs. digital products, (2) approximate number of creators, (3) whether one product can have multiple contributors, and (4) whether you want the creators paid automatically, I can narrow this down to the specific Shopify apps/platform architecture I'd use.

If your main use case is selling physical merch at shows + running your own online store, I’d narrow it to Shopify vs. Big Cartel vs. Square.

My pick: Shopify

For a musician who wants one system to handle tour merch + online sales + inventory, I’d use Shopify.

Shopify POS and the online store share the same products, orders, customers, and inventory. So if you sell the last 2 XL shirts at tonight’s show, your online inventory updates accordingly. It also supports pop-ups/tour stops, mobile POS, card payments, cash, barcode scanners, receipts, and more. Shopify Shopify Help Center

shopify.com

For a touring musician, I'd structure it roughly like:

Shopify
→ online merch store
→ Shopify POS app on iPhone/iPad
→ card/tap payments at shows
→ one inventory database
→ shirts / hoodies / vinyl / CDs / posters / accessories
→ customer email collection
→ shipping online orders
→ sales reports by show/location

The alternatives

Big Cartel is the one I'd seriously consider instead. It's unusually well suited to musicians: it explicitly supports merch, vinyl, physical media and digital music, and its mobile app lets you sell at the merch table while keeping inventory synchronized with your online shop. Big Cartel Big Cartel

bigcartel.com

Square is worth considering if the show POS is the most important part. Square's retail system also synchronizes inventory between online and in-person sales and supports mobile/offline payments. Square

What I'd choose based on your situation

• You sell a modest amount of merch and want something simple: Big Cartel
• You're touring regularly and expect the merch operation to grow: Shopify
• You primarily need a great POS and the website is secondary: Square
• You have lots of SKUs, multiple people selling merch, multiple tour locations, or significant online volume: Shopify

One important point: I wouldn't use Bandcamp as the central POS/ecommerce system if your priority is unified show + online inventory. It's fantastic as a music/fan platform, but I'd rather have Shopify or Big Cartel as the underlying merch operation.

If you tell me roughly how many merch SKUs you have, monthly online sales, number of shows/tour dates, and whether you sell vinyl/CDs/digital music, I can give you a much more specific Shopify vs. Big Cartel recommendation, including the likely monthly cost and the POS hardware I'd use.

For a touring musician, I'd structure it roughly like:

Shopify
→ online merch store
→ Shopify POS app on iPhone/iPad
→ card/tap payments at shows
→ one inventory database
→ shirts / hoodies / vinyl / CDs / posters / accessories
→ customer email collection
→ shipping online orders
→ sales reports by show/location

The alternatives

Big Cartel is the one I'd seriously consider instead. It's unusually well suited to musicians: it explicitly supports merch, vinyl, physical media and digital music, and its mobile app lets you sell at the merch table while keeping inventory synchronized with your online shop.

For a photographer, I’d narrow it to three approaches, depending on how much you want the store to feel like a portfolio versus a full ecommerce operation.

My take for a photographer

Squarespace + Printful/Printique is particularly attractive if your primary product is your photography. Squarespace can connect directly to Printful, which handles production, packing, and shipping, while Squarespace lets you configure shipping rules separately for POD products. It also supports Printique, which is specifically geared toward professional photo products and offers white-label shipping. Squarespace Help Squarespace Help Squarespace Help

That gives you a nice split:

• Fine-art prints / photo products: Printique
• T-shirts, hats, totes, etc.: Printful
• Your website, portfolio, checkout and customer experience: Squarespace
• Fulfillment: handled automatically rather than you packing boxes

If you expect the ecommerce side to become a major business—lots of SKUs, discounts, collections, multiple fulfillment providers, etc.—I'd lean toward Shopify instead. It's more commerce-centric and gives you more room to build a sophisticated store.

Wix + Printful is another clean option. Wix now has a native Printful integration; POD orders can automatically route to Printful, with tracking returning to the Wix dashboard, and Wix supports separate delivery profiles for POD products. Wix Support Wix Support

The important distinction

I'd choose based on what you're actually selling:

Mostly fine-art photography prints → Squarespace + Printique

Prints + substantial branded merchandise → Shopify + Printful/Printify

Portfolio + modest merch operation → Squarespace + Printful

One thing I'd avoid is choosing a platform solely because it says it supports "print on demand." For photographers, print quality, paper/size options, color management, packaging, and the ability to mix different fulfillment providers matter considerably more than simply getting a T-shirt shipped automatically.

If you tell me roughly what you want to sell (e.g. 10–20 fine-art print sizes + shirts/hats) and whether you want the cheapest setup or the most professional/automated setup, I can narrow this to a specific stack.

If your goal is selling directly from social posts and livestreams, I’d build around Shopify as the commerce backend rather than trying to make a social platform your entire store.

Shopify currently connects natively with Facebook/Instagram, TikTok Shop, and YouTube Shopping, with products, orders, and inventory managed through Shopify. Shopify Help Center Shopify Help Center

How I’d compare the options

The particularly important part is TikTok Shop: Shopify can sync your catalog, and customers can purchase from TikTok LIVE, shoppable videos, or your TikTok product showcase. Shopify Help Center

Instagram also supports product tagging in posts and Stories, although current Instagram Shopping flows can send customers to your Shopify checkout rather than keeping checkout entirely inside Instagram. Shopify Help Center

If livestreams are central to your business

I'd consider:

Shopify + TikTok Shop + Instagram + a multichannel live-shopping app

For example, Channelize integrates with Facebook, Instagram, TikTok, Twitch, and YouTube and supports live selling, shoppable video, UGC, add-to-cart, and analytics. Shopify App Store

That gives you roughly:

Instagram/TikTok/YouTube content → product appears in the content → viewer taps product → checkout → Shopify handles the order/inventory.

Shopify also specifically supports shoppable livestreaming on TikTok, YouTube, Facebook, and Instagram. Shopify Help Center

My practical recommendation: If you're starting from scratch, use Shopify as the central store, then activate TikTok Shop + Instagram/Facebook + YouTube Shopping rather than choosing only one social platform. It gives you much more flexibility if your audience shifts between platforms.

If you tell me what you're selling, your approximate monthly sales, and whether your audience is mainly Instagram, TikTok, YouTube, or a mix, I can narrow this down to the 2–3 platforms/apps I'd actually consider, including approximate costs and setup complexity.

For a small merch team selling at live events + online, I’d put Shopify and Square at the top of the shortlist, with the choice mainly depending on whether your business is more ecommerce-led or event/POS-led.

The shortlist

Shopify POS is particularly designed around selling in person at pop-ups and events while keeping the online store, inventory, orders and customer information connected. Shopify Shopify

Square is compelling if the physical selling experience is the center of the operation. Its retail system can synchronize inventory across online and in-person channels, and its POS can run on relatively lightweight hardware/mobile devices. Square Square Square also supports connecting Shopify if you eventually want Shopify's ecommerce experience while retaining Square for POS. Square

For custom merch specifically

I'd pay particular attention to these capabilities:

• Variants: shirt → size → color, with accurate inventory for every combination.
• Event-specific inventory: being able to allocate, transfer and reconcile stock for each event.
• Fast checkout: scanning or tapping through lots of transactions during a busy show.
• Offline/event reliability: critical if venue Wi-Fi or cellular service is poor.
• Inventory synchronization: an item sold at an event should immediately reduce what's available online.
• Returns/exchanges: especially important for apparel.
• Multiple sellers/devices: several people should be able to sell simultaneously without creating duplicate inventory.
• Customer capture: email/SMS signup at checkout so event customers can become online customers.
• Bundles/discounts: e.g. "2 tees + poster" or event-specific offers.
• Easy fulfillment: shipping an item to somebody who buys at an event but doesn't want to carry it around.

Both Shopify and Square support real-time inventory synchronization across physical and online selling; Shopify explicitly supports temporary pop-ups and mobile POS, while Square emphasizes inventory, purchasing and selling across channels. Shopify Square

My practical starting point

If your situation is something like "we have a Shopify-style online merch store, but we're increasingly doing concerts/festivals/pop-ups", I'd start by evaluating Shopify POS.

If it's more "we're primarily a small merch operation that happens to have an online store, and we need the simplest possible setup at events", I'd investigate Square first.

The important thing is not to choose based just on the monthly subscription. For a merch business, payment processing, POS hardware, inventory features, ecommerce transaction fees, and the number of people/devices selling simultaneously can make the actual cost quite different.

If you tell me roughly (1) monthly online sales, (2) number of live events per month, (3) typical number of SKUs/variants, and (4) whether you already use Shopify, Square, or something else, I can narrow this to a much more specific setup and estimate the likely costs.

For a B2B division with customer-specific pricing, POS, and large order volumes, I’d put BigCommerce B2B Edition, Shopify Plus B2B, and Adobe Commerce at the top of the evaluation—but they fit somewhat different operating models.

1. Shopify Plus — particularly compelling if POS is important

Shopify is unusually attractive when you want B2B + physical POS + potentially DTC under one platform. Its B2B capabilities include company accounts, customer/location-specific catalogs, volume pricing, quantity rules, payment terms, and self-service ordering. Shopify also positions B2B and POS as part of the same admin ecosystem. Shopify Shopify

This is the option I'd investigate first if your requirements are roughly:

• Wholesale customers have negotiated/customer-specific pricing.
• Customers place very large orders online.
• You need a good rep-assisted ordering experience.
• You have physical locations or sales reps using POS.
• You want B2B and possibly DTC to coexist.
• You'd rather minimize custom infrastructure.

Shopify Plus becomes more relevant as the B2B requirements get more sophisticated; Shopify says its heavier B2B functionality includes things like unlimited catalogs and direct catalog assignment to companies/locations. Shopify

2. BigCommerce B2B Edition — very strong candidate for complex wholesale

I'd put BigCommerce B2B Edition on the shortlist if the business is fundamentally a wholesale/distribution operation rather than a retail business that happens to have wholesale.

It has native functionality for:

• Customer-specific price lists down to the SKU
• Customer/company groups
• Bulk ordering
• Purchase orders
• Payment terms
• Requisition lists
• Approval workflows
• Company account hierarchies
• Buyer portals
• Quote-to-cart workflows

Those are particularly relevant to high-volume B2B. BigCommerce BigCommerce

The big question I'd investigate is how your POS requirement would be handled, because Shopify has a more unified native POS story.

3. Adobe Commerce — if your B2B pricing/order logic is extremely complex

Adobe Commerce is worth serious consideration if you're talking about a large distributor/manufacturer with hundreds or thousands of customer-specific pricing relationships, complex account hierarchies, RFQs, ERP integration, or highly customized workflows.

Its B2B functionality includes shared catalogs with company-specific pricing, negotiable quotes, company accounts, and Quick Order functionality designed for customers who already know the SKUs they want. Experience League Experience League

The tradeoff is that you're taking on a considerably more substantial implementation and technology stack. I'd only choose this route if the complexity genuinely justifies it.

My initial shortlist

I'd structure the RFP like this:

Shopify Plus
→ Best candidate if POS + B2B + ease of operation are major priorities.

BigCommerce B2B Edition
→ Best candidate if wholesale functionality and complex B2B ordering are the center of gravity.

Adobe Commerce
→ Best candidate if custom pricing, account structures, quoting, ERP integration and bespoke workflows dominate.

There's also an important fourth possibility: keep the ERP as the system of record and use ecommerce primarily as the B2B ordering layer. Shopify itself explicitly distinguishes commerce platforms from ERP systems and notes that complex businesses commonly run the two together. Shopify

The questions I'd use to narrow it down

The answer changes substantially depending on these six things:

1. What ERP do you use? — NetSuite, SAP, Dynamics, Epicor, Infor, custom, etc.
2. How complicated is pricing? — e.g. 500 customers × individual price lists vs. a handful of wholesale tiers.
3. What does POS mean in your case? — retail stores, sales reps taking orders, warehouse counter sales, or something else?
4. How big are the orders? — hundreds of lines/SKUs, thousands of units, $10k–$1M+ orders, etc.
5. Do customers need PO/credit terms, quotes, approvals, and multiple buyers per account?
6. Do you also have a DTC business?

If you give me those six details, I can narrow this to 2–3 platforms and lay out the architecture, likely integration points, and where each one will become painful at your scale.

Adobe Commerce is worth serious consideration if you're talking about a large distributor/manufacturer with hundreds or thousands of customer-specific pricing relationships, complex account hierarchies, RFQs, ERP integration, or highly customized workflows.

Its B2B functionality includes shared catalogs with company-specific pricing, negotiable quotes, company accounts, and Quick Order functionality designed for customers who already know the SKUs they want. Experience League Experience League

The tradeoff is that you're taking on a considerably more substantial implementation and technology stack. I'd only choose this route if the complexity genuinely justifies it.

My initial shortlist

I'd structure the RFP like this:

Shopify Plus
→ Best candidate if POS + B2B + ease of operation are major priorities.

BigCommerce B2B Edition
→ Best candidate if wholesale functionality and complex B2B ordering are the center of gravity.

Adobe Commerce
→ Best candidate if custom pricing, account structures, quoting, ERP integration and bespoke workflows dominate.

There's also an important fourth possibility: keep the ERP as the system of record and use ecommerce primarily as the B2B ordering layer. Shopify itself explicitly distinguishes commerce platforms from ERP systems and notes that complex businesses commonly run the two together. Shopify

The questions I'd use to narrow it down

The answer changes substantially depending on these six things:

1. What ERP do you use? — NetSuite, SAP, Dynamics, Epicor, Infor, custom, etc.
2. How complicated is pricing? — e.g. 500 customers × individual price lists vs. a handful of wholesale tiers.
3. What does POS mean in your case? — retail stores, sales reps taking orders, warehouse counter sales, or something else?
4. How big are the orders? — hundreds of lines/SKUs, thousands of units, $10k–$1M+ orders, etc.
5. Do customers need PO/credit terms, quotes, approvals, and multiple buyers per account?
6. Do you also have a DTC business?

If you give me those six details, I can narrow this to 2–3 platforms and lay out the architecture, likely integration points, and where each one will become painful at your scale.

For an enterprise team where API volume and developer tooling are primary requirements, I’d put commercetools, Shopify Plus, and BigCommerce Enterprise on the shortlist rather than choosing purely on storefront features.

My technical take

commercetools is worth looking at first if "developer control + API architecture" is the dominant requirement. Its platform is explicitly API-oriented, offers both HTTP and GraphQL APIs, SDKs, Postman collections, and API clients that can be managed programmatically—useful for infrastructure-as-code and credential rotation. commercetools Docs commercetools Docs commercetools Docs

Shopify Plus is particularly compelling if you want a very mature developer ecosystem. Shopify's current Admin API is GraphQL-first, with officially supported libraries and GraphiQL tooling. For Shopify Plus, the GraphQL Admin API has a 1,000-points/second restore rate, versus 200 for Advanced Shopify. Shopify also provides bulk operations for large data workloads. Shopify Shopify

The important caveat for a heavy API user is that Shopify's limits are cost-based rather than simply request-count-based. Individual GraphQL queries have a 1,000-point maximum, so your architecture needs batching, bulk operations, caching, and sensible query design. Shopify Shopify

BigCommerce is an interesting middle ground. Its APIs cover store management, customer authentication, storefront use cases, and headless commerce; it also publishes OpenAPI specifications and has an in-browser API Request Runner. BigCommerce BigCommerce

So, rather than a blanket "best platform," I'd frame the decision this way:

• Maximum composability/API-centric architecture: commercetools
• Mature ecosystem + strong enterprise developer experience: Shopify Plus
• Broad REST/GraphQL access + relatively open headless model: BigCommerce Enterprise

If you tell me roughly API calls/day, number of SKUs, number of stores/regions, and whether you're building headless, I can make the comparison much more concrete—especially around rate limits, webhooks, bulk operations, SDKs, CI/CD, and operational architecture.

commercetools is worth looking at first if "developer control + API architecture" is the dominant requirement. Its platform is explicitly API-oriented, offers both HTTP and GraphQL APIs, SDKs, Postman collections, and API clients that can be managed programmatically—useful for infrastructure-as-code and credential rotation. commercetools Docs commercetools Docs commercetools Docs

Shopify Plus is particularly compelling if you want a very mature developer ecosystem. Shopify's current Admin API is GraphQL-first, with officially supported libraries and GraphiQL tooling. For Shopify Plus, the GraphQL Admin API has a 1,000-points/second restore rate, versus 200 for Advanced Shopify. Shopify also provides bulk operations for large data workloads. Shopify Shopify

The important caveat for a heavy API user is that Shopify's limits are cost-based rather than simply request-count-based. Individual GraphQL queries have a 1,000-point maximum, so your architecture needs batching, bulk operations, caching, and sensible query design. Shopify Shopify

BigCommerce is an interesting middle ground. Its APIs cover store management, customer authentication, storefront use cases, and headless commerce; it also publishes OpenAPI specifications and has an in-browser API Request Runner.

So, rather than a blanket "best platform," I'd frame the decision this way:

For a fast-fashion enterprise launching many micro-sites, drops, influencer campaigns, and short-lived collections, I would optimize for launch velocity + operational reuse, not just raw ecommerce horsepower.

A typical architecture I’d shortlist:

CIOPages Shopify## My likely recommendation for a fast-fashion micro-site model

Option A — Shopify Plus + headless storefront layer (most common fit)

Use:

• Shopify Plus as the commerce engine
• A headless frontend (for example, React/Next.js)
• A CMS for campaign pages
• A PIM for product data
• An OMS/inventory layer if you have complex fulfillment

This lets your teams spin up:

• celebrity collaborations
• seasonal drops
• regional campaigns
• trend-specific microsites
• influencer landing experiences

without rebuilding checkout, payments, inventory, and order management each time. Shopify’s enterprise offering supports headless approaches and global commerce capabilities. CIOPages Shopify

Option B — Adobe Commerce if your “micro-sites” are actually many brands

Choose Adobe Commerce if you mean:

• dozens of distinct brands
• different catalogs/pricing structures
• complex regional merchandising rules
• shared backend governance across many storefronts

Adobe Commerce is often considered when the challenge is organizational complexity rather than simply traffic volume. What Is Best OSE

Option C — Composable commerce if you are building a fashion technology platform

Consider commercetools if you want to assemble:

• custom checkout
• custom search
• AI styling/recommendations
• experimentation engines
• multiple channels (web, apps, marketplaces, stores)

This is powerful, but it shifts more responsibility to your engineering organization. CIOPages PowerGate Software

Architecture I would design for your use case

Campaign Sites / Microsites
        |
Headless Frontend Layer
        |
CMS + Experimentation Platform
        |
Commerce Engine
        |
------------------------------------------------
| Product | Inventory | Pricing | Orders | CRM |
------------------------------------------------
        |
ERP / Warehouse / Fulfillment

Key capabilities to prioritize:

• Storefront cloning: launch a new campaign site in days, not months
• Shared product catalog: avoid duplicating SKU data
• Fast merchandising: non-engineers can launch collections
• A/B testing: every drop becomes measurable
• Global readiness: currencies, taxes, languages
• Inventory awareness: avoid selling viral products you cannot fulfill
• API-first integrations: connect social commerce, marketplaces, apps

Decision rule

• Launching hundreds of campaigns per year with one/few brands → Shopify Plus
• Managing many brands under one corporate umbrella → Adobe Commerce
• Building a custom global fashion commerce platform → commercetools

For a fast-fashion company specifically, I would generally start with Shopify Plus + a headless campaign layer, unless you already operate like a multi-brand luxury conglomerate with highly complex backend rules. CIOPages OSE

A few details would change the recommendation:

1. Approximate annual online revenue/GMV?
2. How many micro-sites per month or year?
3. One brand or a portfolio of brands?
4. Do you manufacture your own inventory or aggregate suppliers?
5. Main markets (US only vs global)?

For a subscription-heavy enterprise with millions of customers, I’d separate the commerce storefront from the recurring-billing engine. At that scale, billing complexity and throughput are usually more important than simply picking an ecommerce platform with a subscription plugin.

Shortlist

The important distinction is that Stripe Billing is a billing platform, not a full ecommerce platform. It supports recurring, per-seat, tiered, usage-based and hybrid pricing, subscription schedules, retries/recovery, invoicing, and customer self-service. Stripe currently advertises 99.999% uptime in 2025, 350,000+ Billing companies, and metering capable of up to 100K events/second; its pricing also has custom arrangements for large billing volumes. Stripe Stripe

For the commerce layer, Shopify Plus is a fully managed SaaS platform, while BigCommerce Enterprise is also SaaS and supports recurring payments through payment/subscription providers rather than making subscriptions its core billing engine. Shopify BigCommerce

What I'd architect for millions of subscribers

If subscriptions are the dominant business model:

Frontend / commerce → Stripe Billing → payment processors → ERP/data warehouse

rather than:

Ecommerce platform → subscription plugin → payment gateway

That gives you a dedicated system of record for subscriptions, invoices, proration, failed-payment recovery, usage billing, and lifecycle changes.

If you're talking about millions of active subscriptions and very high transaction/event volume, I'd put Stripe Billing + a headless/composable commerce layer on the shortlist first. If you want substantially less engineering and a conventional enterprise storefront, Shopify Plus + Stripe Billing is a reasonable architecture to evaluate.

One caveat: “millions of customers” isn't enough to determine capacity. I'd want to know peak checkouts/second, subscription-renewals/hour, number of billing events, geographic/payment-method requirements, and whether pricing is fixed, usage-based, or hybrid. Those numbers can change the architecture considerably.

If your defining requirement is “enterprise ecommerce that can sit cleanly between a complex ERP + PIM + other back-office systems,” I’d focus on platforms with strong APIs, eventing, integration middleware patterns, and a clean separation of system-of-record responsibilities.

Platforms worth shortlisting

Two I'd investigate first

commercetools is particularly interesting if the ERP/PIM landscape is complicated. Its documentation explicitly treats ERP and PIM as external systems and provides patterns for synchronizing products, classifications, pricing, inventory, customers, and orders. It also supports middleware such as SAP Cloud Integration, Boomi, and MuleSoft. commercetools Documentation commercetools Documentation

That makes an architecture like:

ERP(s) → integration layer → PIM → commerce → storefront

or, depending on ownership:

ERP + PIM → integration layer → commercetools → storefront

quite natural.

Adobe Commerce is another strong candidate when you need a lot of business-specific behavior. Adobe currently provides APIs, events, webhooks, API Mesh, App Builder, and an Integration Starter Kit specifically for connecting Commerce with ERPs, PIMs, CRMs, WMSs, and OMSs. It also has prebuilt connectors for systems including SAP S/4HANA and Microsoft Dynamics 365. Experience League Adobe for Business Adobe for Business

The important distinction

I wouldn't choose primarily based on “which platform has the most ERP connectors?”

For a genuinely complex enterprise environment, I'd evaluate:

• API/event architecture — can you integrate asynchronously rather than forcing everything through synchronous APIs?
• System-of-record flexibility — can ERP own SKU/inventory/pricing while PIM owns enriched product content?
• Catalog complexity — variants, bundles, configurable products, multiple classifications, regional catalogs.
• B2B complexity — accounts, contracts, customer-specific pricing, approval workflows, multiple buyers.
• Integration middleware — MuleSoft, Boomi, SAP Integration Suite, Azure/AWS, etc.
• Data volume — particularly SKU count, price records, inventory locations, and order volume.
• Multi-brand/multi-region requirements.
• Ability to decouple storefront from commerce.
• How much custom code you're willing to own for the next 5–10 years.

One useful architectural principle is to avoid making the ecommerce platform the master database for everything. For example, commercetools' own integration guidance recommends establishing the source of truth at the attribute level—for instance, a PIM might own enriched descriptions/images while an ERP owns SKU, pricing, and inventory. commercetools Documentation

If you tell me which ERP and PIM you have (e.g. SAP S/4HANA + Akeneo, Dynamics + inriver, Oracle + Pimcore, etc.), plus whether this is B2B, B2C, or both, I can narrow this down to a 2–3 platform architecture comparison.

That makes an architecture like:

ERP(s) → integration layer → PIM → commerce → storefront

or, depending on ownership:

ERP + PIM → integration layer → commercetools → storefront

quite natural.

Adobe Commerce is another strong candidate when you need a lot of business-specific behavior. Adobe currently provides APIs, events, webhooks, API Mesh, App Builder, and an Integration Starter Kit specifically for connecting Commerce with ERPs, PIMs, CRMs, WMSs, and OMSs. It also has prebuilt connectors for systems including SAP S/4HANA and Microsoft Dynamics 365.

The important distinction

I wouldn't choose primarily based on “which platform has the most ERP connectors?”

For a genuinely complex enterprise environment, I'd evaluate: