IOSOR Kunnskap
Sluttbrukersending belaster fortsatt én forhåndsbetalt hovedbok
Innbygd sending belaster fortsatt ISV-ens forhåndsbetalte wallet. Ikke finn opp en sekundær hovedbok som produktet ikke finansierer.
Når sluttbrukere sender meldinger direkte i et innbygd SaaS-grensesnitt, blir den forhåndsbetalte hovedboken til ISV-en likevel belastet bak kulissene. Det finnes ingen egen lommebok for sluttbrukeren, så manglende dekning krever en tydelig produktfeil heller enn en falsk levert-status. Unngå fiktiv regnskapsføring ved å koble kredittmåleren i appen mot den faktiske saldoen og sikre at re-forsøk ikke dobbelbelaster saldoen.
Én hovedbok, selv når brukergrensesnittet viser produktkreditter
Meldingspakker solgt til leietakere er et ISV-kommersielt lag. De må kartlegges til forhåndsbetalte reservasjoner og belastninger på den enkelte IOSOR-walleten ISV-en finansierer. En leietakersaldo som aldri avstemmes mot hovedbokslinjer er en supportbombe. Eksporter leietakerforbruk ukentlig mot wallet-linjer slik at økonomi ser det samme forbruket som produktet gjør.
Reservasjoner og idempotens gjelder fortsatt på innbygde stier
Sending fra serversiden må bruke idempotentitetsnøkler for OTP og transaksjons-SMS. Et dobbelklikk i SaaS-grensesnittet må ikke skape to belastninger for én brukerhandling. Nye forsøk etter tidsavbrudd følger samme nøkkel inntil en terminal DLR eller en kartlagt feil.
Når walleten ikke kan reservere beløpet, må du returnere en produktinnfødt status om utilstrekkelige midler eller pauset sending. Returner aldri HTTP 200 med levert-semantikk når reservasjonen feilet.
Kartlegg produktfeil til hovedbokens sannhet
| SaaS UI-signal | Hovedboksannhet | Tillatt neste trinn |
|---|---|---|
| Sendt / levert | Belastning + DLR-sti eksisterer | Vis kvitterings-ID |
| I kø | Reservasjon åpen eller akseptert | Sjekk status |
| Feilet / pauset | Reservasjon avvist eller sperret | Prøv igjen kun ved ny handling |
| Falsk suksess | Ingen belastn. |
Kanaloverleveringer forblir på samme wallet
Hvis produktet senere legger til e-post eller tale ved siden av SMS, lander forbruket fortsatt på den samme hovedboken med mindre du kjører en kanaloverlevering med godkjenning fra økonomi. Innbygging skaper ikke en gratis sidekanal. Les om wallet-tilknytning før du aktiverer en ny Live-flis i SaaS-innstillingene.
Relaterte driftstier
- Andre kanal på wallet: forbruksoverlevering
- idempotens, nytt forsøk og penger
- Håndheving av hastighetsgrenser på tvers av multi-tenant-kontoer
Start med IOSOR
Apne IOSOR-konsollen og koble leietakarkredittsystemet direkte til hovudrekneskapen for førehandsett forhald. Sjå til at alle server-side-innbyggingsførespurnader sender ein deterministisk idempotensnøkkel før du set ei sperring på hovudlommeboka. Konfigurer webhook-endepunktet til å behandle innkommande DLR-ar slik at opne sperringar blir løyste opp til endelege reskontrodebetar eller frigiringar.
IOSOR-lærdom
Eit innbygd SaaS-grensesnitt kan vise tilpassa meldingskreditsar til sluttopplevarar, men kvar einaste faktiske utsending er knytt til den enkelte førehandsbetalte reskontroen som ISV-en finansierer. Returförsök, kanalutvidingar og brukastatusignal må stemme overens direkte mot lommeboksperringar i staden for ufullstendige UI-abstraksjonar.
Handhev streng idempotens på serversida og koble kvar leietakar-UI-tilstand til sanne reskontro-DLR-svar. Ikkje lag ufinansierte sekundærlommebøker eller lat leietakar-UI-returförsök køyre utan konkrete reskontrosperringar.
Var denne guiden nyttig?
Relaterte veiledninger
- Innbygging av API versus en white-label partnerportal
SaaS-produkter som bygger inn meldinger forblir i ISV-grensesnittet. Partnerportaler hører hjemme under Partner — ikke bland merkevare, nøkler og eierskap.
- Når et innebygd tenant-tak må stoppe utsending
Fair-share-tak i et ISV-produkt må stoppe utsending for den tenanten — aldri returnere en falsk levert API 200 når taket er nådd.