Integration

Magento MLM Software

Magento is the storefront most direct selling companies arrive at when they outgrow a simpler one, and two of its native concepts map almost exactly onto what this industry needs: customer groups for distributor pricing, and multi-website for multiple markets. The integration is built to use both rather than to work around them.

What you get

Outcomes operators report after moving onto the platform.

  • Customer groups do the pricing

    Distributor and preferred-customer pricing is a native Magento customer group, so a distributor's price comes from the catalogue rather than from a discount applied at checkout.

  • One website per market

    Magento's multi-website model gives each market its own catalogue, currency, tax and language, which is what a two-country operation actually needs.

  • API and queues, not the database

    Integration runs over the REST and GraphQL APIs with asynchronous message queues. Nothing writes into Magento tables directly, so upgrades stay routine.

  • Volume on the product, not the indexer

    Commissionable volume is held per SKU in the commission platform. It never depends on a Magento index being current, because a stale index must not change a payout.

  • Multi-Source Inventory respected

    Fulfilment source and batch identifiers arrive on the order line, so warehouse allocation and lot traceability survive the handoff.

  • B2B accounts as distributor entities

    Where distributors trade as companies, Adobe Commerce B2B company accounts map to distributor entities with the right buyers attached.

How responsibility splits

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

Magento / Adobe Commerce keeps

  • Product catalogue, attribute sets, tier pricing and promotions
  • Customer groups, which carry distributor and preferred-customer pricing natively
  • Multi-website and multi-store views for each market, currency and language
  • Cart, checkout, payment methods and tax calculation
  • Multi-Source Inventory, warehouses, shipping and fulfilment
  • B2B company accounts and quotes, where Adobe Commerce B2B is in use

We take over

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

Why companies end up on Magento

Two native Magento concepts happen to match two hard requirements in this industry, and that is not a coincidence anyone planned — it is a consequence of Magento being built for merchants with complicated pricing and several markets.

Customer groups give you distributor pricing, preferred-customer pricing and retail pricing as a catalogue property rather than as a cart discount. On simpler platforms this is custom work.

Multi-website gives each market its own catalogue, currency, tax configuration and language on one installation, which is what a US plus South Africa operation actually requires.

The cost is Magento’s cost of ownership, which is real. If you are running one market with a simple catalogue, Shopify or WooCommerce will be cheaper to operate and neither will hold you back.

The integration boundary

Magento keeps the storefront. The commission platform owns the plan. The line between them is worth stating precisely, because a fuzzy boundary here is what produces a system where the plan is configured in two places.

Owned by MagentoOwned by the commission platform
Catalogue, attributes, prices, promotionsCommissionable volume per SKU
Customer groups and group pricingWhich group a distributor belongs in, and why
Cart, checkout, payment, tax on the saleTax on commission, per market
Inventory, sources, shipping, fulfilmentAttribution, classification, plan rules, the run
Order lifecycle and statusWallet, payouts, statements, adjustments

The one field that needs care is the volume value of a product. It is a plan decision, it lives in the commission platform, and it is referenced by SKU. Letting Magento own it means the plan is configured in two systems, which is the same argument the ERP page makes about product masters.

How it connects

An integration user with scoped API access, a Magento module, and asynchronous queue consumers.

The module does three narrow things: captures the attribution parameter into the quote as an extension attribute, provides the distributor login handoff to the back office, and optionally renders replicated page content inside your store views.

Order events flow over Magento’s message queues — placed, invoiced, shipped, credit memo, cancelled — rather than as synchronous webhooks, because queue-based delivery is what Magento is built for and it degrades gracefully under load. A reconciliation sweep compares totals per period to catch anything the queue lost.

Nothing writes into Magento tables directly. Everything goes through REST, GraphQL and documented extension points, which is what keeps a 2.4.x upgrade a routine operation rather than a project.

Inventory, sources and lots

Multi-Source Inventory means an order line can be fulfilled from a specific source, and where you sell consumable products the batch identifier matters. Both arrive on the order line in the commission platform, so warehouse allocation reporting and lot traceability survive the handoff — which is the requirement set out on the health and wellness page.

