Hoe we dubbele afschrijvingen op architectuurniveau hebben geëlimineerd

Een hotelgast tikt om 23:47 uur op "boeking wijzigen" op de tablet in de kamer. De 3DS-verificatie duurt 40 seconden. De mobiele verbinding valt weg. De gast tikt nogmaals. In de meeste hospitalitysystemen wordt er twee keer afgerekend en bellen ze 's ochtends de receptie. In het onze wordt er één keer afgerekend. Fysiek. Niet "meestal". Niet "met monitoring". Architecturaal.

Dit artikel gaat over de Self-Service wijzigingsengine die mDOS deze maand in productie heeft genomen, en waarom het betalingsarchitectuurwerk erachter commercieel belangrijker is dan de operationele functionaliteit doet vermoeden.

Het probleem dat de meeste hospitality-SaaS nog niet heeft opgelost

Selfservice-wijzigingen (een gast de mogelijkheid bieden om zelf zijn boeking, bestelling of verblijf aan te passen zonder de receptie te bellen) klinkt als een eenvoudige functie. Dat is het ook. Maar het technische fundament erachter is meedogenloos op een manier die de meeste productteams pas beseffen wanneer ze het lanceren en de eerste stornoposten (chargebacks) binnenkomen.

Het basisscenario: een gast wil iets wijzigen wat geld kost. Misschien upgraden ze hun kamer. Misschien voegen ze een spabehandeling toe aan een reeds lopend verblijf. Misschien ontvangen ze een gedeeltelijke terugbetaling van een aanbetaling omdat het gezelschap is gekrompen van 12 naar 10 personen. Of misschien wijzigen ze de datums van een flexibele boeking en moeten ze het tariefverschil bijbetalen.

In al deze gevallen ziet de operationele workflow er als volgt uit: identificeer de wijziging, bereken het financiële verschil (dit kan een afschrijving, een terugbetaling of beide zijn bij complexe gedeeltelijke wijzigingen), verwerk de betaling, werk de boekingsgegevens bij en start alle vervolgprocessen (loyalty-aanpassingen, bevestigingsmails, operationele meldingen).

Op de meeste hospitalityplatformen is deze workflow sequentieel opgebouwd, waarbij elke stap een ander systeem aanroept: eerst wordt het boekingssysteem bijgewerkt, vervolgens wordt de payment service provider aangeroepen, daarna krijgt het loyalty-systeem een melding en ten slotte verstuurt het mailsysteem een bevestiging. Elke stap kent zijn eigen mogelijke fouten. Elke stap vormt een risico op een onvolledige verwerking.

De specifieke fout die exploitanten daadwerkelijk geld kost: de verbinding van de gast valt weg tussen de betalingsaanroep en de bevestiging van het boekingssysteem. Vanuit het perspectief van de gast is de aanvraag mislukt. De tablet toont een foutmelding. Ze proberen het opnieuw. De tweede poging slaagt. Maar de oorspronkelijke betaling was ook al verwerkt, omdat deze al onderweg was toen de verbinding wegviel. De gast is dubbel belast. De receptie komt er de volgende ochtend pas achter. De gast betwist de afschrijving. De exploitant draait op voor het verlies, de geschillenkosten, de klantenservicetijd én de reputatieschade.

Dit is geen hypothetisch scenario. Het is het meest voorkomende betalingsgerelateerde supportticket in hospitality-SaaS. De meeste exploitanten hebben er simpelweg mee leren leven.

Wat mDOS anders heeft aangepakt

De Self-Service-engine behandelt elke wijziging als een transactie met een deterministische idempotentie-sleutel. Deze sleutel wordt afgeleid van de intentie van de gast: de boeking die wordt gewijzigd, de specifieke aanpassing die wordt doorgevoerd en het financiële verschil dat wordt toegepast. Als dezelfde sleutel binnen een kort tijdsbestek twee keer binnenkomt, herkent het systeem dit als een herhaalde poging en retourneert het de oorspronkelijke respons in plaats van de wijziging opnieuw te verwerken.

Dit klinkt eenvoudig. Dat is het niet. De uitdagingen zitten in:

