Credenciales sandbox que no queman débito Live

Las credenciales sandbox existen para que ingeniería envíe tráfico de prueba sin tocar el ledger prepago. El débito Live desde una clave sandbox debe ser imposible — no una advertencia suave en un README que nadie lee durante un incidente.

IOSOR trata sandbox como una postura de crédito separada: OTP y alertas de prueba pueden tener éxito en el carril sandbox mientras la billetera permanece plana. Si aparece un hold o un débito desde una clave etiquetada sandbox, esa credencial está mal acotada y debe revocarse antes del siguiente CI.

Separe las claves sandbox de los holds Live

Cree en Developers una clave sandbox que no pueda abrir un hold prepago. Demuestre que un envío OTP de prueba en el carril sandbox devuelve éxito con cero débito de billetera y cero cargo MRC en el mismo minuto. Exporte el ledger de esa ventana y guarde la prueba junto al id de la clave.

Si aparece una fila de hold, revoque esa clave de inmediato y trátela como defecto de credencial — no como test inestable. Reemita una clave sandbox con alcance correcto y repita la prueba hasta que el ledger se mantenga plano.

Vincule CI y staging solo a alcances sandbox

Apunte las variables de integración continua y staging únicamente a credenciales sandbox. Nunca pegue una clave Live en un secreto de GitHub, un docker-compose, un .env de portátil para demos o una carpeta compartida del gestor de contraseñas etiquetada “test”.

Rote cualquier clave Live que haya aparecido en un arnés de prueba. Registre la hora de rotación para que finanzas pueda cruzar un débito stray con la ventana de fuga.

Pruebe el aislamiento de débito antes del primer piloto

Exporte el ledger de la ventana de envío sandbox antes de invitar al host piloto. Confirme: sin hold, sin débito y sin ruta Live disparada desde la clave sandbox.

Repita la exportación tras la primera semana de CI para que el drift no reintroduzca en silencio una clave Live por una variable de workflow olvidada.

Los hábitos de cutover quedan bajo Developers

Al promover un build, siga la checklist de cutover Live en Developers — emita una nueva clave Live, revoque sandbox de hosts de producción y haga smoke de frescura del vault antes del runway verde. No reutilice el secreto sandbox como clave Live temporal “solo para el piloto”.

El cutover es un cambio de credencial más una revisión de ledger, no el flip de un flag de configuración.

Rutas operativas relacionadas

Mantenga cutover y honestidad de cobertura adyacentes para que los equipos no inventen una tercera historia de claves:

• paso de sandbox a producción
• Validación de diferencias de alcance entre pruebas sandbox y producción
• Semana piloto de monedero: retenciones y débitos reales en tráfico vivo

Comience con IOSOR

En Developers, emita una clave sandbox, envíe un OTP a un E.164 de prueba consentido y exporte el ledger de ese minuto. Confirme cero hold y cero débito. Fije CI a ese id de clave. Solo entonces solicite una clave Live para el host piloto y revoque sandbox de cualquier host que lleve tráfico Live.

Conclusión IOSOR

Sobre «Credenciales sandbox que no queman débito Live»: el aislamiento es el producto. Una clave sandbox que puede abrir un hold es un defecto, no una comodidad. Mantenga CI en alcances sandbox, pruebe ledger plano antes del piloto y trate el cutover como cambio de credencial más chequeo de ledger bajo Developers.