Entornos
Hay dos, prueba y producción, y el que aplica lo decide la key que uses. No hay un parámetro que cambiar ni una cabecera que recordar.
Cómo se eligen
El prefijo de la key lo dice todo: belfort_test_sk_… opera en prueba y
belfort_live_sk_… en producción. La misma URL base sirve a los dos.
Que el entorno viaje en la credencial y no en un parámetro es deliberado. Un parámetro se olvida, se copia mal entre servicios y acaba mandando datos reales a un entorno de pruebas sin que nadie lo note. Un prefijo de key no se olvida: o tienes la credencial correcta o no la tienes.
El aislamiento es real
No es un campo is_test que alguien puede olvidar filtrar. La partición está en las
consultas: una key de prueba no puede leer, escribir ni listar nada de producción, y al revés.
Un identificador de un entorno no existe en el otro — pedirlo devuelve
404, igual que si perteneciera a otra organización.
Los webhooks siguen la misma regla: un endpoint registrado con una key de prueba solo recibe eventos de prueba. No hay forma de que un evento real llegue a tu entorno de desarrollo.
Qué cambia en prueba
- No cuesta. Las verificaciones de prueba no consumen créditos.
- Es determinista. El resultado depende de los datos de entrada, no del azar, así que puedes escribir tests que esperen un veredicto concreto y forzar cada rama —aprobada, rechazada, revisión manual— sin buscar la imagen adecuada.
- No se consulta a fuentes gubernamentales. Las respuestas se simulan con la misma forma que las reales.
- Los límites son más bajos. Ver límites de uso.
Antes de pasar a producción
- Verifica la firma de los webhooks, no solo que llegue el cuerpo.
- Trata los 429 según su código: algunos se arreglan esperando y otros no. Ver límites de uso.
- Fija tu versión de API en las peticiones.
- Comprueba que tus claves secretas no aparecen en ningún artefacto que llegue a un navegador.