Trimiterea utilizatorului final debitează tot un singur registru preplătit

Trimiterea de mesaje încorporată pare gratuită pentru utilizatorul final: apăsă Trimitere în interfața SaaS și văd bifă verde. Sub suprafață, fiecare trimitere reușită debitează în continuare un singur registru preplătit deținut de ISV. Nu apare un al doilea portofel doar pentru că produsul a încorporat un API. Dacă ISV-ul nu finanțează rezervările, trimiterea trebuie să eșueze cu o eroare cinstită de produs — nu cu o stare falsă de livrare.

Contabilitatea fictivă este modul de eșec: un contor de credite în aplicație care nu este susținut de portofelul IOSOR, rambursări SaaS în timp ce registrul arde, sau reîncercări fără idempotență care debitează de două ori un OTP. Încorporarea ascunde consola; ISV-ul rămâne partea care finanțează.

Linie de arhitectură: trimitere utilizator final ≡ debit preplătit ISV. Fiecare revizuire de design începe acolo.

Un singur registru, chiar și când interfața arată credite de produs

Pachetele de mesaje vândute clienților sunt un strat comercial al ISV-ului. Acestea trebuie să se mapeze pe rezervări preplătite și debitări pe singurul portofel IOSOR finanțat de ISV. Un sold al clientului care nu se reconciliază niciodată cu rândurile registrului este o bombă pentru suport.

Rezervările și idempotența se aplică în continuare pe căile încorporate

Trimiterea pe partea de server trebuie să utilizeze chei de idempotență pentru OTP și SMS tranzacțional. Un dublu clic în interfața SaaS nu trebuie să creeze două debitări pentru o singură acțiune a utilizatorului. Reîncercările după expirare urmează aceeași cheie până la un DLR terminal sau o eroare mapată.

Mapați erorile de produs la adevărul registrului

Predările de canale rămân pe același portofel

Dacă produsul adaugă ulterior email sau voce pe lângă SMS, cheltuielile ajung tot pe același registru, cu excepția cazului în care rulați o predare de canal secundar cu aprobarea departamentului financiar. Încorporarea nu creează un canal secundar gratuit. Citiți despre adiacența portofelului înainte de a activa o altă pictogramă Live în setările SaaS.

Căi operaționale conexe

• A doua canal pe portofel: predarea cheltuielilor
• idempotență, reîncercări și bani
• Aplicarea limitelor de rată pentru conturile multi-tenant

Începeți cu IOSOR

Deschide consola IOSOR și mapează sistemul de credite al chiriașului tău direct în registrul portofelului prepaid principal. Asigură-te că toate cererile de integrare de pe server transmit o cheie de idempotență deterministă înainte de a plasa o reținere pe portofelul principal. Configurează punctele finale pentru webhook ca să proceseze notificările de livrare primite, astfel încât reținerile deschise să se deconteze curat în debitări sau eliberări finale ale registrului.

Rezumat IOSOR

O interfață SaaS integrată poate prezenta credite de mesaje personalizate utilizatorilor finali, dar fiecare expediere reală se leagă de un singur portofel prepaid finanțat de ISV. Reîncercările, extinderile de canale și semnalele de stare ale utilizatorului trebuie să se reconcilieze direct cu reținerile din portofel, în loc de abstracțiuni de interfață neacoperite.

Implică chei de idempotență stricte pe partea de server și mapează fiecare stare de interfață a chiriașului la răspunsuri DLR reale ale registrului. Nu inventa portofel secundare neacoperite și nu permite reîncercărilor din interfața chiriașului să se execute fără rețineri concrete în registru.