Using Siren for Marketplaces

Siren powers the commission and royalty side of multi-vendor marketplaces. It tracks which vendor owns which product, calculates per-sale royalties, and organizes payouts. What Siren doesn’t do is marketplace UX. It isn’t a storefront plugin, doesn’t handle vendor onboarding flows, and doesn’t render a “shop by vendor” page for you.

That’s usually where the first question shows up: “Does Siren replace WC Vendors, or do I run both?” The honest answer is that Siren is the commission engine and the product-ownership data layer, and the storefront UX is a separate concern. You can pair Siren with a marketplace plugin like WC Vendors or Dokan, or you can write a small amount of custom WordPress code and skip the marketplace plugin entirely. Both paths work, and which one fits depends on how much vendor self-service you need.

This page walks through what Siren handles natively, where the gaps are, and the two realistic routes to a working marketplace.

It’s aimed at operators who already have (or plan to have) a WordPress site with WooCommerce, LifterLMS, EDD, or NorthCommerce powering the store. The assumption is that you need a commission engine that can handle multi-vendor revenue splits without forcing you to change your existing storefront.

What Siren handles natively

Product ownership is the foundation. Every WooCommerce product (or LifterLMS course, or EDD download) can have a collaborator owner, set via a field Siren adds to the product edit screen. When that product sells, Siren attributes the sale to the owning collaborator through the Collaborator Product Sold trigger. This is the same mechanism the product royalty program recipe uses, and it’s the right fit for marketplaces because attribution happens automatically at checkout without anyone needing to click a referral link.

That “no referral link” part is important. In a standard affiliate program, the customer has to arrive via a tracking URL or use a coupon code for the attribution to fire. In a marketplace, the customer is just shopping, and they probably don’t know (or care) which vendor made the thing they’re buying. Product ownership sidesteps the whole referral problem by attributing based on what was sold rather than how the customer got there.

Per-sale royalty calculation uses the Percentage of Transaction incentive structure. Set the percentage that matches your vendor/platform split (70% to the vendor and 30% to the platform is common for handmade marketplaces, 50/50 for curated design marketplaces, and so on), and Siren runs the math on every sale. Commissions are calculated on line item totals, so shipping and taxes stay out of the calculation.

The multi-vendor order case is where marketplace commission engines get interesting. If a customer buys three items from three different vendors in one order, each vendor earns their percentage on their specific line item. Nobody competes with anyone else for the same sale. This is what the “every binding wins” resolver does in the marketplace vendor commission recipe, and it’s the critical difference between a marketplace program and a standard affiliate program where only one collaborator can earn per transaction.

Vendor tiers are handled with program groups. If your marketplace has “premium vendors earn 80%, standard vendors earn 70%” you can run two programs and enroll each vendor in the one that matches their tier. You can also use a single program and override the rate on individual collaborator profiles, but separate programs are cleaner when you want to see premium versus standard payouts at a glance. Program groups also let you switch vendors between tiers without having to rewrite their individual settings: move a vendor from the standard program to the premium program and the new rate kicks in immediately for future sales.

Payouts follow Siren’s standard fulfillment workflow. Group obligations by collaborator, export a CSV, mark paid in bulk. If you’re paying 80 vendors on the first of every month, this is the same flow Siren uses for any other program.

The only thing that’s marketplace-specific is the sheer volume of obligations (one per vendor per period), and Siren’s fulfillment view handles that fine. Sort by collaborator, review the totals, export. See How to Pay Collaborators for the step-by-step.

Refunds in marketplaces work the same way as refunds in any Siren program. When a customer refunds an order, the conversion attached to that order is rejected, and if the obligation hasn’t been fulfilled yet, it’s rejected too. The refund pipeline has more detail. The practical implication for marketplaces is that you should hold off on paying vendors until your refund window has passed. If your marketplace offers a 30-day return policy, wait at least 30 days between order and payout so refunds have time to roll in before money leaves your account.

