IOSOR

IOSOR Kennis

Eindgebruiker-verzendingen raken nog steeds één prepaid grootboek

Embedded Send debiteert nog steeds de ISV-prepaid-wallet. Bedenk geen tweede grootboek dat het product niet financiert — reserveringen, retries en idempotentie blijven eerlijk.

Embedded messaging voelt gratis voor de eindgebruiker: zij tikken op Verzenden binnen de SaaS-UI en zien een groen vinkje. Onder het oppervlak raakt elke succesvolle indiening nog steeds één prepaid grootboek dat eigendom is van de ISV. Er verschijnt geen tweede wallet omdat het product een API heeft ingebed. Als de ISV reserveringen niet financiert, moet het verzenden mislukken met een eerlijke productfout — niet met een nep-geleverde status.

Fictieve boekhouding is het faalmechanisme: een in-app creditteller die niet wordt gedekt door de IOSOR-wallet, SaaS-terugbetalingen terwijl het prepaid grootboek leegloopt, of retries zonder idempotentie die één OTP dubbel debiteren. Embed verbergt de console; de ISV blijft de gefinancierde partij.

Architectuurdocumentlijn: eindgebruiker verzendt ≡ ISV prepaid debitering. Elke ontwerpbeoordeling begint daar.

Één grootboek, zelfs als de UI producttegoeden toont

Berichtenpakketten die aan tenants worden verkocht, vormen een commerciële ISV-laag. Ze moeten worden gekoppeld aan prepaid reserveringen en debiteringen op de enkele IOSOR-wallet die de ISV financiert. Een tenant-saldo dat nooit aansluit op grootboekregels is een tijdbom voor ondersteuning. Exporteer tenant-gebruik wekelijks tegen wallet-regels, zodat financiën dezelfde uitgaven ziet als het product.

Reserveringen en idempotentie blijven van kracht op embedded paden

Verzending aan de serverzijde moet idempotentie-sleutels gebruiken voor OTP en transactionele SMS. Een dubbelklik in de SaaS-UI mag geen twee debiteringen veroorzaken voor één gebruikersactie. Retries na een timeout volgen dezelfde sleutel tot een definitieve DLR of een gemapte fout.

Koppel productfouten aan de grootboekwerkelijkheid

SaaS UI signaal Grootboekwerkelijkheid Toegestane vervolgstap
Verzonden / geleverd Debitering + DLR-pad bestaat Toon ontvangstbewijs-ID
In wachtrij Reservering open of ingediend Status pollen
Mislukt / gepauzeerd Reservering geweigerd of stop A.

Kanaaloverdrachten blijven op dezelfde wallet

Als het product later e-mail of spraak toevoegt naast SMS, landen de uitgaven nog steeds op hetzelfde prepaid grootboek, tenzij u een overdracht naar een tweede kanaal uitvoert met goedkeuring van financiën. Embed creëert geen gratis zijpad. Lees Wallet-aangrenzendheid voordat u nog een Live-tegel inschakelt in de SaaS-instellingen.

Gerelateerde operationele paden

Begin met IOSOR

Open de IOSOR Console en koppel je tenant-kredietsysteem direct aan het primaire prepaid wallet-grootboek. Zorg ervoor dat alle server-side embed-aanvragen een deterministische idempotentiesleutel meesturen voordat er een reservering wordt geplaatst op de hoofdwoning. Configureer je webhook-eindpunt om binnenkomende DLR-meldingen te verwerken, zodat openstaande reserveringen netjes worden omgezet in definitieve grootboekafschrijvingen of vrijgaven.

IOSOR-les

Een ingebedde SaaS-interface kan aangepaste berichttegoeden tonen aan eindgebruikers, maar elke echte verzending is gekoppeld aan het enkele prepaid grootboek dat door de ISV wordt gefinancierd. Retries, kanaaluitbreidingen en gebruikersstatusseignalen moeten direct worden afgestemd op wallet-reserveringen in plaats van niet-gedekte UI-abstracties.

Hanteer strikte server-side idempotentiesleutels en koppel elke tenant-UI-status aan echte grootboek-DLR-antwoorden. Bedenk geen niet-gedekte secundaire wallets en sta niet toe dat UI-retries van tenants worden uitgevoerd zonder concrete grootboekreserveringen.

Was deze gids nuttig?

Gerelateerde gidsen