Je hebt dynamische prijzen ingesteld. Je platform verhoogt de prijs nu tijdens piekuren, laat ze 's nachts zakken, reageert op vraag zoals het hoort. Op papier zou elke sessie geprijsd moeten worden zoals jij het ontworpen hebt.
Dan bekijk je de CDR's van je roamingverkeer en een deel klopt duidelijk niet. Een sessie die aan je avondtarief had moeten afrekenen, sloot af op wat je oude vaste tarief lijkt. Niemand heeft iets aangepast aan jouw kant. Technisch gezien is er niets stukgegaan. De prijsupdate is gewoon nooit volledig aangekomen waar ze moest zijn.
Dit is een stiller probleem dan de meeste prijsgesprekken, want het toont zich niet als een fout. Het toont zich als omzet die net iets lager ligt dan je eigen dashboard zegt dat ze zou moeten zijn, dun genoeg verspreid over sessies om als ruis af te doen.
Waar het gat echt zit
Een dynamisch tarief is geen enkele update, het is een uitzending. Je platform stuurt de nieuwe prijs via OCPI (of welk protocol je ook gebruikt) naar elke verbinding die hem zou moeten ontvangen: rechtstreekse eMSP-integraties, roaminghubs, kaartnetwerken, app-partners. Elke van die verbindingen is een aparte technische relatie, gebouwd en onderhouden door een andere partij, met een eigen releaseritme.
Publieke documentatie over OCPI-integratie is daar behoorlijk eerlijk over: tariefverwerking wordt beschreven als een van de gevoeligste onderdelen van het protocol, precies omdat een tariefmismatch betekent dat de prijs die een chauffeur ziet afwijkt van de prijs die uiteindelijk gefactureerd wordt. CDR-mismatches worden ook aangeduid als een van de meest voorkomende oorzaken van OCPI-integratieproblemen, vaak terug te voeren op hoe een ontvangende partij het tarief interpreteerde of cachete, niet op een fout aan de verzendende kant. AMPECO's OCPI-gids en Codibly's protocolbeschrijving noemen het allebei een van de meest voorkomende integratieproblemen, geen uitzondering.
In de praktijk betekent dat dat de update die je platform verstuurde zich nooit twee keer hetzelfde gedraagt. De ene eMSP past hem binnen het uur toe. Een hub cachet het vorige tarief langer dan je zou verwachten. Een roamingverbinding valt terug op een standaardprijs omdat de integratie daar nu eenmaal voor gebouwd is, ongeacht wat jij verstuurt. Geen van deze partijen doet iets fout naar hun eigen maatstaven. Ze zijn gewoon niet gebouwd voor een tarief dat zo vaak verandert als het jouwe nu doet.
Waarom dit makkelijk over het hoofd gezien wordt
Je eigen platform vertelt je dat de tariefupdate verstuurd is. Dat klopt, en het is ook niet het volledige verhaal, want "verstuurd" en "ontvangen en toegepast" zijn twee verschillende gebeurtenissen die zich afspelen op twee systemen die jij niet in de hand hebt.
De enige plek waar het gat echt zichtbaar wordt, is in de CDR's die later terugkomen, en dan alleen als je nagaat welke prijs een sessie werkelijk afrekende tegenover wat je schema zei dat het moest zijn, op dat uur, op die connector, via die specifieke roamingroute. De meeste facturatiecontroles gaan na of de totalen kloppen, niet of elke sessie tegen het juiste tarief geprijsd werd.
De routes wegen zwaarder mee dan je zou verwachten. Via welke hub of eMSP een roamingsessie binnenkomt ligt niet vast. Partners migreren tussen hubs, heronderhandelen verbindingen, of passen hun integratie op hun eigen tempo aan, zonder dat elke CPO aan de andere kant dat noodzakelijk te horen krijgt. Een route die maandenlang betrouwbaar je tariefupdates oppikte, kan daar stilletjes mee stoppen na een wijziging aan hun kant.
Waar het misgaat aan jouw kant (het CPMS)
Een deel van het gat begint al voor de update je platform verlaat:
- Een tariefpush die één keer afgaat bij het opslaan, zonder automatische herhaling als een hubverbinding tijdelijk plat lag op dat moment.
- Overlappende tariefprofielen of -versies op dezelfde connector, waardoor het onduidelijk is welke een ontvangende partij eigenlijk moet toepassen.
- Geen melding wanneer een OCPI-push naar een specifieke route mislukt of geweigerd wordt: het komt stilletjes niet aan, en niets in je eigen systeem geeft dat aan.
- Tariefupdates die gebundeld of ingepland worden in plaats van in real time verstuurd, wat een extra vertragingsvenster opent bovenop wat er verderop al vertraagt.
- Inconsistente tarief-ID's of -modellen tussen connectoren en hubs, overblijfsels van oudere integraties die nooit volledig gestandaardiseerd werden.
Geen van deze zijn exotische mankementen. Het is het soort dingen dat zich stilletjes opstapelt in elk CPMS dat zijn roamingintegraties één verbinding tegelijk heeft opgebouwd.
Waar het misgaat aan de andere kant (de MSP's en hubs)
De rest van het gat ligt bij partijen die je helemaal niet in de hand hebt:
- Hubs of eMSP's die een tarief langer cachen dan jouw updatefrequentie, omdat hun systemen gebouwd zijn rond tarieven die af en toe veranderen, niet dagelijks of uurlijks.
- Partnerintegraties gebouwd voor periodiek pollen in plaats van push-gebaseerde updates, waardoor een prijswijziging simpelweg wacht op de volgende pollcyclus.
- Stille terugval op een standaard- of laatst-bekende-tarief wanneer een ontvangend systeem het nieuwe tariefobject niet kan verwerken of valideren.
- Kaartnetwerken en oudere app-integraties zonder echt pad om een dynamische prijs te tonen of te factureren.
- Routewijzigingen: een partner migreert naar een andere hub of heronderhandelt een verbinding, en de route die vroeger betrouwbaar je updates oppikte doet dat niet meer, zonder dat iemand je dat laat weten.
Niets hiervan betekent dat dynamische prijzen niet de moeite waard zijn. Het betekent dat de waarde alleen zichtbaar wordt op het verkeer dat je prijs ook echt ontvangt, en op dit moment houdt bij de meeste operators niemand de volledige keten nauwkeurig genoeg in de gaten om te weten welk verkeer dat is.
Waarom dit voor de meeste operators onopgelost blijft
Dit is geen probleem dat je één keer oplost. Problemen aan de CPMS-kant en aan de MSP-kant blijven allebei terugkomen zodra partners hun integraties aanpassen, hubs migreren, en nieuwe roamingverbindingen bijkomen. Het goed opvolgen betekent continu CDR's afzetten tegen je prijsschema, per route in plaats van per partner, en dat snel genoeg doen zodat het niet stilletjes aan een kwartaalomzet knaagt voor iemand het opmerkt.
Dat is precies het gat waarvoor Proxilink gebouwd is. We hebben een systeem ontwikkeld dat de tariefsynchronisatie over CPMS- en roamingverbindingen continu bewaakt voor onze klanten, en dat de routes vangt waar een dynamische prijs niet echt aankomt voor het drie maanden later als omzetverrassing opduikt. Het draait vandaag live voor operators.
Als dit klinkt als iets wat je nooit grondig hebt nagekeken op je eigen netwerk: we lichten graag toe hoe dat er voor jouw situatie zou uitzien.
Veelgestelde vragen
Waarom bereikt een tariefupdate niet elke roamingpartner tegelijk?
Omdat een dynamisch tarief geen enkele update is, maar een uitzending over aparte technische relaties: rechtstreekse eMSP-integraties, roaminghubs, kaartnetwerken, app-partners. Elke verbinding heeft zijn eigen releaseritme en eigen cachegedrag, waardoor dezelfde update op de ene verbinding binnen het uur aankomt en op de andere dagenlang verouderd blijft staan.
Wat is het verschil tussen een probleem aan CPMS-kant en aan MSP-kant?
Problemen aan CPMS-kant beginnen al voor de update je eigen platform verlaat: een push die één keer afgaat zonder herhaling, overlappende tariefversies, of een mislukte push waar niemand een melding van krijgt. Problemen aan MSP-kant liggen bij de roamingpartner: een hub die een tarief langer cachet dan jouw updatefrequentie, een integratie gebouwd voor pollen in plaats van push, of een stille terugval op een standaardprijs.
Hoe merkt een operator dit eigenlijk op?
Niet via het platform dat de update verstuurde, want 'verstuurd' en 'ontvangen en toegepast' zijn twee verschillende gebeurtenissen op twee systemen die je niet in de hand hebt. Het wordt alleen zichtbaar in de CDR's die later terugkomen, en dan alleen als je nagaat welke prijs een sessie werkelijk afrekende tegenover je prijsschema, per route, niet enkel per partner.
Waarom volstaat het niet om dit één keer te controleren?
Omdat beide kanten blijven veranderen. Partners migreren tussen hubs, heronderhandelen verbindingen, of passen hun eigen integraties aan zonder elke CPO aan de andere kant te verwittigen. Een route die maandenlang betrouwbaar je tariefupdates oppikte, kan daar stilletjes mee stoppen na een wijziging aan hun kant. Daarom moet het continu bewaakt worden, niet eenmalig gecontroleerd.