Quand la grâce prend fin, les pauses s'activent — Le direct n'est pas un faux succès

Dès que la période de grâce de la recharge automatique expire, vous devez immédiatement déclencher les pauses d'envoi. Ne vous laissez pas tromper par un statut actif en direct qui masque en réalité un défaut de paiement. Cette règle essentielle évite de délivrer vos services à perte en attendant la régularisation.

La transition de la période de grâce à l'arrêt complet

Dans l'écosystème IOSOR, le mécanisme de recharge automatique est conçu pour éviter l'interruption de service lors de légers retards de paiement. Cependant, une fois que la période de grâce définie pour une transaction par carte échouée expire, la plateforme passe d'un état permissif à un arrêt complet (hard stop). Cette transition est cruciale pour maintenir l'intégrité du modèle prépayé.

Logique du grand livre et drapeaux Traffic_OK

Chaque transaction au sein de la plateforme est régie par un grand livre en temps réel. Lorsqu'une requête de message est reçue via API ou webhook, le système vérifie le drapeau traffic_ok associé à votre sous-compte. Si la période de grâce de recharge automatique est écoulée, ce drapeau est révoqué. Il est important de noter qu'IOSOR ne pratique pas le reporting de 'faux succès'.

Gestion des numéros JIT et retenues MRC

Les ressources de numérotation dans IOSOR sont gérées via un système d'allocation Just-In-Time (JIT). Lorsqu'un solde entre dans un état d'arrêt complet après une période de grâce échouée, le système doit toujours comptabiliser les frais mensuels récurrents (MRC) pour tous les numéros E.164 actuellement assignés à votre compte.

Gestion des réponses Webhook OTP et SMS

Lorsque le système entre en état de pause, la réponse API pour les requêtes OTP ou SMS sortantes passera d'un standard 202 Accepted à un code d'erreur spécifique indiquant un blocage lié au solde. Il est vital pour votre application de parser ces réponses correctement. Au lieu de recevoir un jeton Verify OK, votre système recevra une notification indiquant que le message a été supprimé. Cette distinction est fondamentale pour maintenir la fiabilité de vos flux de travail.

Ressources de conformité et de transparence

Pour mieux gérer votre portefeuille et comprendre les nuances de la suppression du trafic, nous vous recommandons de consulter nos guides détaillés sur les contrôles de solde et la vérité de livraison. Ces ressources expliquent les mécanismes sous-jacents de la gestion des messages ignorés et les règles spécifiques régissant les tentatives de paiement échouées. Surveiller ces paramètres aide à prévenir les temps d'arrêt inattendus dans les environnements de production.

Commencez avec IOSOR

Rendez-vous sur votre console IOSOR pour inspecter vos déclencheurs de secours de paiement et la gestion des erreurs de webhook. Assurez-vous que la logique de votre application gère explicitement les codes d'erreur API renvoyés lorsque traffic_ok passe à false après la période de grâce d'une carte refusée. Testez votre gestionnaire de files d'attente pour vérifier que l'envoi sortant s'interrompt instantanément au lieu d'attendre de faux accusés de réception.

• Recharge automatique pour éviter l'interruption du trafic en direct
• La tentative du processeur ne doit pas doubler une recharge
• Preuve de Flash-Call avant la connexion de production

À retenir — IOSOR

Cet article a démontré qu'IOSOR applique l'état du grand livre en temps réel sans jamais délivrer de codes de statut faussement positifs. Dès que la période de grâce pour une tentative de rechargement automatique expire, le fanion traffic_ok révoque les privilèges d'envoi et renvoie des erreurs API explicites afin de préserver l'intégrité des comptes.