Laravel Plus SaaS MLM. The Bridge Pattern.
Laravel for product UX, SaaS MLM for operations. Listener pushes orders to SaaS; webhook controller handles inbound events. About 300 lines of glue code.
Why the bridge pattern is the recommended choice for most Laravel MLMs
Laravel is a strong application framework. It's not an MLM framework. The bridge pattern lets each layer do what it's good at. Laravel handles the customer-facing app surface, custom workflows, marketing automation integration, and any business logic specific to the network. The SaaS MLM platform handles members, commissions, genealogy, KYC, payouts, all the standardized MLM operations that don't differentiate any one network from another.
The architectural goal is symmetric. Laravel does not calculate commissions; the SaaS does not render product pages; neither side breaks when the other ships an update.
The data flow
Laravel app CloudMLM SaaS (or Business MLM)
─────────── ──────────────────────────────
Order created ───► /api/orders (POST)
Distributor created ───► /api/members (POST)
Member rank advances /webhooks/rank-up ───► Laravel listener
Commission calculated /webhooks/calc ───► Laravel listener
Laravel sends member registrations and order completions to the SaaS. The SaaS calculates commissions, runs payout cycles, manages KYC, and posts results back as signed webhooks that Laravel listeners handle.
The listener pattern
class PushOrderToMlm
{
public function __construct(private CloudMlm $mlm) {}
public function handle(OrderCompleted $event): void
{
$this->mlm->orders()->create([
'idempotency_key' => $event->order->uuid,
'distributor_id' => $event->order->distributor_id,
'amount' => $event->order->total,
'currency' => $event->order->currency,
'completed_at' => $event->order->completed_at,
]);
}
}
The idempotency key on the SaaS-side request matters; if the listener fires twice (which happens during queue retries), the SaaS deduplicates rather than creating two commission cycles.
The webhook receiver
// In routes/web.php or a dedicated route file
Route::post('/webhooks/mlm', function (Request $request) {
abort_unless(
hash_equals(
$request->header('X-Mlm-Signature'),
hash_hmac('sha256', $request->getContent(), config('mlm.webhook_secret'))
),
401
);
event(new MlmWebhookReceived($request->json()->all()));
return response()->noContent();
});
Signature verification first, business logic via event dispatch second. The pattern keeps the webhook route fast (under 50ms) and decouples the inbound webhook from any heavy processing the network's own logic might want to do.
What to verify in the SaaS demo
Before signing, five specifics. First, the REST API covers every operation in the admin UI; ask the vendor to walk through five admin operations through API calls during the demo. Second, webhooks are HMAC-SHA256 signed and retried with exponential backoff for at least 24 hours. Third, idempotency keys are honored on inbound requests so retries do not double-process. Fourth, a sandbox environment exists with seedable test data for testing the webhook flow before production cutover. Fifth, a composer-installable PHP SDK ships with the API documentation; you should not be writing HTTP plumbing from scratch.
CloudMLM Software passes these tests cleanly and ships the SDK on Packagist as cloudmlm/sdk. Business MLM Software passes them functionally with slightly less polished SDK ergonomics. Other SaaS MLM vendors vary; the demo conversation surfaces it quickly.
Filament admin layer
For the Laravel admin side, Filament 3 is the fastest path to a real MLM admin panel. Distributor management, commission ledgers, KYC document viewer, payout cycle UI all map cleanly to Filament Resources. Performance ceiling is similar to Laravel itself. About 2,000 lines of Filament Resource definitions covers the operational admin surface; the SaaS-side admin is separate and handles the deep MLM operations.
What this scales to
Through $25M+ GMV with no architectural changes. Above that, the question becomes whether to leave Laravel entirely (Pattern C, direct SaaS) or stay on the bridge with bigger Laravel hosting. Most networks staying on Laravel through that scale find no operational reason to migrate.