DashCommerce for marketplaces

Why build a marketplace?

Single-vendor stores are simple: money comes in, one party gets paid, done. Marketplaces are harder because the money has to split. A shopper buys three items from three vendors, and each vendor needs their cut minus a platform fee, minus Stripe’s processing, on a schedule they can predict. Refunds, disputes, payouts, and tax reporting all have to respect that split.

The standard answer to “how do I build a marketplace” in 2026 is Stripe Connect. Stripe handles the KYC, the payout scheduling, the 1099 generation, and the money movement. What Stripe doesn’t handle is your storefront, your cart, your admin, or your product catalog — that’s where a commerce layer lives. DashCommerce is the layer that plugs Connect into an Astro storefront without asking you to write the PaymentIntent wiring by hand.

What Stripe Connect gives you

Stripe Connect is Stripe’s multi-party payments product. Three mechanics matter most for a marketplace:

transfer_data[destination] — when you create a PaymentIntent, you name the Connect account that should receive the funds. Stripe moves the money to that account’s balance when the payment captures. No separate transfer API call, no reconciliation job; it happens as part of the charge.

application_fee_amount — on the same PaymentIntent, you specify how much the platform (you) keeps. Stripe deducts this from the vendor’s portion and routes it to your platform balance. If you take a 10% cut on a $100 sale, you set application_fee_amount: 1000 (cents) and transfer_data[destination] to the vendor’s account; Stripe puts $90 on the vendor’s balance and $10 on yours, minus processing fees.

Express vs Standard accounts — Express is the path of least resistance: Stripe hosts the onboarding flow, collects the KYC, and gives the vendor a lightweight dashboard scoped to their marketplace activity. Standard gives vendors a full Stripe account under your platform’s umbrella — more power, more complexity. Most indie marketplaces should use Express. DashCommerce supports both but defaults to the Express flow for new vendor invites.

These three primitives are what “Stripe Connect integration” means in practical terms. DashCommerce wires all three into the checkout and admin so you don’t write the boilerplate.

How DashCommerce plumbs Connect into a storefront

The data model changes in three places:

1. Products carry a vendor ID. Every product in the products collection is assigned to exactly one vendor. The storefront renders the vendor badge on product cards; the admin lets you filter orders by vendor; the cart groups line items by vendor for display.
2. Vendors are first-class records. The vendors collection stores the Connect account ID, the platform fee percentage (or a null that falls back to the global default), contact info, activation state, and metadata Stripe hands back from onboarding.
3. PaymentIntent creation splits by vendor. When a cart has items from multiple vendors, DashCommerce creates multiple PaymentIntents — one per vendor — each with its own transfer_data and application_fee_amount. The checkout UI shows this as a single purchase, but the underlying money movement is per-vendor. This is important because Stripe’s transfer_data[destination] is a single-destination field; a marketplace with multi-vendor carts needs multiple PaymentIntents.

The platform fee is calculated at PaymentIntent creation time based on each vendor’s configured percentage. Change a vendor’s fee tomorrow and tomorrow’s sales use the new rate; already-captured charges are final.

Three marketplace shapes that fit

Creator marketplaces — platforms selling digital downloads, courses, or physical goods from independent creators under a shared brand. Think of a niche Gumroad competitor for a specific vertical: indie musicians, font designers, course authors, worldbuilding artists. Each creator signs up as a vendor, onboards to Stripe Express, and starts listing products. Platform takes a flat fee per sale.

B2B wholesaler marketplaces — curated storefronts with a small number of verified suppliers (ten to thirty) listing products for resellers or small businesses. Higher average order values, longer vendor relationships, often custom fee tiers for featured or strategic suppliers. DashCommerce’s per-vendor platform fee override is the feature that makes this shape work without code changes.

Local goods aggregators — regional marketplaces of makers, farmers, or artisans sharing one storefront. Shoppers buy from multiple vendors in a single checkout; platform keeps a fee per sale to cover site operations. Often combined with shared fulfillment (a single pickup location) or vendor-specific shipping zones — DashCommerce’s shipping engine supports both.

These are the three shapes we’ve seen in the wild. They share a common assumption: under 50 vendors, straightforward splits, and a platform operator who can handle vendor support directly rather than through a ticket system.

Vendor lifecycle

DashCommerce models the vendor journey as five states:

1. Invited. Admin sends an invitation email with a signed onboarding link. Email template is in dashcommerce-merge-seed and can be customized.
2. Onboarding. Vendor clicks the link, lands on Stripe’s hosted Connect onboarding, submits their KYC. Stripe redirects back when done.
3. Activated. DashCommerce marks the vendor active when Stripe confirms the account can accept charges and payouts. Activation email is sent.
4. Listing. Vendor’s products can now appear on the storefront. Admin can scope product creation to the vendor.
5. Payout. Stripe runs the payout schedule the vendor configured. DashCommerce surfaces payout history metadata in admin for support visibility.