Refunds and credit memos

A Magento credit memo triggers one flow with four effects in the commission platform: the linked volume reverses, every bonus that volume supported unwinds including matching bonuses computed on top of it, affected rank qualifications are re-evaluated, and the result posts as a dated adjustment against the open period referencing the original run.

Partial refunds reverse volume in proportion to the amount refunded, which is the only treatment that survives a partial return on a bundle.

B2B and company accounts

Where your distributors trade as registered businesses — common in South Africa, and common at higher ranks anywhere — Adobe Commerce B2B company accounts map onto distributor entities, with individual buyers attached to the company and the commission relationship held against the entity rather than a person. That also makes VAT-registered commission invoicing tractable, which the South Africa page covers.

Magento 1

We will not integrate against Magento 1. It has been end of life since 2020 and it holds payment and identity data with no security patches. If you are on it, the migration to 2.4 comes first and it is not a small piece of work; scope it as its own project rather than as part of a commission platform build.

The integration overview covers the API and webhook model for anything not on the supported list.

At a glance

VersionsMagento Open Source 2.4 and Adobe Commerce 2.4, including B2B. Magento 1 is end of life and we will not integrate against it
InstallationA Magento module for attribution capture and distributor handoff, plus an integration user with scoped API access and async queue consumers
Attribution signalsReplicated link or store view, cart price rule coupon, quote extension attribute, assigned-customer relationship, authenticated distributor order
Order syncAsynchronous queue on order placed, invoiced, shipped, credit-memoed and cancelled, plus a reconciliation sweep against Magento order totals
Pricing modelCustomer groups for distributor and preferred-customer pricing, with tier pricing for quantity breaks, all resolved by Magento
Volume mappingPer SKU in the commission platform, fixed or proportional, with commissionable and qualifying volume held separately
Multi-marketOne website per market, each with its own catalogue, currency, tax rules and approved product set; volume resolves per market
What is never syncedPayment instruments and Magento's own admin users. Card data stays with your payment method 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 integrate rather than build the plan as a Magento extension?

Because the two systems have different shapes. Magento is excellent at catalogue, pricing, checkout and inventory, and its data model is built around those. A commission engine needs separate placement and sponsorship trees, materialised volume roll-ups, versioned plan rules and long-running reproducible batch jobs, none of which the Magento model is designed for. An extension attempting it either constrains the plan to what fits, or ends up with its own tables and its own cron jobs inside a codebase whose upgrade cycle it then blocks. Keeping the boundary clean means Magento upgrades on Adobe's schedule and the plan changes on yours.

How does distributor pricing work?

As a Magento customer group, which is the native mechanism and the right one. A distributor's price comes from the catalogue for their group rather than from a discount applied in the cart, so what they see is their price, tier pricing for quantity breaks works normally, and the order total is correct before any commission logic is involved. Preferred customers get their own group. This is one of the main reasons larger direct selling operations end up on Magento — the pricing tier problem that requires custom work on simpler platforms is already solved here.

Does commissionable volume depend on the Magento indexer?

No, deliberately. Volume per SKU is held in the commission platform, referenced by product code, and the order sync carries SKU, quantity and line total. Nothing about a payout depends on a Magento index being current, because index staleness is a normal operational state and it must not be able to change what someone is paid. The same reasoning applies in the other direction: the commission platform does not write prices, stock or catalogue data back into Magento, so a run cannot affect your storefront.

Can we run two countries on one Magento installation?

Yes, and this is where Magento earns its cost of ownership. Multi-website gives each market its own catalogue, currency, tax configuration, language and approved product set on one installation, which is close to what a US and South Africa operation needs. What Magento does not solve is the part that is not a storefront: two tax treatments on commission, two sets of payout rails, two compliance positions, and per-market product availability affecting which volume enters which plan. Those resolve in the commission platform, per market. Scoping a second market as a translation exercise is the usual costing mistake, and it is not one Magento fixes.

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