Integration

WooCommerce MLM Plugin

WooCommerce is a capable storefront and WordPress is a poor place to run a commission engine. The integration that works keeps the store exactly where it is and moves the calculation, the trees and the payouts outside — for reasons that are about month-end load and plugin updates rather than about taste.

What you get

Outcomes operators report after moving onto the platform.

  • Orders post by webhook, with a sweep

    A WooCommerce webhook posts order create, paid, completed, refunded and cancelled, backed by a reconciliation sweep that catches deliveries WordPress dropped.

  • The engine is not a plugin

    Commission logic lives outside WordPress, so a plugin update on a Tuesday cannot change how people are paid, and a run cannot be killed by a PHP timeout.

  • WordPress users are not distributor records

    A WP user maps to a distributor; it does not define one. Genealogy, volume and payouts never live in wp_usermeta, where they cannot be queried at scale.

  • Volume per variation

    Commissionable and qualifying volume set on the product variation rather than derived from cart total, so coupons and shipping upgrades do not quietly pay commission.

  • Subscriptions post on success

    Recurring orders post volume when a billing cycle succeeds. Retries after a failed payment post once, not on every attempt.

  • No direct database writes

    The integration reads and writes through the WooCommerce REST API and hooks. Nothing writes into Woo tables behind its back, so upgrades stay routine.

How responsibility splits

Your storefront keeps what it is good at. We take over what it was never built to do.

WooCommerce keeps

  • Product catalogue, variations, pricing and coupons
  • Cart, checkout and payment gateways
  • Tax calculation and collection at checkout
  • Inventory, shipping and order fulfilment status
  • WordPress content, theme and the customer-facing experience
  • WooCommerce Subscriptions for recurring orders, where already in use

We take over

  • Distributor enrolment, agreement versioning and credential records
  • Placement and sponsorship trees, stored separately
  • Order attribution with a stated precedence order and an unattributed queue
  • Retail, preferred-customer and participant order classification
  • Plan rules, qualification, ranks and the commission run
  • Wallet ledger, payout batching, statements and tax documents

The architecture decision

There are two ways to add a compensation plan to WooCommerce, and the choice determines most of what happens afterwards.

Everything inside WordPress. A plugin that stores distributors as users, genealogy in post meta or a custom table, and computes commission on a wp-cron schedule. Cheap, quick, and it works until it does not.

WooCommerce as the storefront, the engine outside. Woo keeps everything it is good at. Orders flow out by webhook. The trees, the plan, the run, the wallet and the payouts live in an application built for them, and the distributor back office is its own thing.

We build the second, and the reasons are specific rather than architectural preference.

Why the engine goes outside

A commission run is a long job. PHP execution limits, request timeouts and shared hosting are a bad match for a process that must either complete or roll back cleanly. Runs need a queue, a resumable state and a machine that is not also serving your storefront on the day everyone checks their statement.

wp-cron fires when someone visits. It is not a scheduler; it is an approximation of one. Payout batches should not depend on traffic.

Plugin updates arrive on someone else’s schedule. WordPress sites are updated constantly, often automatically. Code that determines what people are paid should not change on a release cadence you do not control, and a plugin conflict should not be able to alter a rate.

The data model does not stretch. Genealogy queries at depth, volume roll-ups and rank evaluation against tens of thousands of positions need materialised volume and a schema designed for tree traversal. Volume in wp_usermeta is workable at five hundred positions and unusable at fifty thousand, and changing it later is a rewrite. The genealogy page explains what that model needs to look like.

Security surface. WordPress is the most attacked application on the public internet. Distributor identity documents and bank details are better held somewhere that is not also running a page builder.

What actually gets installed

A small companion plugin, doing three narrow things:

  1. Capturing the attribution parameter into the session and writing it as a cart attribute.
  2. Providing the distributor login handoff to the back office.
  3. Rendering the replicated page shell inside your theme, if you want replicated pages on the same domain.

Plus scoped REST API credentials and a set of webhook subscriptions. No theme edits are required for attribution, and nothing writes into WooCommerce tables directly — everything goes through the REST API and documented hooks, which is what keeps Woo and WordPress upgrades routine.

Attribution and classification

Attribution follows a stated precedence: authenticated distributor order, then assigned customer, then replicated link, then coupon code, then unattributed — with unattributed recorded and queued rather than absorbed into a house account.

Classification happens at order creation: retail sale, preferred customer, or participant purchase. That single field is what makes your retail proportion a report rather than a reconstruction, and it is the main reason this is not an affiliate plugin. The ecommerce page works through both in detail.

