L'envoi de l'utilisateur final débite toujours un seul grand livre prépayé

La messagerie intégrée semble gratuite pour l'utilisateur final : il clique sur Envoyer dans l'interface SaaS et voit un coche vert. En arrière-plan, chaque envoi réussi débite toujours un seul grand livre prépayé détenu par l'ISV. Il n'y a pas de second portefeuille qui apparaît magiquement sous prétexte que le produit a intégré une API. Si l'ISV ne finance pas les réserves, l'envoi doit échouer avec une erreur produit explicite et non avec un faux statut de livraison.

La comptabilité fictive est le mode de défaillance classique : un compteur de crédits in-app non adossé au portefeuille IOSOR, des remboursements SaaS pendant que le grand livre prépayé se consomme, ou des retries sans idempotence qui débitent deux fois un même OTP.

Un seul grand livre, même quand l'UI affiche des crédits produit

Les packs de messages vendus aux clients représentent une couche commerciale propre à l'ISV. Ils doivent être directement associés aux réserves et débits prépayés du portefeuille unique IOSOR financé par l'ISV. Un solde client qui ne concorde jamais avec les lignes du grand livre constitue une dette de support critique.

Les réserves et l'idempotence s'appliquent toujours aux parcours intégrés

L'envoi côté serveur doit impérativement utiliser des clés d'idempotence pour les SMS transactionnels et les codes OTP. Un double-clic dans l'interface utilisateur du SaaS ne doit en aucun cas générer deux débits pour une seule action utilisateur.

Associer les erreurs produit à la vérité du grand livre

Les transferts de canaux restent sur le même portefeuille

Si le produit intègre ultérieurement l'e-mail ou la voix en plus du SMS, les dépenses continuent de s'imputer sur le même grand livre prépayé, sauf si un transfert vers un second canal est validé par l'équipe financière. L'intégration ne crée pas de canal gratuit secondaire.

Parcours opérationnels associés

• Second canal sur le portefeuille : transfert des dépenses
• idempotence, retries et argent
• Application sécurisée des limites de débit pour les comptes multi-tenant

Commencez avec IOSOR

Ouvrez la console IOSOR et associez directement le systeme de credit de votre locataire au grand livre principal du portefeuille prepaie. Veillez a ce que toutes les requetes d'integration cote serveur transmettent une cle d'indempotence deterministe avant de placer une retenue sur le portefeuille maitre. Configurez votre point de terminaison de webhook pour traiter les rapports de livraison entrants afin que les retenues ouvertes se resolvent proprement en debits ou en liberations definitifs du grand livre.

À retenir — IOSOR

Une interface SaaS integree peut presenter des credits de message personnalises aux utilisateurs finaux, mais chaque envoi reel est lie au portefeuille prepaie unique finance par l'editeur de logiciels independant. Les nouvelles tentatives, les expansions de canaux et les signaux d'etat de l'utilisateur doivent se reconcilier directement avec les retenues du portefeuille plutot qu'avec des abstractions d'interface utilisateur non garanties.

Imposez des cles d'indempotence strictes cote serveur et associez chaque etat d'interface utilisateur du locataire a de verponses de rapport de livraison reelles du grand livre. Ne creez pas de portefeuilles secondaires non garantis et ne permettez pas aux nouvelles tentatives de l'interface utilisateur du locataire de s'executer sans retenues concretes dans le grand livre.