Denk aan een checkout waarbij de betaling slaagt, maar de orderupdate mislukt. De klant ziet een foutmelding en probeert het opnieuw. Ondertussen heeft de support een transactieregistratie, heeft het magazijn geen bevestigde order en wil de financiële afdeling weten of de klant nog iets verschuldigd is.

Welk systeem moet de situatie oplossen? Incidenten zoals dit zijn het moment waarop architectuurbeslissingen zichtbaar worden: wanneer eigendom niet is gedefinieerd, krijgt elke gebeurtenis een handgemaakte fix, en die fixes hopen zich op waar ze het gemakkelijkst te schrijven zijn.

Een architectuur moet die vraag beantwoorden voordat de eerste transactie in productie gaat. Anders neemt betaalcode geleidelijk orderherstel, abonnementsregels, factuuraanpassingen en fulfishmentbeslissingen op.

Het hieronder geschetste eigendomsmodel biedt een praktisch startpunt: houd de gateway gericht op communicatie met de provider, geef betaaloperaties een eigen thuis, en laat beslissingen over aan facturering en orders.

Begin met vier verantwoordelijkheden, niet drie

Voor dit ontwerp moet de betaalgateway worden onderscheiden van de bredere betaaldienst. Het model gebruikt vier logische grenzen die de gateway, de betaaldienst, facturering en orders omvatten.
Behandel deze als eigheidsgrenzen, niet als een instructie om vier microservices te deployen. Beginnen met modules binnen één applicatie is prima als dat bij het team past. In beide gevallen moeten de verantwoordelijkheden expliciet worden gemaakt.

Bij het beoordelen van betaalgateway-architectuur, combineer het componentdiagram met een beslissingskaart: wie bepaalt het bedrag, wie vraagt de inning aan, wie legt de uitkomst vast, en wie autoriseert de volgende bedrijfsactie?

Houd de gateway dicht bij de provider

Geef de gateway een smal contract. Het moet een ondersteunde betaaloperatie accepteren, deze vertalen naar het formaat van de provider en een resultaat teruggeven dat de betaaldienst kan interpreteren.

De isolatie heeft een praktische motivatie: betaalproviders verschillen in API's, authenticatieschema's, veldformaten en notificatiemechanismen, en het consolideren van die variatie in één laag houdt de rest van het systeem geïsoleerd van providerspecifieke details.

Wijs het verantwoordelijkheden toe zoals:

• Valideren van het verzoek richting de provider
• Authenticeren van de communicatie met de provider
• Vertalen van interne velden naar providerspecifieke velden
• Verifiëren van inkomende providernotificaties
• Mappen van responsen met behoud van nuttige providerdetails

Productkennis blijft buiten dat contract. De gateway hoeft niet te begrijpen wat loyaliteitsniveaus, verzendgeschiktheid, abonnementsgraceperiodes of promotiebundels zijn. Geef het de goedgekeurde hoeveelheid, valuta, betaalreferentie en vereiste betaalmethode-informatie—niet de regels die deze hebben opgeleverd.

Een nuttige beoordelingsvraag: zou het wijzigen van het retourbeleid het wijzigen van gatewaycode vereisen? Zo ja, heroverweeg dan de grens.

Geef betaaloperaties een aparte eigenaar

Betaalpogingen en hun uitkomsten horen thuis in de betaaldienst. Leg voor elke poging een interne identifier, relevante providerreferenties, opgevraagd bedrag, valuta, operatietype en status vast. Bewaar voldoende geschiedenis om te onderzoeken wat is aangevraagd en wat daadwerkelijk is bevestigd.

Vermijd het reduceren van het model tot één enkele 'betaald'-vlag. Definieer in plaats daarvan de onderscheidingen die de workflows nodig hebben, inclusief onopgeloste uitkomsten. Providercommunicatie is soms echt onzeker—time, late notificaties en updates in verkeerde volgorde zijn normaal—dus het statusmodel heeft ruimte voor ambiguïteit nodig in plaats van elke uitkomst te reduceren tot succes of mislukking.

Ontwerp expliciet voor deze hypothetische reeks: de betaaldienst vraagt een autorisatie aan, het verzoek bereikt de provider en de respons gaat verloren. De applicatie moet dan beslissen wat er nu moet gebeuren. Een time-out mag nooit automatisch een nieuwe belasting activeren. Vereis dat de betaaldienst de oorspronkelijke poging oplost of veilig beheert voordat een andere operatie is toegestaan.

Twee soorten retries moeten ook worden gescheiden:

• Technische retry: herhalen van de communicatie voor dezelfde beoogde operatie onder gedefinieerde veiligheidsregels.
• Inningsretry: een nieuwe poging doen om een openstaand saldo te innen.

Wijs de afhandeling van technische retries toe aan het ontwerp van de betalingsintegratie. Facturering bepaalt het innametiming en de geschiktheid, waarbij de betaaldienst de goedgekeurde poging uitvoert.

Laat facturering bepalen wat er verschuldigd is

Facturering is eigenaar van de financiële verplichting: de belastingberekening, de factuur, credits en het resterende saldo. Voor een abonnementsproduct horen hier regels voor planwijzigingen, proratie, factureringsperiodes en innametabellen.

Vereis dat facturering elk inningsverzoek uitgeeft met een expliciet bedrag, valuta en referentie naar de ingende verplichting. De betaaldienst rapporteert de uitkomst, en facturering bepaalt vervolgens hoe die uitkomst het saldo beïnvloedt.

Denk aan een hypothetische factuur van $100 met een credit van $30. Facturering moet de resterende $70 opvragen. De gateway mag nooit worden gevraagd die berekening te reconstrueren uit abonnementsmetadata.

