Lista de verificación para salir a producción

Una lista práctica para llevar una integración de sandbox a producción. Cada elemento está respaldado por el comportamiento que la API expone hoy. Cuando un valor o garantía dependa del entorno, confírmalo con tu contacto de onboarding en Migo en lugar de asumir un valor por defecto.

Credenciales y autenticación

• Credenciales de producción solicitadas por separado de las de sandbox — las credenciales y llaves no se comparten entre entornos. Consulta Entornos y URLs base.
• Merchant token guardado en tu gestor de secretos, nunca incrustado en código del lado del cliente. Es de larga duración y no tiene flujo de refresh — rótalo a través de tu contacto en Migo si pudo haber quedado expuesto. Consulta Autenticación → Merchant token.
• Header Authorization correcto según la superficie: los Payment Links aceptan el token con o sin el prefijo Bearer ; Alternative Payments envía convencionalmente Bearer <token>. Consulta Autenticación → Formato del header por endpoint.
• Si tu integración usa el flujo interno de JWT de corta duración, tu cliente refresca el access token ante un 401 TOKEN_EXPIRED en lugar de volver a iniciar sesión, y descarta el refresh token anterior (los refresh tokens son de un solo uso). Consulta Autenticación → Refresh.
• IPs de tus servidores en la lista permitida con Migo (origen saliente de tus webhooks en producción).

Entornos

• URLs base de producción en lugar de las de sandbox — por ejemplo https://mw.migopayments.com (Middleware) en vez de https://sb-mw.migopayments.com. Matriz completa en Entornos y URLs base.
• No quedan tokens, hosts ni tarjetas de prueba de sandbox en la configuración de producción. Un token de sandbox no funciona contra un host de producción.

Correctitud de la integración

• Recorriste los escenarios recomendados en sandbox: cobro de happy path, cobro rechazado, 3-D Secure y un reenvío/replay duplicado. Consulta Prueba tu integración.
• Tokenización confirmada — almacenas el cardId que devuelve Migo, nunca el PAN. Consulta Seguridad y alcance PCI.
• Obtienes los identificadores (como el uid / reference de la transacción) de las respuestas reales de la API en lugar de construirlos tú mismo.

Webhooks

• El receptor de webhooks usa HTTPS con un certificado válido (producción exige HTTPS).
• Webhooks entrantes protegidos con lista de IPs permitidas de tu lado. El esquema de firma Ed25519 está documentado como estándar objetivo pero aún no se aplica de extremo a extremo — no dependas únicamente de la validación de firma hasta que Migo confirme que está activa para tu tenant.
• El handler responde 2xx rápidamente y delega el trabajo pesado; una respuesta no-2xx o un timeout se trata como fallo de entrega y se reintenta.
• Confirmaste con Migo el comportamiento de entrega/reintentos que aplica a tu flujo (la ruta de despacho y la semántica de reintentos dependen del flujo que Migo seleccionó para tu cliente).

Manejo de errores e idempotencia

• Cada llamador inspecciona CustomResponse.error.code y mapea al menos los códigos del Catálogo de errores.
• El handler de webhooks es idempotente — las entregas son al-menos-una-vez, así que deduplica con un identificador estable del cuerpo (por ejemplo uid, o (uid, status)). Los reenvíos no deben cumplir la misma orden dos veces.
• Los reintentos del lado del cliente ante fallos transitorios usan backoff exponencial. (Hoy no existe un header genérico Idempotency-Key en las solicitudes POST — confirma con Migo el contrato de deduplicación de cualquier endpoint específico.)

Observabilidad

• Alertas sobre tasas elevadas de 4xx / 5xx de los endpoints de Migo.
• Alertas sobre fallos del handler de webhooks y vencimiento del certificado TLS (los certificados vencidos se manifiestan como fallos de entrega).
• Logging que nunca registra PANs completos, CVVs ni tokens.
• Sabes cómo solicitar un reporte de entregas a tu contacto en Migo y cómo pedir el reenvío de una entrega perdida (no existe un endpoint de replay autoservicio).

Corte a producción

• TLS 1.2+ aplicado de extremo a extremo.
• Revisión de seguridad completada según tu alcance PCI — consulta Seguridad y alcance PCI.
• Runbook de incidentes listo: contacto y ruta de escalamiento en Migo, además de tu procedimiento de rotación del merchant token.
• Ejecuta la matriz de pruebas recomendada contra producción con un titular de tarjeta desechable antes de tu primera transacción real.