Saltar al contenido principal
Migo Docs

Seguridad y alcance PCI

Lo que Migo maneja​

Migo opera como proveedor de servicio PCI-DSS Level 1. Dentro de nuestro perímetro manejamos:

  • Primary Account Numbers (PANs) — almacenados tokenizados, nunca devueltos en respuestas.
  • Bóveda y tokenización de datos del tarjetahabiente.
  • Autenticación 3-D Secure (integración ACS con redes de tarjetas).
  • Cifrado en reposo y en tránsito (TLS 1.2+).
  • Integración con el procesador de tarjetas, incluyendo intercambio de llaves para flujos card-present en crudo.
  • Scoring de fraude y suspensiones.

Lo que tú manejas​

Tu alcance PCI depende de cómo recolectes la tarjeta.

FlujoTu alcance PCINotas
Tokenizado vía Migo Wallet SDKSAQ-ALos datos de la tarjeta nunca tocan tus servidores. Recomendado.
Redirect / iframe alojado por MigoSAQ-ACampos de tarjeta dentro de un iframe propiedad de Migo.
Tu UI, tokenización en clienteSAQ-A-EPEl JS SDK envía directo a Migo; tú nunca ves el PAN.
Tus servidores recolectan el PAN completoSAQ-DAlcance PCI-DSS completo. Migo desaconseja este camino.
Card-present (POS)SAQ-P2PEEl terminal de hardware cifra los datos de la tarjeta; Migo los descifra dentro de su entorno con alcance PCI.

Lo que nunca debes hacer​

  • Nunca registres el PAN, CVV, datos de track o PIN — ni una sola vez, ni siquiera en desarrollo.
  • Nunca almacenes CVV ni PIN. Migo tampoco lo hace.
  • Nunca envíes PANs completos por email.
  • Nunca pongas tokens (cardId) en URLs registradas en analítica de terceros. No son sensibles como un PAN, pero identifican una tarjeta real.

Controles de red​

  • TLS 1.2+ requerido en todo el tráfico de la API. TLS 1.0 y 1.1 son rechazados.
  • HSTS con includeSubDomains; preload.
  • Allowlisting de IPs disponible para tráfico server-to-server (solicítalo a tu contacto Migo).
  • Firmas de webhook — la firma de webhooks con Ed25519 es el estándar objetivo pero aún no se hace obligatoria de extremo a extremo en toda la plataforma. Los hooks entrantes de procesador actualmente usan esquemas HMAC / firma específicos del procesador. Confirma el esquema activo y la llave pública con Migo antes de depender de la verificación de firma.

Gestión de llaves​

  • Migo firma los JWT con Ed25519. La llave pública se comparte contigo — valida la firma de cada JWT antes de confiar en los claims.
  • Si habilitas firma de solicitud, generas un par de llaves Ed25519 y compartes la llave pública con Migo. Mantén la llave privada en tu secret manager (AWS KMS, Vault, etc.) — nunca en código.
  • Rota llaves al menos una vez al año. Migo coordinará una rotación sin downtime.

Integridad del dispositivo (atestación de app móvil)​

Los clientes móviles pueden atestar la integridad del dispositivo y la app antes de realizar operaciones sensibles. El flujo se expone en el Wallet Gateway bajo /integrity/app y requiere un JWT válido (Bearer auth):

  1. GET /integrity/app — devuelve un hash de validación para la aplicación que llama. La aplicación se identifica por el header HTTP applicationid (p. ej. com.migo.ali).
  2. El cliente genera un token de integridad en el dispositivo usando la Google Play Integrity API.
  3. POST /integrity/app — envía el resultado de la atestación con { hash, applicationId, token }. Migo valida el hash, el application ID y el token de integridad.

Las verificaciones fallidas se manifiestan como errores de integridad (p. ej. versión de app no reconocida, integridad del dispositivo o estado de licencia; token de integridad vencido/inválido; hash o application ID inválido).

Monitoreo y auditoría​

  • Cada solicitud autenticada se correlaciona con una traza interna. Proporciona el timestamp y los detalles de la solicitud al abrir un ticket de soporte para que Migo pueda correlacionarla.
  • Existe un catálogo de eventos audit.* (p. ej. otorgamiento/revocación de permisos, login de usuario CMS) documentado como contrato objetivo pero aún no emitido por la plataforma. No dependas de webhooks de auditoría hasta que Migo confirme su emisión.
  • Patrones inusuales (velocidad, mismatch de BIN, mismatch de país) pueden disparar suspensiones automáticas — consulta Suspensiones del Middleware.

Respuesta ante incidentes​

Si sospechas que una llave, secret o token fue filtrado:

  1. Contacta a soporte@migopayments.com inmediatamente.
  2. Rota la credencial afectada de tu lado.
  3. Migo revocará la llave comprometida y emitirá una nueva.

Certificaciones de cumplimiento​

  • PCI-DSS Level 1 Service Provider
  • Reporte SOC 2 disponible bajo NDA — contacta a tu account manager de Migo

Para especificidades de residencia de datos, GDPR y cumplimiento regional, contacta al área legal de Migo.