Volume, coupons and subscriptions

Volume is set per product variation — fixed or proportional — with qualifying volume held separately from commissionable volume. Anything that should not pay is set to zero explicitly: shipping upgrades, gift cards, fees, literature, sample packs.

WooCommerce Subscriptions renewals post volume on success only. Three failed retries followed by a successful charge post volume once.

Migrating off an existing plugin

The products and customers are easy. The history is the work, and it splits into three:

DataHow it comes across
Distributor records and statusmigrated directly, with agreement versions where they exist
Genealogymigrated; if only one tree was stored, the second is reconstructed where possible or set as an opening structure
Commission historymigrated as historical statements that continue to reconcile to what was paid

Where an existing plugin kept volume as a running total with no order-level detail, part of the history can only come across as an opening position. We will tell you which parts those are during scoping, because finding out afterwards is how a migration turns into a dispute.

For everything beyond WooCommerce — the REST API, the webhook model, and other storefronts — see the integration overview.

At a glance

RequirementsWordPress with WooCommerce, REST API enabled, HTTPS, and a webhook-capable host. No specific hosting tier required
InstallationA small companion plugin for attribution capture and distributor login, plus scoped REST credentials and webhook subscriptions
Attribution signalsReplicated link or subdomain, coupon code, cart session attribute, assigned-customer relationship, authenticated distributor order
Order syncWebhooks on create, processing, completed, refunded and cancelled, plus a fifteen-minute reconciliation sweep against order totals
Volume mappingPer product variation, as a fixed value or a percentage of line total, with commissionable and qualifying volume held separately
SubscriptionsWooCommerce Subscriptions supported; volume posts on each successful renewal, and self-service pause, skip and cancel are surfaced in the back office
Where commission runsOutside WordPress. Runs are queued, resumable and unaffected by PHP execution limits or wp-cron reliability
What is never syncedCustomer payment instruments. Card data stays with your gateway and does not enter the commission platform
FAQ

Questions operators ask before they switch

Straight answers on plan mechanics, migration risk and compliance. If yours is not here, ask us directly.

Why not run the commission engine as a WordPress plugin?

Four reasons, all practical. A commission run for a real distributor base is a long job, and PHP execution limits, shared hosting and wp-cron are the wrong foundation for a long job that must not half-complete. Plugin updates land on a schedule you do not control, and money-moving code should not change on someone else's release cadence. Genealogy queries at depth are not something the WordPress data model does well, and volume stored in usermeta stops being queryable somewhere in the low thousands of positions. And WordPress is the most attacked application surface on the internet, which is not where distributor bank details belong.

Does this replace our theme or checkout?

No. WooCommerce keeps the catalogue, cart, checkout, gateways, tax and fulfilment exactly as they are, and your theme is untouched. Attribution is captured from the link parameter and stored as a session and cart attribute, so nothing is injected into the checkout flow itself. The distributor back office is a separate application rather than a WordPress admin screen, which is deliberate: distributors should not have WordPress accounts, and a back office built as an admin page inherits every constraint of the admin.

We already have an MLM plugin. Can we migrate?

Usually yes, and the hard part is not the products or the customers, it is the history. Distributor records, both tree structures and past commission statements have to come across and keep reconciling, because a distributor will look up a statement from two years ago and it has to match what they were paid. Where an existing plugin stored only one tree, or stored volume as a running total with no order-level detail, some history can be carried as an opening position rather than recomputed, and we will tell you which parts fall into that category before the work starts rather than after.

How do coupons and discounts affect commission?

Only in the way you decide, because volume is set on the product variation rather than derived from what the cart charged. A coupon reduces revenue; it changes commissionable volume only if you configure volume as a percentage of line total. Shipping upgrades, gift cards, fees and sample packs are set to zero volume explicitly. This is worth doing carefully at setup, because the failure mode is a promotion that turns into an unplanned payout event — a discount code shared widely, and a commission run that pays on volume the margin no longer supports.

Ready to Transform Your Direct Selling Business?

Send us your plan rules and we will run a live commission cycle against them, on your numbers, before you commit to anything.

  • Configured in a sandbox before the call, usually within two business days
  • No slide deck and no card — you watch your own plan pay out
  • Your plan document stays confidential and is deleted on request

Prefer a longer conversation? Open the full enquiry form

required

Prefer email? Write to us at sales@mlmsoftwarepro.com