What Siren doesn’t handle

Here’s the list of things you’ll need to cover some other way:

• Vendor storefronts (the “shop by vendor” page that lists all products from one vendor)
• Vendor self-service product submission
• Vendor profile pages and identity management
• Vendor onboarding application flows
• Tax form collection and 1099 generation
• Vendor-specific email automation

None of these are close to shipping. They’re deliberately out of scope because they’re things WordPress (or a dedicated marketplace plugin) already handles well, and Siren’s job is the commission engine. If any of these are must-haves for your marketplace, you’ll pair Siren with another tool to cover them. The rest of this page walks through what that pairing looks like.

The two paths to a vendor storefront

Path A: Use a marketplace plugin alongside Siren

WC Vendors, Dokan, and similar plugins handle the storefront, vendor identity, and product management. Siren handles commission tracking. They coexist: the marketplace plugin manages the vendor-facing UX (dashboards, product submission, storefront pages), and Siren manages commission calculation and payouts. The mental model is “marketplace plugin for the front-end, Siren for the money.”

There’s some overlap. Both WC Vendors and Siren want to know which products belong to which vendor. That’s fine, because Siren’s product ownership field can be set independently of whatever the marketplace plugin does. You can even script the assignment so the two systems stay in sync automatically, though for most sites a one-time import is enough.

You might wonder why not just use WC Vendors for both the storefront and the commissions. The answer is that WC Vendors’ commission engine is less flexible than Siren’s. It handles flat percentages and not much else. If you want tiered commissions, bonus structures, program groups with resolver logic, or anything more complex than “vendor gets X percent of sales,” Siren is the stronger tool. Running both gives you WC Vendors’ storefront and Siren’s commission engine, which is usually the right call for marketplaces that need more than a flat commission rate.

This path is the right call when you need vendor self-service. If vendors should log in, add their own products, edit their own descriptions, and manage their own inventory without you touching anything, a marketplace plugin gets you there faster than writing custom code.

Path B: Build a vendor storefront with a small WordPress customization

Siren’s product ownership is stored as standard WordPress data. That means you can query it with WP_Query and build a vendor storefront page yourself. A custom template page can show “all products owned by this collaborator” by passing the collaborator’s ID to a meta query, looping through the results, and rendering whatever layout your theme wants. This is maybe 50 lines of PHP for a basic storefront, and it gives you complete control over the UX without depending on a marketplace plugin.

The query looks roughly like this in concept: load the collaborator record by ID or slug, pull their linked product IDs from Siren’s ownership metadata, then feed those IDs into a standard WP_Query to render them as a product grid. Anyone comfortable with WordPress theme development can put this together in an afternoon. The rest (pagination, filtering by category, sorting by price) is all standard WordPress patterns you probably already use elsewhere on the site.

This path fits sites that already have a custom theme and want a tightly-integrated vendor experience. If your marketplace has a strong visual identity and you’d rather control every pixel of the vendor page layout, a custom template is the cleanest route. The trade-off is that vendors can’t log in and edit their own products. You (or your team) add products on their behalf. For curated marketplaces where every listing is reviewed before going live, this is usually how the workflow runs anyway, so the lack of vendor self-service isn’t actually a constraint.

Bulk product ownership assignment

For a marketplace with hundreds or thousands of products, assigning ownership one product at a time through the WordPress admin is slow. There’s no bulk-assign UI in Siren today, which means you’ll need a small workaround for the initial import.

The fastest route is to script the assignment via Siren’s REST API. A few lines of PHP (or a WP-CLI script) can read your products list and post ownership records. If you have a CSV of “product SKU, vendor collaborator ID” this is a one-afternoon job for anyone comfortable with WordPress development. The ownership records persist just like manual assignments do, so once the script runs, everything behaves the same from that point forward.

