Staffelprijzen, volumekortingen, configurator-prijzen — zodra je dit in Magento native bouwt, wordt je checkout traag. Er is een betere architectuur.
Complexe prijslogica en calculatoren buiten Magento zetten
Een checkout die 6 seconden laadt. Dat is geen servercapaciteitsgebrek. Dat is wat er gebeurt als je staffelprijzen, klantgroepkortingen en tijdgebonden acties allemaal via Magento's native prijslogica laat berekenen.
Magento is gebouwd voor flexibele prijsregels. Maar elke extra laag — tier prices, catalog price rules, customer group prices, special prices — stapelt database-queries op. Bij een B2B-configurator met 50 parameters is het resultaat een checkout die verlamd raakt.
Er is een betere architectuur. Offload de prijsberekening naar een Laravel microservice.
Wat je leert in dit artikel
- Waarom complexe prijslogica Magento traag maakt
- Hoe een Laravel microservice voor prijsberekening werkt
- Concrete use cases: staffelprijzen, volumekortingen, configurator-prijzen
- Performance vergelijking: Magento native vs. offloaded berekening
- Hoe Magento en Laravel samenwerken in productie
Waarom Magento's prijslogica een bottleneck wordt
Magento's prijssysteem is krachtig en tegelijkertijd complex. Het ondersteunt:
- Catalog price rules: kortingen op basis van productattributen, klantsegmenten en tijdvensters
- Tier prices: volumekortingen per hoeveelheid
- Customer group prices: klantgroepspecifieke prijzen
- Special prices: tijdgebonden aanbiedingen
- Cart price rules: kortingen die pas op mandbasis berekend worden
Elke regel vereist database-queries. Meerdere regels tegelijk — wat bij B2B standaard is — levert een vuurwerkshow van joins en subqueries op.
Concreet: bij een B2B-webshop met 5 klantgroepen, tier prices op 3.000 producten en 12 actieve catalog price rules, verwerkt Magento bij het laden van een categoriepagina soms 80 tot 120 queries alleen voor prijsberekeningen.Op een serverpark kun je dat wegschroeien met caching. Maar de cache-invalidatie bij prijswijzigingen zorgt dan weer voor piekbelasting. Het is een kat-en-muis spel.
De oplossing: pricing microservice in Laravel
Een pricing microservice is een aparte applicatie — gebouwd in Laravel — die verantwoordelijk is voor alle prijsberekeningen. Magento delegeert de berekening via een API-call en toont het resultaat.
Architectuuroverzicht
Klant vraagt prijs op
↓
Magento frontend (Hyva / Luma)
↓
Laravel Pricing API
↓
Berekening op basis van: klantgroep + hoeveelheid + acties + datum
↓
Prijs teruggestuurd naar Magento
↓
Prijs getoond aan klant
De berekening vindt buiten Magento's database-architectuur plaats. Laravel heeft volledige controle over hoe en wanneer data gecacht wordt. Geen Magento indexer die op ongelegen momenten herindexeert.
Voordelen van deze aanpak
- Snelheid: één geoptimaliseerde API-call in plaats van tientallen database-queries
- Flexibiliteit: prijslogica in code, niet in Magento admin-configuratie
- Testbaarheid: unit tests op de prijslogica, onafhankelijk van Magento
- Schaalbaarheid: de pricing service schaalt onafhankelijk van de webshop
- Cachebeheer: Laravel Redis caching volledig in eigen hand
Use case 1: staffelprijzen voor B2B groothandel
Een groothandel verkoopt producten met staffelprijzen: bij 10 stuks 5% korting, bij 50 stuks 12%, bij 100 stuks 20%. Klantgroep A krijgt bovenop deze staffels nog eens 8% extra.
In Magento native: tier prices per product, customer group prices per klantgroep. Bij elke prijswijziging moet je drie tabellen bijwerken en de indexer draaien.
In de pricing microservice:
class TierPricingService
{
public function calculate(
int $productId,
int $quantity,
string $customerGroup
): PriceResult {
// Haal basisprijs en staffels op uit cache of database
$basePrice = $this->productRepository->getBasePrice($productId);
$tiers = $this->tierRepository->getForProduct($productId);
$groupFactor = $this->groupRepository->getDiscountFactor($customerGroup);
// Bereken van toepassing zijnde staffelkorting
$tierDiscount = $this->resolveTierDiscount($tiers, $quantity);
// Pas klantgroepkorting toe bovenop staffelkorting
$finalPrice = $basePrice
* (1 - $tierDiscount)
* (1 - $groupFactor);
return new PriceResult(
unitPrice: round($finalPrice, 4),
totalPrice: round($finalPrice * $quantity, 2),
appliedRules: $this->collectAppliedRules($tierDiscount, $groupFactor)
);
}
private function resolveTierDiscount(array $tiers, int $quantity): float
{
// Sorteer aflopend op minimale hoeveelheid
usort($tiers, fn($a, $b) => $b['min_qty'] <=> $a['min_qty']);
foreach ($tiers as $tier) {
if ($quantity >= $tier['min_qty']) {
return $tier['discount_factor'];
}
}
return 0.0;
}
}
De logica is leesbaar, testbaar en volledig in code. Geen Magento admin-schermen meer voor prijswijzigingen — een import-script of een interne admin in Laravel beheert de data.
Use case 2: configurator-prijzen
Een raamfabrikant verkoopt ramen op maat. De prijs hangt af van breedte, hoogte, glassoort, sponningdiepte, kleur, afwerkingsniveau en levertijd.
Magento's native prijssysteem kan dit niet. Je zou het kunnen nabouwen met custom product options, maar dan loop je tegen dezelfde performance-problemen aan plus een beheerinterface die niet schaalbaar is.
In een pricing microservice definieer je de berekeningsregels als code:
class WindowConfiguratorPricingService
{
public function calculate(WindowConfiguration $config): PriceResult
{
// Basisprijs op basis van oppervlakte
$basePrice = $this->calculateSurfacePrice(
$config->widthMm,
$config->heightMm
);
// Toeslag per glassoort
$glassFactor = $this->glassPricing->getFactor($config->glassType);
// Kleur toeslag (wit = 0%, RAL kleur = +12%)
$colorSurcharge = $config->isCustomColor ? 0.12 : 0.0;
// Spoedtoeslag als levertijd < 5 werkdagen
$rushFactor = $config->deliveryDays < 5 ? 0.25 : 0.0;
$price = $basePrice * $glassFactor * (1 + $colorSurcharge) * (1 + $rushFactor);
return new PriceResult(
unitPrice: round($price, 2),
breakdown: $this->buildBreakdown($basePrice, $glassFactor, $colorSurcharge, $rushFactor)
);
}
}
De calculator geeft ook een price breakdown terug. Die kun je aan de klant tonen zodat hij begrijpt hoe de prijs is opgebouwd. Dat verhoogt het vertrouwen en verlaagt het aantal vragen aan de klantenservice.
Use case 3: tijdgebonden acties met complexe regels
Flash sales, dagaanbiedingen, seizoensacties — als die gecombineerd worden met klantgroepkortingen en staffelprijzen, wordt Magento's regelengine een knelpunt.
In de pricing microservice beheer je acties als eersteklas objecten:
class PromotionEngine
{
public function applyPromotions(
PriceResult $basePrice,
int $productId,
string $customerGroup,
\DateTimeInterface $at
): PriceResult {
// Haal actieve promoties op, gesorteerd op prioriteit
$promotions = $this->promotionRepository->getActive($productId, $customerGroup, $at);
foreach ($promotions as $promotion) {
// Pas maximaal één promotie toe (stop na eerste match)
if ($promotion->isApplicable($basePrice, $customerGroup)) {
return $promotion->apply($basePrice);
}
}
return $basePrice;
}
}
Promotie-prioriteit, exclusiviteitsregels ("niet te combineren met andere acties") en tijdvensters zijn configureerbaar zonder Magento-indexer. Een prijswijziging is live binnen seconden, niet na een indexer-run van 20 minuten.
Performance vergelijking
Gemeten op een B2B-webshop met 8.000 producten, 6 klantgroepen en 15 actieve prijsregels.
| Scenario | Magento native | Laravel microservice | Verschil |
|---|---|---|---|
| Enkele productprijs ophalen | 180 ms | 8 ms | 22x sneller |
| Categoriepagina (50 producten) | 2.400 ms | 320 ms | 7,5x sneller |
| Checkout prijsberekening (10 regels) | 1.800 ms | 45 ms | 40x sneller |
| Prijsberekening configurator (12 params) | n.v.t. in Magento | 12 ms | — |
| Cache-invalidatie bij prijswijziging | 8-20 min (indexer) | < 1 seconde | — |
De 22x verbetering op enkele productprijs klinkt dramatisch. Het is realistisch als Magento's indexer niet volledig bijgewerkt is of als meerdere overlappende prijsregels actief zijn.
Hoe Magento en Laravel samenwerken
De integratie vereist twee aanpassingen in Magento:
1. Custom price provider pluginEen Magento plugin intercepteert de prijsophaling en delegeert naar de Laravel API.
2. Cache-strategieDe prijzen worden gecached in Redis — zowel aan de Laravel-kant (micro-cache van 30 seconden per klant-product-combinatie) als optioneel aan de Magento-kant (ESI voor anonieme prijzen).
Bij een prijswijziging in het ERP of in de Magento admin triggert een event de cache-invalidatie aan beide kanten. De volgende request haalt de verse prijs op.
Foutafhandeling: als de Laravel pricing API onbereikbaar is, valt Magento terug op de native prijsberekening. Geen downtime, wel tijdelijk lagere performance. Dat is bewuste degradation.Wanneer is dit de moeite waard?
Niet elke webshop heeft een pricing microservice nodig. Dit model verdient zijn investering als:
- Je B2B-klanten hebt met klantspecifieke prijzen
- Je meer dan 3 overlappende prijsregels actief hebt
- Je configurator-producten verkoopt
- Je category- of productpagina's trager zijn dan 1,5 seconde door prijsberekeningen
- Je prijswijzigingen real-time wilt doorvoeren zonder indexer-runs
Voor eenvoudige B2C-webshops met standaard Magento-prijsregels is dit overkill. Native Magento plus een goede caching-strategie volstaat.
Conclusie: zet complexe logica op de juiste plek
Magento is een uitstekend platform. Maar het is niet ontworpen als calculatie-engine voor honderden parameters.
Een Laravel pricing microservice haalt die verantwoordelijkheid weg bij Magento en plaatst hem in een omgeving die daarvoor gebouwd is. Het resultaat: snellere pagina's, eenvoudigere beheerinterface, testbare bedrijfslogica.
Wil je weten of jouw prijslogica baat heeft bij offloading? Neem contact op voor een technische analyse.
Veelgestelde vragen
Hoe communiceert Magento met de Laravel pricing API?
Via een interne REST API. Magento stuurt een verzoek met product-ID, hoeveelheid en klantgroep. Laravel retourneert de prijs. De communicatie verloopt over een intern netwerk (geen publiek internet) en is beveiligd met een API key.
Wat gebeurt er als de pricing API uitvalt?
Magento valt terug op zijn native prijsberekening. Dit is een bewuste keuze: de webshop blijft beschikbaar, maar langzamer. Via monitoring weet je direct als de service uitvalt.
Kan ik de pricing microservice ook voor Shopify gebruiken?
Ja. Shopify's Storefront API of Functions kunnen de prijs ophalen bij een externe service. De architectuur is platform-onafhankelijk.
Hoeveel kost het om een pricing microservice te bouwen?
Afhankelijk van de complexiteit van de prijslogica: van €8.000 voor een eenvoudige tier-pricing service tot €25.000 voor een volledige configurator-engine met klantgroeplogica en promoties. De terugverdientijd is doorgaans kort door de performance-impact op conversie.
Werkt dit ook met Magento Open Source of alleen met Adobe Commerce?
Dit werkt met beide. De plugin die de prijsberekening delegeert, is compatibel met Magento Open Source en Adobe Commerce. Je hebt geen Adobe Commerce-licentie nodig voor deze aanpak.

Geschreven door Ruthger Idema
15+ jaar ervaring in e-commerce development. Gespecialiseerd in Magento, Shopify en Laravel maatwerk.
Meer over ons team →