El tráfico sandbox no debe golpear la billetera

El tráfico sandbox nunca debe abrir un prepaid hold. Si una clave Live se filtra a un harness de prueba, trátelo como incidente — no como atajo para «ver un DLR real más rápido» antes de la semana piloto.

IOSOR espera que los carriles de prueba queden planos en la billetera. Una credencial Live filtrada convierte el CI en motor de gasto: reintentos, jobs de carga y scripts de demo debitan como tráfico piloto. Detenga la fuga antes de debatir por qué staging «necesitaba» alcance de producción para una captura. Mantenga el reloj del incidente corto: cada hora de Live en CI es prepaid que no se recupera tras rotar. Nombre al dueño de la clave en el ticket antes del primer comentario de finanzas.

Detecte claves Live en rutas de prueba

Escanee secrets de CI, hosts de staging y archivos .env locales buscando prefijos Live con cadencia fija. Cualquier hallazgo abre ticket de incidente: revoque, rote y confirme el mismo día que no hay hold abierto desde esa clave.

Incluya runners compartidos y contenedores cron olvidados — conservan secretos viejos más tiempo que un portátil. Publique el dueño del escaneo para que el ticket no rebote entre developers y fraud ops toda la jornada.

Congelar holds nacidos de tráfico Live filtrado

Si los jobs de prueba ya abrieron holds en la billetera, páuselos y exporte las filas atascadas con marcas de tiempo. No deje que el harness siga reintentando hacia débito Live mientras investiga la ruta del secreto.

Mapee cada hold atascado al job id que lo generó. Ese mapa es lo que finanzas necesita cuando pregunte si el débito fue «piloto real» o una clave filtrada quemando prepaid.

Separe picos de abuso de errores sandbox

Un pico de abuso se detiene sin falso éxito. Una clave Live en pruebas se parece en el ledger — ambos exigen parada dura. Etiquete el incidente para que fraud ops y developers no hablen en paralelo: abuso vs fuga de credencial vs staging mal enlazado.

Etiquetas erróneas queman un día de chat mientras los holds envejecen en la billetera. Ponga la etiqueta en el título del ticket antes del primer status update a finanzas.

Vuelva a probar el aislamiento tras la rotación

Tras revoke y rotate, reejecute la prueba OTP sandbox solo con la clave sandbox. Exporte cero hold en esa ventana. Solo entonces restaure automatización de staging y secrets de CI que apunten a credenciales sandbox.

Si la prueba aún muestra un hold, pare: queda otro secreto Live en la ruta. No reabra volumen hasta que el ledger vuelva a plano y el escaneo esté limpio.

Rutas operativas relacionadas

• paso de sandbox a producción
• Semana de incidencias en el monedero: una retención atascada no es un segundo…
• Pico de abuso: detención sin falso éxito

Comience con IOSOR

Busque claves Live en cada host de prueba. Revoque cualquier fuga, exporte holds abiertos y reenlace el CI solo a sandbox. Envíe un OTP sandbox y pruebe que el ledger quedó plano antes de reiniciar automatización — y deje el escaneo en la checklist ops semanal.

Conclusión IOSOR

Una clave Live en el harness de prueba es un incidente, no una función. Los carriles sandbox deben dejar la billetera plana: detecte y rote, congele holds, y demuestre aislamiento con un OTP sandbox de cero hold. No restaure la automatización de CI ni use «solo para ver el DLR» como excusa para dejar Live en el harness.