If you’d rather not write the script yourself, describe your situation to Beacon and ask for a one-off import script. Beacon can generate the PHP and walk you through running it. For most marketplaces, the initial import is a one-time job, so the script is throwaway code that doesn’t need to become part of your permanent codebase.

Bulk product ownership assignment is on the roadmap as a future feature, so this workaround may not be necessary forever. For now, the REST API route is the fastest path from zero to a fully-assigned catalog.

Splitting commission with an introducer

Some marketplaces want a third party to earn commission alongside the vendor. An agent who recruited the vendor, a marketing partner who drove traffic to that vendor’s page, a curator who vetted the vendor for inclusion. In this model, the vendor gets their usual 70%, the marketplace keeps a smaller cut, and the introducer takes the remainder.

Siren can handle this with program groups or with parallel programs, depending on how the attribution should work. If the introducer should always earn a flat percentage on every sale from the vendors they introduced, run a second program that fires on the same “collaborator product sold” trigger but targets the introducer’s collaborator profile. You’d need to set up a custom attribution rule so the introducer is credited based on the vendor ownership relationship, which usually requires a small custom integration.

For most marketplaces, this level of complexity isn’t worth it. Pay the introducer a flat fee per vendor signup instead, tracked manually as a one-time obligation. It’s simpler, easier to explain to everyone involved, and doesn’t require any custom code.

A worked example

Picture a handmade goods marketplace with 50 vendors, 1,500 products, and $30,000/month in GMV. The business split is 70/30 (vendor/platform). The founder wants automated commission tracking and a once-a-month payout workflow.

The Siren setup:

1. Install the marketplace vendor commission recipe. This creates the program with a 70% Percentage of Transaction incentive and the “every binding wins” resolver (so every vendor with a product in an order gets paid, not just one).
2. Add each vendor as a collaborator.
3. Assign products to vendors via a one-time REST API import script. Roughly 1,500 products, a few hundred lines of CSV, one afternoon of work.
4. On the first of each month, generate a fulfillment, review the obligations by vendor, export the CSV, and upload it to whatever ACH tool the marketplace uses.

The front-end remains whatever the site already had. No marketplace plugin swap, no vendor dashboard rewrite. The commission engine slots in behind the existing storefront and runs quietly.

A few numbers for context. At $30,000/month in GMV with a 70/30 split, the platform is keeping $9,000/month and paying out $21,000 across 50 vendors. Average per-vendor payout is about $420, though in practice it’ll be heavily skewed (a few top vendors earning most of the pool, a long tail earning smaller amounts). Siren’s fulfillment export handles that distribution fine: obligations of any size roll up into the same CSV, and you can filter out vendors below a minimum payout threshold if you want to roll small amounts into the next cycle.

When to pick this over a dedicated marketplace plugin

If you’re deciding between Siren + WordPress versus a dedicated marketplace SaaS (something like Arcadier or Sharetribe), the trade-off is control versus speed. Marketplace SaaS platforms ship with vendor dashboards, application flows, and tax form collection out of the box. Siren on WordPress gets you the commission engine and leaves everything else to you. For a marketplace that needs to ship in two weeks with 200 vendors, the SaaS platform is faster. For a marketplace that already has a WordPress site and wants full control over the experience, Siren is the right engine.

The other trade-off is cost. Marketplace SaaS typically charges per-vendor or takes a percentage of GMV. Siren’s pricing is flat, which means as your marketplace grows, your Siren cost stays the same while the SaaS cost scales with you. For marketplaces above a certain GMV, this difference alone pays for the additional setup work.

Closing pointers

For the deeper concept, read What is an Engagement and Collaborator Product Sold. For the ready-to-apply configuration, see the marketplace vendor commission recipe or the product royalty program recipe. For payout workflow details, see How to Pay Collaborators. If your marketplace has a non-standard configuration (multiple tiers, line-item filters by SKU, conditional rates based on product category), describe it to Beacon and ask for a custom recipe.