Herstelbare abonnementsstatussen voor een SaaS

Een betalingsprovider kan een afschrijving vertraagd bevestigen, dezelfde gebeurtenis meer dan eens versturen of een transactie half verwerkt achterlaten. Daarom zijn «betaald» en «heeft toegang» niet gelijkwaardig. Als de toestemming van een account rechtstreeks afhangt van het laatste antwoord van een betalings-API, kan een tijdelijke storing een klant blokkeren die wel heeft betaald, of een andere klant toegang geven terwijl diens afschrijving uiteindelijk is mislukt.

Bij abonnementsstatussen in PHP-SaaS is het doel niet om één label in een tabel op te slaan. Het is om een herstelbaar proces op te bouwen: elke beslissing moet bewijs, een verantwoordelijke, een geldige overgang en een manier hebben om te reconciliëren wanneer nieuwe gegevens binnenkomen.

Productregels bepalen vóór het technische model

Het datamodel lost commerciële ambiguïteiten niet op. Voordat entiteiten of webhooks worden ontworpen, moeten product, financiën en operations overeenkomen wat er in elke relevante situatie gebeurt.

• Activering: wordt toegang verleend voordat de eerste betaling is bevestigd, na een autorisatie of alleen na vereffening?
• Verlenging: wanneer begint de respijtperiode en welke mogelijkheden blijven daarin behouden?
• Wanbetaling: zijn er automatische herpogingen, meldingen, gedeeltelijke beperkingen of volledige opschorting?
• Opzegging: eindigt de toegang onmiddellijk of aan het einde van de reeds gecontracteerde periode?
• Terugbetaling of geschil: vereist dit onmiddellijke blokkering, handmatige beoordeling of intrekking zodra een resultaat is bevestigd?
• Heractivering: herstelt dit precies het vorige plan, creëert het een nieuwe commerciële cyclus of vereist het operationele validatie?

Het is ook raadzaam om een door de klant aangevraagde opzegging te onderscheiden van een effectieve opzegging. De eerste drukt een intentie uit; de tweede wijzigt het toekomstige toegangsrecht. Door ze te vermengen ontstaan verwarrende interfaces en automatiseringen die moeilijk te corrigeren zijn.

Contract, facturatie en effectieve toegang scheiden

Een onderhoudbare architectuur representeert ten minste vier concepten. Het account identificeert de houder en zijn leden. Het commerciële contract beschrijft het abonnement, de overeengekomen prijs, de verlengingsdatum en de beslissing om op te zeggen. De factureringscyclus representeert een concrete verplichting voor een periode, het bedrag en de uitkomst ervan. Tot slot maken de ingeschakelde mogelijkheden concreet wat het account binnen het product kan doen.

Deze scheiding voorkomt dat een betalingsprovider de enige bron van waarheid voor de hele SaaS wordt. Een cyclus kan in behandeling zijn terwijl het contract dankzij een respijtperiode van kracht blijft. Tegelijk kan een account leestoegang behouden, maar geen nieuwe resources kunnen aanmaken. Mogelijkheden maken het mogelijk deze beslissing uit te drukken zonder een valse binaire keuze tussen actief en inactief te forceren.

In PHP kan een applicatie een autorisatieservice aanbieden die een lokale projectie van mogelijkheden raadpleegt, bijvoorbeeld canCreateProject of canExportData. Die projectie wordt bijgewerkt wanneer commerciële of factureringsfeiten veranderen; zij hoeft niet bij elke aanvraag de provider aan te roepen. Zo worden latentie, externe afhankelijkheid en verspreide conditionals over controllers, queues en geplande taken verminderd.

Overgangen, verantwoordelijken en bewijs modelleren

Vermijd één enkel veld status met waarden die worden toegevoegd zodra incidenten zich voordoen. Het verdient de voorkeur om statussen per aggregate en toegestane overgangen te declareren. Een factureringscyclus kan bijvoorbeeld van open naar payment_pending, paid, failed, refunded of disputed gaan. Niet elke overgang is omkeerbaar en niet elke actor mag deze uitvoeren.

Elke wijziging moet datum, bron, externe identifier indien aanwezig en bewijs opslaan. De bron kan een interne opdracht, een gevalideerde webhook, een reconciliatiequery of een geautoriseerde handmatige actie zijn. Een correctie door support mag de geschiedenis niet stilzwijgend overschrijven: zij moet als afzonderlijke beslissing worden vastgelegd, met reden en verantwoordelijke operator.

Prioriteit bij tegenstrijdige informatie

Bepaal welk bewijs prevaleert. Een omleidingsscherm na betaling mag een cyclus niet bevestigen: het dient om de gebruiker te informeren, niet als definitief bewijs. Een ondertekende en geverifieerde webhook levert doorgaans een beter signaal, maar kan laat aankomen. Een geauthenticeerde query bij de provider tijdens reconciliatie kan ontbrekende gebeurtenissen verduidelijken. Als twee bronnen van elkaar verschillen, moet het systeem naar beoordeling of naar een gedefinieerde status in afwachting gaan, en niet willekeurig het meest recente gegeven kiezen.

Late, dubbele en onvolledige gebeurtenissen verwerken