Deactivation is a single-field toggle — flip a vendor to inactive, their products hide from the storefront, no new orders can be placed. Stripe Connect controls whether they can still receive payouts for already-captured charges.

The honest scale ceiling

Running pre-1.0 software on a solo store is one thing: if a bug shows up, one merchant deals with it, and the blast radius is your own business. Running pre-1.0 software on a marketplace is different — every vendor on your platform is affected by the same bug, and they’re external businesses with their own obligations to their customers.

DashCommerce is on npm at v0.1.3. Every marketplace feature described on this page is shipped and working, but the software is still evolving and minor versions may include breaking changes. If you’re standing up a marketplace, plan for it:

• Pin the version in package.json exactly — no carets, no tildes.
• Test upgrades on a staging branch with a cloned vendor dataset before production.
• Subscribe to the changelog and read it before every @dashcommerce/core bump.
• Have a rollback plan that includes both code and database schema.

This is true of any pre-1.0 dependency in a multi-tenant context. The answer is not “don’t use pre-1.0 software” — plenty of real businesses run on v0.x code — but “operate it like you understand the tradeoff.”

Refunds, disputes, reversals

The money flow through a marketplace is more complex than a solo store because the platform and the vendor both touched the transaction.

Refunds. A shopper requests a refund; your admin reverses the order via Stripe’s Refund API. By default, the refund comes from the vendor’s Connect balance, and the platform fee is reversed proportionally — you return what you took, the vendor returns what they got. Partial refunds work the same way at a pro-rated share. If your policy says the platform absorbs refunds, you can configure the reversal behavior per order.

Disputes. Customer files a chargeback with their bank; Stripe surfaces it in the Connect dashboard. The evidence-submission flow lives in Stripe — uploading receipts, delivery confirmations, whatever proves the charge was legitimate. DashCommerce surfaces the dispute status on the order in admin so your ops team knows what’s open, but the chargeback workflow is Stripe’s, not DashCommerce’s.

Reversals. Edge cases — fraud, vendor misconduct, accidental double charges — sometimes require reversing a transaction outside the normal refund flow. You handle these in the Stripe dashboard; DashCommerce catches up via webhook and reflects the final state on the order record.

The pattern: Stripe owns money movement, DashCommerce owns storefront state, and the two reconcile via webhooks.

Tax, 1099s, compliance

Stripe generates 1099-K forms for Connect accounts that cross the IRS reporting threshold each year. Vendors access these directly from their Stripe Express dashboard — DashCommerce does not duplicate the form, and trying to is a bad idea because Stripe is the single source of truth for the transaction totals. If a vendor asks where their 1099 is, the answer is always “your Stripe dashboard.”

For non-US vendors or custom tax reporting, you’re on your own — that’s accounting stack territory, not commerce layer territory.

Sales tax on marketplace sales varies by jurisdiction. In some US states, marketplace operators are responsible for collecting and remitting sales tax on behalf of all vendors (marketplace facilitator laws). DashCommerce’s tax engine handles per-zone rates but doesn’t make the legal decision about who owes what — you do, with your accountant.

When DashCommerce is enough

• You’re running a 2-to-50 vendor marketplace with a simple flat or tiered percentage fee.
• You want source code, MIT license, and no monthly SaaS bill to a marketplace platform vendor.
• You already run an Astro or EmDash site and want commerce inside the same codebase.
• You’re comfortable with Stripe Connect as the foundation and happy to send vendors to Stripe’s Express dashboard for payout and tax details.
• You accept pre-1.0 software risk and have operational practices that match.

This is the shape of most indie marketplaces. If you match it, DashCommerce is a real option — the marketplace features are genuine, in core, and working today.

When you need Mirakl, Arcadier, or a custom build

• You have thousands of vendors and need a proper vendor support ticket system, not a founder-in-the-loop.
• You need complex vendor tier logic, A/B-tested commission structures, or programmatic fee changes based on vendor performance.
• You operate internationally and need marketplace-specific tax compliance across jurisdictions.
• Your marketplace is an enterprise product sold to other enterprises — Mirakl and Arcadier earn their license fees in that world.
• Your compliance environment requires SOC 2 / ISO 27001 on the commerce layer itself (not just the host).

Those aren’t DashCommerce’s lane, and pretending otherwise would be dishonest. DashCommerce is for the indie and mid-market marketplace shape — which is by far the most common shape, but not every shape.