IOSOR

IOSOR Guides

Incident partenaire sans exposer les rails

Quand le trafic partenaire échoue, maintenez un statut en marque blanche : aucune marque de rail amont dans l'UI, les webhooks ou les macros de support lors d'une panne.

Une panne qui affiche le nom d'un rail amont dans une notification, un webhook ou un ticket partenaire constitue une fuite de marque en pleine crise, et non un « débogage utile ». Le parcours d'incident partenaire garde le langage des pannes en marque blanche : verrouillé, dégradé, en cours de nouvelle tentative, rétabli — jamais de marque de rail. Pas d'essai sur un double débit de bascule en vol ni d'analyse approfondie d'un statut bloqué au lancement.

Le langage des pannes reste en marque blanche

En cas d'échec : rétrogradez les libellés Ouvert/Live, affichez des codes de motif en marque blanche, sécurisez les champs webhook pour le partenaire et gelez les discussions de volume tant qu'il n'y a pas de preuve de rétablissement. L'examen informel de USD 1 000/mois reste bloqué tant qu'une surface nomme encore un rail.

Liste de contrôle des incidents quand le trafic est rouge

Surface Honnête en panne Expose les rails
Tableau de bord Verrouillé / dégradé + horodatage Alerte « Rail X en panne »
Erreur API Code client mappé Texte brut d'erreur de rail
Webhook Champs de statut nettoyés Marque / ID de rail dans le corps
Macro de support Motif en marque blanche Libellé « Demander au rail »
Ligne d'export Qui a notifié + surface Noms

Pas d'argent de bascule partielle ni d'essais de lancement bloqué

Les pages de bascule partielle enseignent la commutation en vol sans double règlement. Les pages de lancement bloqué enseignent un blocage/verrouillage honnête lorsque la piste est rouge. Cette page pose la question : quand le trafic partenaire échoue, le langage du statut reste-t-il en marque blanche ? Corrigez d'abord les textes destinés aux partenaires.

Chemin de rétablissement sans chaînes de marque

Après le rétablissement : rouvrez uniquement avec un langage de restauration en marque blanche, exportez qui a nettoyé et videz le cache des alertes.

Liste de contrôle partenaire pour les incidents sécurisés

  • Isoler les canaux partenaires avant de déboguer.
  • Purger les identifiants amont des journaux.
  • Vérifier qu'aucune réponse API ne renvoie de métadonnées de rail.
  • Garder les statuts d'erreur génériques et propres.

Commencez avec IOSOR

Ouvrez la console de la passerelle d'état IOSOR et verrouillez toutes les chaînes d'état destinées aux partenaires sur des codes de motif en marque blanche avant de mettre à jour les bannières d'incident. Auditez les charges utiles d'erreur API sortantes, les macros de réponse du support et les champs d'état des webhooks pour garantir qu'aucune chaîne d'erreur réseau brute ne fuite lors du trafic rouge.

À retenir — IOSOR

La confiance des partenaires repose sur un état d'incident transparent sans compromettre votre couche de marque blanche. Protéger les tableaux de bord des partenaires, les charges utiles d'erreur API et les notifications webhook derrière des codes d'erreur normalisés préserve l'identité de votre système et empêche l'exposition de l'infrastructure de transport sous-jacente lors de pannes inattendues.

Ce guide vous a-t-il aidé ?

Guides associés