Exchange valt buiten deze API/CLI-release. Eventuele historische Exchange-voorbeelden in deze gids zijn niet beschikbaar; dit zegt niets over bestaande portaalfuncties. Zie het actuele releasebereik.

Autorisatie tijdens facturatie

Een goedgekeurde API-offerte bewaart de koopintentie en bereidt de echte resources en vastgehouden taken voor voordat facturatie begint. De duurzame facturatiepoging en de reservering van bestedingsruimte worden eenmaal vastgelegd. Dat ontvangstbewijs geeft een ingetrokken verbinding geen toestemming om nieuwe leveranciersaanroepen te blijven versturen.

De gedeelde checkout kan daarom een expliciete backendcontrole krijgen. Iedere echte WeFact-aanroep en iedere Mollie SDK-aanroep controleert opnieuw dezelfde oorspronkelijke verbinding, het oorspronkelijke tokenplafond, het actuele bedrijf en de benodigde rechten. Voor een batch worden de kinderen afzonderlijk gecontroleerd. De controle herhaalt geen bestelling, bestedingsreservering of facturatiejournal. De browsercheckout en achtergrondprocessen krijgen hierdoor geen stilzwijgende API-gebruikerscontext.

Als rechten vervallen tijdens het ophalen van een debiteur, volgt geen factuuraanvraag. Vervallen ze tijdens een reeds geaccepteerd factuurantwoord, dan blijft die ontvangen factuur-ID bewaard en stoppen volgende abonnement-, mail- en betalingsaanvragen. Ook een inmiddels ontvangen Mollie-klant-ID wordt bewaard voordat een volgende betaalopdracht kan worden geweigerd.

Een onzekere bestelling blijft op haar oorspronkelijke intentie staan; de voorbereidende taken blijven vastgehouden. Onderzoek de oorspronkelijke operatie en financiële referenties. Maak geen nieuwe offerte of idempotentiesleutel om een onbekende uitkomst opnieuw te factureren. Intrekken van een verbinding draait een al geaccepteerde betaling of factuur niet terug; afhandeling daarvan vereist de daarvoor bedoelde annulerings- of herstelworkflow.

Ook betaalde wijzigingen van een bestaand spamfilter gebruiken voor de geoffreerde wijziging dezelfde actuele controle bij de abonnement-, filter- en DNS-aanroepen. Een synchrone verwerking van een reeds ontvangen betaling behoudt deze controle wanneer zij achterstallige abonnementen aanmaakt. Bestaande achtergrondontvangsten krijgen geen gefingeerde interactieve gebruiker.

Deze controle staat naast de bestaande actuele taakautorisatie bij levering. De callback is uitsluitend een vertrouwd backendargument en kan niet met een HTTP-veld of header worden aangezet, vervangen of overgeslagen.

Een terugkerend WeFact-abonnement krijgt eveneens een duurzaam aanmaakrecord vóór subscription.add, inclusief een servergegenereerde pogingreferentie in de interne leveranciersopmerking. Een bestaand onbevestigd, mislukt of onbekend record kan geen nieuwe add starten, ook wanneer een hard gestopt proces geen foutmelding heeft opgeslagen. Een ontvangen abonnement-ID wordt afzonderlijk bewaard vóór de lokale eindstatus. Een onbekende overeenkomst kan zonder leverancier-ID niet als bevestigd beëindigd worden aangemerkt.

De WeFact-documentatie voor abonnementaanmaak beschrijft zowel aanmaak als eventuele facturatie. We leiden uit een foutantwoord daarom geen gegarandeerde terugdraaiing van alle stappen af. De pogingreferentie helpt onderzoek; zij maakt de leveranciersaanroep niet idempotent. Onbevestigde factuurregels blijven zichtbaar voor onderzoek en worden niet met een volgende achtergrondronde automatisch opnieuw ingediend. Dit voegt geen onbewezen automatische herstelhandeling toe.