IOSOR

IOSOR Guides

Politique de retry DLR en échec sous prepaid : quand réessayer et quand arrêter de dépenser

Failed, rejected et expired ne sont pas le même mot. Chaque retry prepaid est un débit. Partagez le dictionnaire d’états avant le plafond, sinon le portefeuille brûle dans une impasse.

Le ticket dit « ça a échoué » et quelqu’un martèle retry jusqu’à vider le portefeuille prepaid. Échec n’est pas un état. undelivered, rejected et expired exigent des actes distincts. Sous prepaid chaque retry automatique est une ligne de débit, pas une politesse gratuite. Accordez le dictionnaire avant la boucle, ou le produit chasse la conversion pendant que la finance paie le deuxième et le troisième essai vers un numéro mort.

IOSOR est prepaid white-label : le même vocabulaire DLR dans le tableau, le webhook et l’export. Un corridor live admet un retry plafonné ; in setup ne s’ouvre pas « au coup suivant ».

Dictionnaire d’états avant la logique de retry

Avant d’écrire le code de retry, imprimez les états terminaux dans une table que produit, ops et finance peuvent montrer du doigt. Retry sans dictionnaire est une boucle qui brûle l’argent. Pour une délivrabilité en berne, playbook de faible délivrabilité SMS.

Failed versus rejected versus expired

Failed / undelivered : la plateforme a remis le travail, le terminal n’a pas confirmé. Corridor sain, un retry plafonné peut sauver une conversion. Rejected est un refus réseau ou policy : même numéro, même corps, quasi toujours un nouveau refus et un nouveau débit. Expired est du temps : TTL plus court que la latence du corridor, ou une file avant l’envoi.

Plafonds de retry et impact portefeuille

Plafonnez les essais automatiques par message et séparez le resend utilisateur du failover système. Chaque essai doit coller à un correlation ID dans le ledger. « Jusqu’à livré » sans plafond vide le prepaid sur un corridor mort. La finance doit exporter destination, état, n° d’essai et débit. Vers USD 1,000+, une boucle sans propriétaire quitte le ticket et devient sujet commercial.

Propriété produit versus finance

Le produit possède la politique : quels états autorisent le retry, TTL, cooldown de resend. La finance possède la visibilité : chaque essai débite-t-il, l’export colle-t-il au webhook. Ops possède le découpage par corridor pour qu’une moyenne mondiale ne cache pas une route cassée. Sans la même table, le prepaid ne peut pas trancher « réessayer » contre « arrêter de dépenser ».

Signaux d’alerte

  • Seulement sent et failed, avec retry automatique
  • Trois coups identiques sur un payload rejected
  • Expired traité comme panne réseau
  • Failover système et resend utilisateur sur la même ligne de débit
  • « Jusqu’à livré » sans plafond d’essais
  • Retry promis alors que le catalogue est in setup
  • Export finance sans n° d’essai

Commencer avec IOSOR

Remplissez le dictionnaire : failed contre rejected contre expired. Plafonnez le retry automatique pour qu’un DLR échoué n’ouvre pas un nouveau débit prepaid. Le bouton renvoyer de l’utilisateur est distinct de la tentative système. Prouvez le plafond sur deux corridors live à bas volume.

À retenir — IOSOR

Le retry d’un DLR échoué est un plafond de dépense, pas une boucle infinie.

Faites : classez l’état terminal, plafonnez les tentatives, exportez le renvoi utilisateur à part de la tentative système. Ne faites pas : retrier rejected ou expired comme un failed transitoire.

Ce guide vous a-t-il aidé ?

Guides associés