IOSOR Kunskap
Slutanvändarens sändning belastar fortfarande en förbetald huvudbok
Inbäddad sändning debiterar fortfarande ISV-förbetalda plånbok. Skapa inte en sekundär huvudbok som produkten inte finansierar — reserveringar, omsändningar och idempotens förblir ärliga.
Inbäddade meddelanden känns kostnadsfria för slutanvändaren: de trycker på Skicka i SaaS-gränssnittet och ser en grön bock. Under ytan belastar varje framgångsrik sändning fortfarande en förbetald huvudbok som ägs av ISV. Det dyker inte upp någon sekundär plånbok bara för att produkten bäddade in ett API. Om ISV inte finansierar reserveringar måste sändningen misslyckas med ett ärligt produktfel — inte en falsk levererad status.
Fiktiv bokföring är det primära felsättet: en kreditmätare i appen som inte täcks av IOSOR-plånboken, SaaS-återbetalningar medan den förbetalda huvudboken förbrukas, eller omsändningar utan idempotens som dubbeldebiterar en OTP. Inbäddning döljer konsolen; ISV förblir den finansierande parten.
Arkitekturregel: slutanvändarens sändning ≡ ISV förbetald debitering. Varje designgranskning börjar där.
En huvudbok, även när gränssnittet visar produktkrediter
Meddelandepaket som säljs till kunder utgör ett kommersiellt ISV-lager. De måste mappas till förbetalda reserveringar och debiteringar på den enda IOSOR-plånbok som ISV finansierar. Ena kunds saldo som aldrig stämms av mot huvudboksrader är en skuldbomb för supporten. Exportera kundanvändning veckovis mot plånboksrader så att ekonomiavdelningen ser samma förbrukning som produkten.
Reserveringar och idempotens gäller fortfarande på inbäddade vägar
Serverbaserad sändning måste använda idempotensnycklar för OTP och transaktionsbaserad SMS. Ett dubbelklick i SaaS-gränssnittet får inte skapa två debiteringar för en användarhandling. Omsändningar efter time-out följer samma nyckel tills en slutgiltig DLR eller ett mappat fel uppnås. När plånboken inte kan göra en reservering, returnera en produktnära status för otillräckliga medel eller pauserad sändning.
Mappa produktfel till huvudbokens sanning
| SaaS UI-signal | Huvudbokens sanning | Tillåtet nästa steg |
|---|---|---|
| Skickat / levererat | Debitering + DLR-väg finns | Visa kvitto-ID |
| I kö | Reservering öppen eller sändning mottagen | Kontrollera status |
| Misslyckat / pausat | Reservering avvisad eller stoppspärr. |
Kanalöverlämningar stannar på samma plånbok
Om produkten senare lägger till e-post eller röst vid sidan av SMS, hamnar utgifterna fortfarande på samma förbetalda huvudbok om du inte genomför en överlämning till en andra kanal med godkännande från ekonomi. Inbäddning skapar inte en gratis sidokanal. Läs om plånboksnärhet innan du aktiverar en annan Live-ruta i SaaS-inställningarna.
Relaterade operativa vägar
- Andra kanalen i plånboken: utgiftsöverlämning
- idempotens, omsändning och pengar
- Säker tillämpning av hastighetsgränser för konton med flera klienter
Börja med IOSOR
Öppna IOSOR-konsolen och koppla ditt tenant-kreditsystem direkt till huvudreskontran för förbetalda plånböcker. Säkerställ att alla serverbaserade inbäddningsbegäranden skickar med en deterministisk idempotensnyckel innan en reservation görs på masterplånboken. Konfigurera din webhook-endpoint för att hantera inkommande leveransrapporter så att öppna reservationer stäms av mot slutgiltiga reskontradebiteringar eller frigöranden.
IOSOR sammanfattning
Ett inbäddat SaaS-gränssnitt kan visa anpassade meddelandekrediter för slutanvändare, men varje faktisk sändning är knuten till den enda förbetalda reskontran som ISV:n finansierar. Omsändningar, kanalexpansioner och användarstatus måste stämmas av direkt mot plånboksreservationer snarare än obekräftade gränssnittsabstraktioner.
Kräv strikta idempotensnycklar på serversidan och mappa varje gränssnittstillstånd för tenants till faktiska leveransrapporter i reskontran. Skapa inte obekräftade sekundära plånböcker och tillåt inte att gränssnittet gör omsändningar utan konkreta plånboksreservationer.
Var den här guiden till hjälp?
Relaterade guider
- Bädda in API jämfört med en white-label partnerportal
SaaS-produkter som bäddar in meddelanden stannar på ISV-ytan. White-label partnerportaler hör hemma under Partner — blanda inte varumärke, nycklar och operativt ägarskap.
- När en inbäddad klientgräns måste stoppa sändningen
Rättvisa takgränser i en ISV-produkt måste stoppa sändningen helt för den klienten — skicka aldrig ett falskt 200-svar från API:et när gränsen har nåtts.