L'invio dell'utente finale addebita comunque un unico mastro prepagato

La messaggistica integrata appare gratuita per l'utente finale: seleziona Invia all'interno dell'interfaccia SaaS e visualizza un segno di spunta verde. Tuttavia, in background, ogni invio con esito positivo addebita comunque l'unico mastro prepagato gestito dall'ISV. Non esiste un secondo wallet che compare per il solo fatto che il prodotto ha integrato un'API. Se l'ISV non copre i blocchi di garanzia, l'invio deve fallire con un errore di prodotto trasparente e mai con un falso stato di consegna.

Un solo mastro, anche quando l'interfaccia mostra crediti di prodotto

I pacchetti di messaggi venduti ai clienti rappresentano un livello commerciale dell'ISV. Devono essere associati ai blocchi temporanei e agli addebiti prepagati sull'unico wallet IOSOR finanziato dall'ISV. Un saldo cliente che non concorda mai con le voci del mastro si trasforma in un debito operativo per l'assistenza.

Blocchi e idempotenza continuano ad applicarsi sui percorsi integrati

L'invio lato server deve obbligatoriamente utilizzare chiavi di idempotenza per SMS transazionali e codici OTP. Un doppio clic nell'interfaccia utente del SaaS non deve mai generare due addebiti per una singola azione dell'utente. I retry successivi a un timeout devono continuare a utilizzare la stessa chiave fino al ricevimento di un DLR finale o di un errore mappato.

Mappare gli errori di prodotto alla verità del mastro

I passaggi di canale rimangono sullo stesso wallet

Se in seguito il prodotto aggiunge e-mail o voce accanto agli SMS, la spesa continuerà a gravare sullo stesso mastro prepagato, a meno che non venga eseguito un passaggio formale di canale approvato dal settore finanziario. L'integrazione non crea un canale secondario gratuito. Consulta la documentazione sull'adiacenza del wallet prima di attivare un nuovo modulo nelle impostazioni del SaaS.

Percorsi operativi correlati

• Secondo canale sul wallet: passaggio di consegne della spesa
• idempotenza, retry e denaro
• Applicazione sicura dei limiti di rate per account multi-tenant

Inizia con IOSOR

Apri la console IOSOR e mappa il sistema di crediti del tuo tenant direttamente sul registro principale del portafoglio prepagato. Assicurati che tutte le richieste di integrazione lato server passino una chiave di idempotenza deterministica prima di applicare un blocco sul portafoglio principale. Configura il tuo endpoint webhook per elaborare i DLR in arrivo, in modo che i blocchi aperti si risolvano chiaramente in addebiti o rilasci definitivi sul registro.

Sintesi IOSOR

Un'interfaccia SaaS integrata puo presentare crediti di messaggio personalizzati agli utenti finali, ma ogni invio reale si collega al singolo portafoglio prepagato finanziato dall'ISV. I tentativi, le espansioni di canale e i segnali di stato dell'utente devono riconciliarsi direttamente con i blocchi del portafoglio anzianche con astrazioni di interfaccia utente prive di riscontro.

Imponi rigorose chiavi di idempotenza lato server e mappa ogni stato dell'interfaccia utente del tenant a risposte DLR reali del registro. Non inventare portafogli secondari privi di copertura e non consentire ai tentativi dell'interfaccia utente del tenant di essere eseguiti senza concreti blocchi sul registro.