A inicios de agosto armé un pedido de prueba con datos ficticios, dejé el modo prueba activado y lancé el primer ensayo de la integración con nuestro proveedor de facturación electrónica, la API que emite comprobantes con valor legal y sin botón de deshacer. La API procesó el pedido como cualquier otro: misma respuesta, ninguna marca de ensayo. Que fuera ensayo o no dependía de algo que yo no había mirado. Mi bandera de prueba viajaba en el pedido convencida de su autoridad.
Confiamos en una bandera
El botón de emitir quedó con el modo prueba prendido por defecto, y asumí que esa bandera por pedido decidía si el documento era de verdad. Nadie fue a comprobarlo. Una bandera que se llama test transmite una seguridad que no ha hecho nada por merecer.
La API ignoró la bandera y no dijo nada
Lo primero que revisé fue el nombre del campo, convencido de que lo habíamos escrito mal. Estaba bien escrito. La API no devolvió error ni advertencia: aceptaba la bandera y la ignoraba por completo. La documentación lo decía con todas las letras; yo no la había leído. El entorno lo define la configuración de la cuenta que tienes con el proveedor, y no viaja en ningún pedido.
Es como escribir "ANULADO, SOLO PRÁCTICA" en el concepto de un cheque y confiar en eso. El banco lee la cuenta y el monto, y paga. Si quieres saber si el cheque es de verdad, llamas al banco y preguntas de qué cuenta salió.
Un candado tosco
La mitigación fue fea a propósito: mientras la configuración local diga "prueba", el código bloquea la emisión por completo. Preferí un botón de emitir bloqueado antes que un ensayo que pudiera no serlo.
Dry-run, entorno verificado e idempotencia
Cuando el proveedor publicó una versión nueva de su API, cambié el candado por algo con criterio, porque traía las tres piezas que faltaban. Un endpoint de dry-run, el ensayo de verdad: corre todos los validadores y no emite nada. Una llamada que valida el token de acceso y responde en qué entorno está la cuenta, la fuente de verdad en lugar de mi suposición. Y claves de idempotencia obligatorias: un identificador único por pedido, para que un reintento después de un timeout devuelva el resultado original en vez de emitir dos veces.
La clave se deriva del pedido y siempre sale igual, así que un timeout ambiguo dejó de ser una ruleta. Reintentas con la misma clave y el proveedor responde lo que ya hizo, sin hacerlo dos veces.
79 de 79 y cero documentos emitidos
Verifiqué la migración completa contra la API real sin emitir un solo documento: todo el contrato se probó con el dry-run y con la verificación de entorno. La suite de pruebas de la integración cerró en 79 de 79 en verde.
La compuerta quedó así: antes de cada emisión, el sistema le pregunta al proveedor en qué entorno está la cuenta y lo compara con su propia configuración. Si las dos respuestas no coinciden, o si no hay respuesta, no emite nada. Falla cerrado a propósito.
La bandera de modo prueba sigue viajando en cada pedido, por costumbre. Ya no le creemos nada: del entorno responde el único que lo conoce de verdad, y se le pregunta cada vez.