Sleutelafleiding die bestand is tegen onvolledige informatie. De eerste poging van de gast bevat mogelijk een onvolledige formuliersomgeving. Een tweede poging heeft wellicht een licht afwijkende status als er iets opnieuw is ingevoerd. De sleutel moet specifiek genoeg zijn om de intentie uniek te identificeren, algemeen genoeg om overeen te komen met de herhaalde poging, en onvervalst genoeg zodat een kwaadwillende gebruiker een succesvolle betaling niet opnieuw kan afspelen.

Off-session afschrijvingen via opgeslagen kaartgegevens. De eerste keer dat een gast tijdens een verblijf betaalt, wordt de kaart veilig opgeslagen via de betalingsopslag van Stripe. Opeenvolgende wijzigingen tijdens hetzelfde verblijf maken gebruik van deze opgeslagen kaart om 'off-session' af te rekenen: geen herhaalde invoer van kaartgegevens, geen wrijving en geen afgebroken wijzigingen. Maar off-session afschrijvingen kunnen 3DS-verificaties activeren die vereisen dat de gast de betaling bevestigt via hun bank-app. Dit betekent dat het systeem naadloos moet terugvallen op een 'on-session' workflow als de bank dat vereist.

Boekhouding op basis van gehele centen. Geld wordt opgeslagen en verwerkt in gehele centen (of de equivalente basiseenheid voor niet-GBP-valuta). Saldi, afschrijvingen en terugbetalingen worden nooit berekend via 'floating-point'-getallen. Wanneer een totaalbedrag over verschillende onderdelen moet worden verdeeld (zoals het verdelen van een winkelmandkorting over afzonderlijke regels of het splitsen van een aanbetaling), wordt het evenredige aandeel op het moment van toewijzing berekend en afgerond op hele centen. Door het grootboek in gehele centen bij te houden, wordt een hele categorie van afrondingsfouten geëlimineerd die in hospitality-SaaS regelmatig voorkomen (en die doorgaans stilzwijgend worden gecorrigeerd met nachtelijke aansluitingsruns).

Gecombineerde workflows voor gedeeltelijke terugbetaling en upsell. Een veelvoorkomend scenario: een gast verkleint het gezelschap van 8 naar 6 personen, wat een gedeeltelijke terugbetaling van twee aanbetalingen betekent, maar upgradet tegelijkertijd het menu, wat een extra afschrijving is. Het systeem moet deze bedragen correct verrekenen, de terugbetaling en de afschrijving in een deterministische volgorde uitvoeren en het uiteindelijke verschil met de juiste specificatie aan de gast tonen. mDOS verwerkt dit als één enkele samengestelde transactie; traditionele systemen verwerken dit als twee opeenvolgende transacties en hopen dat er tussentijds niets misgaat.

Waarom dit commercieel van belang is

Het kostte ongeveer zes engineer-weken om de Self-Service-engine op productieniveau op te leveren. Dat is een enorme investering voor wat een eenvoudige functie lijkt.

De commerciële onderbouwing voor die investering was heel specifiek: enterprise hospitality-acquirers en -exploitanten voeren tijdens het inkoopproces een zogenaamde due diligence op betalingssystemen uit. De CTO zal vragen: "Wat gebeurt er als de verbinding van een gast wegvalt tijdens een 3DS-verificatie?" Als het antwoord is "we hebben monitoring", "het komt zelden voor" of "we hebben een nachtelijke controle-job", dan zakt het platform voor de due-diligence-toets.

Als het antwoord luidt: "De architectuur voorkomt dit: dit is de logica achter de afleiding van de idempotentie-sleutel en hier zijn de Playwright-tests die dit bewijzen", dan slaagt het platform.

mDOS slaagt nu. Die ene zin is wat een categorie enterprise-klanten ontsluit die het platform zes maanden geleden niet eens overwogen zouden hebben.

Wat dit betekent voor exploitanten

Voor een exploitant van meerdere locaties met 200 vestigingen elimineert de Self-Service-engine naar schatting 3–7% van alle betalingsgerelateerde klantenservicetickets. Het precieze cijfer varieert per type locatie en gastdemografie, maar het patroon is consistent: elke exploitant die we hebben gebenchmarkt ten opzichte van de verouderde stack, meldt dubbele afschrijvingen als een alledaags verschijnsel.

