Identifiants sandbox qui ne brûlent pas le débit Live

Les identifiants sandbox existent pour que l’engineering envoie du trafic de test sans toucher le ledger prépayé. Un débit Live depuis une clé sandbox doit être impossible — pas un avertissement mou dans un README que personne ne lit pendant un incident.

IOSOR traite le sandbox comme une posture de crédit séparée : OTP et alertes de test peuvent réussir dans la voie sandbox pendant que le portefeuille reste plat. Si un hold ou un débit apparaît depuis une clé étiquetée sandbox, l’identifiant est mal scopé et doit être révoqué avant le prochain run CI.

Séparez les clés sandbox des holds Live

Créez dans Developers une clé sandbox qui ne peut pas ouvrir de hold prépayé. Prouvez qu’un envoi OTP de test dans la voie sandbox réussit avec zéro débit portefeuille et zéro frais MRC la même minute. Exportez le ledger de cette fenêtre et gardez la preuve à côté de l’id de clé.

Si une ligne hold apparaît, révoquez immédiatement cette clé et traitez-la comme un défaut d’identifiant — pas un test instable. Réémettez une clé sandbox correctement scopée et répétez la preuve jusqu’à ce que le ledger reste plat.

Liez CI et staging uniquement aux scopes sandbox

Pointez les variables d’intégration continue et de staging uniquement vers des identifiants sandbox. Ne collez jamais une clé Live dans un secret GitHub, un docker-compose, un .env de laptop pour démos ou un dossier partagé de gestionnaire de mots de passe étiqueté « test ».

Faites tourner toute clé Live qui a apparu dans un harness de test. Enregistrez l’heure de rotation pour que la finance rattache un débit stray à la fenêtre de fuite.

Prouvez l’isolement du débit avant le premier pilote

Exportez le ledger de la fenêtre d’envoi sandbox avant d’inviter l’hôte pilote. Confirmez : aucun hold, aucun débit, aucun chemin Live déclenché depuis la clé sandbox.

Répétez l’export après la première semaine de CI pour que le drift ne réintroduise pas silencieusement une clé Live via une variable de workflow oubliée.

Les habitudes de cutover restent sous Developers

Lors de la promotion d’un build, suivez la checklist de cutover Live sous Developers — émettez une nouvelle clé Live, révoquez le sandbox des hôtes de production, et smokez la fraîcheur du vault avant runway vert. Ne réutilisez pas le secret sandbox comme clé Live temporaire « juste pour le pilote ».

Le cutover est un changement d’identifiant plus un contrôle de ledger, pas le flip d’un flag de config.

Chemins ops associés

Chemins liés :

• bascule sandbox vers production
• Validation des différences de portée entre sandbox et production
• Semaine pilote du portefeuille : vérité des retenues et débits en direct

Commencez avec IOSOR

Dans Developers, émettez une clé sandbox, envoyez un OTP sur un E.164 de test consenti, et exportez le ledger de cette minute. Confirmez zéro hold et zéro débit. Verrouillez le CI sur cet id de clé. Ensuite demandez Live pour le pilote et révoquez sandbox sur les hôtes Live.

À retenir — IOSOR

Sur « Identifiants sandbox qui ne brûlent pas le débit Live » : l’isolement est le produit. Une clé sandbox qui peut ouvrir un hold est un défaut, pas une commodité. Gardez le CI sur des scopes sandbox, prouvez un ledger plat avant le pilote, et traitez le cutover comme changement d’identifiant plus contrôle de ledger sous Developers.