De inzet groeit met prijscomplexiteit: elke berekening die in de verkeerde component terechtkomt wordt logica die later moet worden gevonden, gemigreerd en afgestemd tussen systemen.

Dezelfde discipline geldt na een terugbetaling. Betalingsregistraties stellen vast wat via de provider is terugbetaald; facturering bepaalt welke factuur- of saldisaanpassing overeenkomt met die terugbetaling.

Laat orders bepalen wat er met de aankoop gebeurt

Fulfilment- en aankooplevenscyclusbeslissingen blijven bij het orderdomein. De betaaldienst moet een betaaluitkomst publiceren, geen magazijninstructie uitgeven, en de orderworkflow moet die uitkomst interpreteren naast haar andere vereisten. Het interpreteren van de uitkomst is net zozeer een zakelijk oordeel als een technisch, aangezien dezelfde bevestigde betaling een verschillend gewicht kan hebben voor verschillende fulfilmentmodellen.

Eén voorbeeld van een explic fulfilmentregel: geef de order pas vrij wanneer aan de vereiste betaalvoorwaarde is voldaan, voorraad is toegewezen en eventuele vereiste controle is voltooid. De betaalvoorwaarde moet worden gekozen passend bij het bedrijfsmodel en nooit begraven worden in een providerrespons-handler.

Annuleringen verdienen dezelfde scheiding. Orders bepalen of annulering is toegestaan en wat er met de aankoop moet gebeuren, en vragen vervolgens de juiste betaaloperatie aan via de betaaldienst. Vermijd een overbelast 'annuleer'-commando dat kan betekenen: annuleer de order, geef een autorisatie vrij, betaal een betaling terug of beëindig een abonnement. Geef elke actie een precieze naam.

Coördineer terugbetalingen zonder één systeem elke taak te geven

Een terugbetalingsworkflow is een goede test of de grenzen standhouden. Stel dat een klant één artikel retourneert van een order met drie artikelen. Structureer de workflow zodat:

• De retour- of ordercomponent de retour goedkeurt.
• De aangewezen eigenaar van de commerciële berekening het terugbetaalbare bedrag bepaalt.
• De betaaldienst de betaalgeschiedenis en toepasselijke operatielimieten controleert.
• De gateway het verzoek bij de provider indient.
• De betaaldienst de bevestigde of onopgeloste uitkomst vastlegt.
• Facturering en orders hun eigen registraties dienovereenkomstig bijwerken.

Wijs aan elke berekening één eigenaar toe. Facturering en orders mogen niet onafhankelijk verschillende terugbetalingsbedragen berekenen en het betalen de keuze laten maken.

Houd 'terugbetaling aangevraagd' gescheiden van 'terugbetaling bevestigd'. Als het providerresultaat onopgelost is, behoud die onzekerheid en bied een onderzoeksroute aan in plaats van de hele workflow als voltooid te markeren.

Maak herstel deel van het contract

Elke grensoverschrijdende operatie moet meer specificeren dan alleen de succesvolle respons. Documenteer:

• Hoe herhaalde verzoeken worden geïdentificeerd
• Welke component de autoritatieve status beheert
• Hoe late of dubbele notificaties worden afgehandeld
• Wat er gebeurt wanneer de volgende component niet beschikbaar is
• Hoe medewerkers onopgeloste uitkomsten onderzoeken
• Welke acties veilig kunnen worden herhaald

Voor herhaalde verzoeken in het bijzonder bieden providers doorgaans idempotentiemechanismen die precies voor dit doel zijn ontworpen, waardoor dezelfde operatie opnieuw kan worden ingediend zonder twee keer te worden uitgevoerd.

Geef elk domein zijn eigen identifiers en verbind ze expliciet: order-ID, factuur-ID, betalings-ID, pogings-ID en providerreferentie. Forceer niet dat één identifier elke relatie vertegenwoordigt.

Supportmedewerkers kunnen een gecombineerde tijdn ontvangen, maar correcties moeten onder de controle van de beherende component blijven. Een handig dashboard mag geen toestemming worden om betaalgeschiedenis te overschrijven of factsaldi stilletjes te wijzigen.

Test de grenzen met bedrijfsveranderingen

Voordat het ontwerp wordt goedgekeurd, doorloop dan verschillende veranderingen:

• Voeg een betaalprovider toe zonder prijsregels te wijzigen.
• Wijzig de inningsfrequentie van abonnementen zonder gateway-adapters aan te passen.
• Introduceer gedeeltelijke retouren zonder de afhandeling van providernotificaties te herschrijven.
• Wijzig het fulfilmentbeleid zonder de definities van betaalstatussen te veranderen.

Beschouw onverwachte wijzigingen tussen componenten als signals voor beoordeling. Sommige coördinatie is legitiem; onverklaarde koppeling verdient aandacht.

Eigendomsdrift kondigt zich zelden aan; het hoopt zich op, één pragmatische wijziging per keer. Het opnieuw doorlopen van deze oefeningen wanneer een nieuwe provider, betaalmethode of prijsmodel wordt geïntroduceerd, houdt de grenzen expliciet lang na de eerste ontwerpbeoordeling.

De gateway moet eindigen bij providergerichte betaalcommunicatie. De betaaldienst moet eigenaar zijn van betaaluitvoering en bewijs. Facturering moet eigenaar zijn van verplichtingen en saldi. Orders moeten eigenaar zijn van de aankoop en het fulfilment daarvan.

Schrijf die verantwoordelijkheden in interfaces, herstelprocedures en teameigendom. Een diagram alleen houdt ze niet gescheiden.