De ontvangst van een gebeurtenis moet idempotent zijn. Sla een stabiele identifier van de externe gebeurtenis op, evenals een hash of referentie van de relevante payload. Als deze opnieuw wordt ontvangen, reageer dan zonder het bedrijfseffect te herhalen. Dit is vooral belangrijk als een betalingsgebeurtenis het uitgeven van een document, de verlenging van de periode of een melding activeert.

De verwerking moet ontvangst en toepassing scheiden. Valideer eerst de handtekening, het schema en de herkomst; sla daarna de ontvangen gebeurtenis duurzaam op; verwerk tot slot een taak die de overgang probeert toe te passen. Als het proces uitvalt nadat de gebeurtenis is gepersisteerd, kan een queue of herstelproces het hervatten. Als het faalt vóór het opslaan, moet reconciliatie het verschil ontdekken door interne cycli met de externe bron te vergelijken.

gebeurtenis ontvangen → validatie → duurzame registratie → idempotente toepassing
                                      ↓
                              herpoging of reconciliatie

Ga niet uit van een aflevervolgorde. Een terugbetaling kan vóór een late bevestiging van de oorspronkelijke betaling aankomen. De regels moeten de huidige status, de transactiereferenties en de bekende volgorde beoordelen, en onmogelijke of ambigue gevallen in een beoordelingsqueue achterlaten. Blindelings «de laatst ontvangen gebeurtenis» toepassen is een veelvoorkomende oorzaak van onjuiste rechten.

Reconciliatie en rechten als gecontroleerde projectie

Periodieke reconciliatie is geen lapmiddel; het maakt deel uit van het ontwerp. Zij moet cycli opsporen die te lang openstaan, betalingen die buiten het systeem zijn bevestigd, geregistreerde maar onverwerkte gebeurtenissen, dubbele externe referenties en mogelijkheden die niet overeenkomen met het geldige contract. Wanneer een verschil wordt gedetecteerd, registreer dan de bevinding en pas een traceerbare overgang toe, in plaats van velden rechtstreeks bij te werken.

De projectie van mogelijkheden moet expliciete regels hebben. Een geldig contract met een verlopen cyclus die nog binnen de respijtperiode valt, kan bijvoorbeeld essentiële functies behouden; na afloop van de respijtperiode kan het schrijfbewerkingen intrekken. Wanneer een late betaling wordt bevestigd, heractiveert het systeem de voor het abonnement voorziene mogelijkheden en behoudt het de geschiedenis van de eerdere beperking.

Een cache voor rechten kan nuttig zijn, maar heeft invalidatie nodig wanneer de projectie verandert en een geldigheidslimiet. Kritieke autorisatie mag evenmin uitsluitend gebaseerd zijn op gegevens die in de browser zijn opgeslagen. De server moet beslissen op basis van de geldige mogelijkheid en de juiste scope van account, gebruiker en resource.

Backoffice, audit en hersteltests

Het supportteam moet, zonder databaserecords te bewerken, het contract, de cycli, de externe gebeurtenissen, de toegepaste overgangen, de huidige mogelijkheden en de handmatige acties kunnen zien. Het moet een reconciliatie kunnen aanvragen, een veilige gebeurtenis opnieuw kunnen proberen en een beoordeling kunnen openen. Correcties die toegang of saldo wijzigen, vereisen gescheiden rechten, een verplichte reden en een auditlog.

Test de flow als een reeks fouten, niet alleen als een correcte betaling. Neem bevestigde verlenging, onzekere betaling, duplicaten, gebeurtenissen buiten volgorde, terugbetaling, opzegging aan het einde van de periode en heractivering op. Controleer zowel het eindresultaat als dat geen enkele herpoging twee perioden, twee documenten of een dubbele uitbreiding van rechten creëert.

Een hypothetisch geval: een cyclus vervalt, de afschrijving blijft in behandeling en het account komt in een respijtperiode met beperkte mogelijkheden. De bevestigingswebhook wordt door een tijdelijke onderbreking niet verwerkt, maar de gebeurtenis blijft geregistreerd. Een idempotente herpoging bevestigt de cyclus, verlengt het contract en herstelt de mogelijkheden. Als de gebeurtenis niet was aangekomen, zou reconciliatie de bevestigde externe transactie vinden en dezelfde overgang met eigen bewijs genereren.

Waarschuwingssignalen en controlelijst

Meet accounts met incoherente contracten en mogelijkheden, verlopen cycli zonder beslissing, onverwerkte gebeurtenissen, uitgeputte herpogingen, door reconciliatie gedetecteerde verschillen en de frequentie van handmatige wijzigingen. Een toename van handmatige correcties wijst doorgaans op ontoereikende regels, niet alleen op een operationeel probleem.

• Zijn contract, factureringscyclus en mogelijkheden afzonderlijke entiteiten?
• Heeft elke overgang een actor, bewijs, datum en reden?
• Zijn externe gebeurtenissen idempotent en worden ze opgeslagen vóór ze worden toegepast?
• Is er reconciliatie die onvolledige transacties kan herstellen?
• Worden rechten berekend vanuit een lokale projectie en niet vanuit een realtime betalingsantwoord?
• Kan support onderzoeken en corrigeren met auditing, zonder rechtstreekse wijzigingen in productie?
• Dekken de tests vertragingen, duplicaten, wanorde en tegenstrijdigheden?

Een herstelbaar model elimineert externe storingen niet. Het maakt ze detecteerbaar, afgebakend en corrigeerbaar, zonder van een factureringsincident een verlies van controle over de toegang tot het product te maken.