Het elimineren van die 3–7% heeft een versterkend effect. Het aantal klantenservice-uren daalt. Het aantal chargebacks neemt af. De boekhoudkundige afstemming van terugbetalingen vermindert. Het klantvertrouwen verbetert aantoonbaar, met name onder gasten met een hoge uitgave die vaker gebruikmaken van functies voor zelfbedieningswijzigingen. De operationele ROI van de Self-Service-engine voor een grootschalige organisatie is aanzienlijk genoeg om op zichzelf een budgetpost te vormen.

Voor een overnemende partij die mDOS beoordeelt als IP, signaleert de Self-Service-engine iets anders: het geeft aan dat het engineeringteam er voor heeft gekozen om complexe problemen grondig op te lossen in plaats van sneller op de markt te komen met technische schuld. Dit is waar de technische due diligence van koper echt naar zoekt: geen aantal functies, maar bewijs van architectonische volwassenheid in de minder spectaculaire onderdelen van het systeem.

Het architectonische patroon in één alinea

Elke wijziging vloeit voort uit de intentie van een gast. Deze intentie wordt gehasht naar een deterministische idempotentie-sleutel. De sleutel wordt gecontroleerd aan de hand van een tabel met recente verzoeken. Als de sleutel overeenkomt met een recent succesvol verzoek, retourneert het systeem de oorspronkelijke respons. Als de sleutel niet overeenkomt, start het systeem een transactie die het financiële verschil (afschrijving, terugbetaling of een combinatie), de boekingsupdate en de uitwaaiering van triggers afhandelt als één enkele atomaire operatie. Als een stap mislukt, wordt de gehele transactie teruggerold. Als de gast dezelfde intentie binnen het idempotentie-venster opnieuw probeert, ontvangt deze de oorspronkelijke succesvolle respons, zelfs als de verbinding op het slechtst denkbare moment wegviel.

Dit patroon is goed gedocumenteerd in de literatuur over payment engineering. Stripe adviseert het zelf ook. Het ontbreekt echter vrijwel universeel in hospitality SaaS, omdat een correcte implementatie een mate van cross-systeem transactiediscipline vereist die gefragmenteerde architecturen fundamenteel niet kunnen bieden.

mDOS kan dit wel bieden doordat elke stap in de wijzigingsflow zich in dezelfde Postgres-database bevindt. De berekening van het financiële verschil, de boekingsupdate, de loyaliteitsaanpassing en de uitwaaiering van triggers: ze maken allemaal deel uit van dezelfde transactie. De atomiciteit is geen functionaliteit; het is een eigenschap van de geïntegreerde architectuur.

Wat u aan uw huidige platform moet vragen

Als u een hospitality-organisatie met meerdere locaties runt, testen drie vragen of uw stack dit type probleem kan hanteren.

Hoe gaat uw huidige platform om met een gast die tijdens een 3DS-controle bij een wisselvallige verbinding twee keer op "wijzigen" tikt? Als het eerlijke antwoord monitoring, handmatige afstemming of tussenkomst van de klantenservice omvat, vangt u operationele kosten op die de architectuur eigenlijk zou moeten elimineren.

Welk percentage van uw maandelijkse klantenservicetickets heeft betrekking op dubbele afschrijvingen, gemiste terugbetalingen of facturatieverschillen door wijzigingen? De meeste exploitanten hebben dit niet gemeten omdat ze het als achtergrondruis zijn gaan accepteren.

Wat doet uw platform wanneer een opgeslagen off-session afschrijving een onverwachte 3DS-controle activeert? Als het antwoord is "de afschrijving mislukt en we moeten de gast vragen om opnieuw door de reguliere checkout te gaan", heeft u bij elke wijzigingsflow een aanzienlijk conversieprobleem.

Deze vragen gaan niet over functionaliteiten. Ze gaan over de vraag of de payment engineering van uw platform volwassen genoeg is voor enterprise-schaal.

---

De Self-Service-engine is in mei 2026 in productie genomen. Technische documentatie is onder een wederzijdse NDA beschikbaar voor lopende evaluaties.