Seguridad

Paymos es una pasarela custodial: nosotros guardamos las claves que mueven tus fondos en cadena. Eso pone delante de cada comercio una pregunta legítima: ¿qué impide que Paymos se quede con mi dinero y qué ocurre si algo se rompe?

Esta página responde a las dos: primero como una lista breve de compromisos y después en lenguaje llano, con el razonamiento detrás de cada uno. Describe las garantías que te da la plataforma y qué te aporta cada una, no un plano interno. Cuando un detalle forma parte de la API pública (cómo se firma una petición, cómo se verifica un webhook), lo documentamos con precisión, porque lo necesitas para integrarte.

---

Por qué tus fondos están seguros

Destinos controlados y firma aislada

• Infraestructura de firma aislada. Paymos opera la custodia y la ruta de firma fuera de la superficie web pública. Es custodia gestionada, no control directo de las claves por parte del comercio.
• Lista blanca obligatoria. Los fondos solo pueden salir hacia destinos que hayas aprobado de antemano. Ni siquiera el robo total de tus credenciales de API permite inventar una nueva dirección de retiro.
• Bajo control del titular por defecto. La capacidad de retirar y la de editar la lista blanca quedan reservadas al titular de la cuenta salvo que las delegues expresamente, y cada delegación queda registrada.
• Retiras a tu ritmo. Tu saldo es tuyo desde el momento en que un pago alcanza la finalidad. No bloqueamos fondos. Retira cada hora, cada día o nunca: entre la petición y la transacción enviada no hay ventana de lote ni cola de espera, y lo que tarde luego en llegar lo marca la propia cadena.
• Saldos separados. El saldo de cada comercio se lleva por separado. No juntamos los fondos de los comercios en un fondo común ni los prestamos ni los reutilizamos.

Tu dinero no desaparece en silencio

• Abonamos a una profundidad que elegimos por red e importe: suficiente para que una reorganización sea rara, nunca tanta como para descartarla.
• Sin reversiones. Cuando te decimos que un pago está confirmado, no lo deshacemos nunca. Si más tarde una reorganización tumba un pago ya confirmado, la pérdida la asume Paymos, no tú.
• Los retiros no salen dos veces. Cada retiro lleva tu propia clave de idempotencia.
• Controles de congelación por capas que pueden detener automáticamente un activo concreto si la realidad en cadena se separa del libro mayor.
• La liquidez se comprueba por adelantado, de modo que un retiro falla rápido en lugar de quedarse atascado.
• Registros a prueba de manipulación: toda acción privilegiada queda auditada, y los secretos y las firmas se depuran del registro antes de escribirlo.

El resto de la página explica cada punto en términos llanos. Si alguna vez has visto las palabras HMAC o SSRF y te has preguntado qué significan, sigue leyendo.

---

Modelo de amenazas

Diseñamos frente a:

• Fondos en reposo — claves capaces de mover saldos en cadena
• Fondos en movimiento — autorización del retiro y manipulación del destino
• Acceso a la API — robo de credenciales, repetición de peticiones, escalada de alcance
• Entrega de webhooks — contenidos falsificados y uso de nuestra infraestructura como trampolín SSRF hacia la tuya
• Riesgo operativo — acciones destructivas accidentales, condiciones de carrera entre servidores, huecos en la auditoría

Queda expresamente fuera del alcance: la seguridad de la billetera de tu cliente (las claves las tiene él), el riesgo del lado del destinatario una vez firmado un retiro (las transacciones en cadena son definitivas), los servicios de terceros que ejecutes junto a Paymos y la ingeniería social contra tu equipo.

---

Firma de retiros y control de destinos

El problema. Los fondos de una blockchain los controlan las claves de firma. Una credencial robada, un destino cambiado o un servidor de firma comprometido pueden convertirse en una pérdida de dinero si los controles que los rodean no fallan en modo cerrado.

Qué hace Paymos. Las transacciones salientes se firman en infraestructura aislada. Un retiro solo puede ir a una dirección que ya figure en la lista blanca del comercio, y una lista vacía desactiva los retiros por completo. Tocar esa lista es una acción aparte y queda registrada. Si la persona que la toca tiene un segundo factor activado, el cambio exige además una verificación en ese momento. Si no lo tiene, no hay nada que verificar: esa capa empieza el día en que la activas.

El equipo de operaciones puede detener todas las transferencias salientes o congelar un par concreto de activo y red mientras se investiga un incidente. Además, cada retiro lleva una clave de idempotencia, así que repetir la misma petición no crea un segundo envío.

Esto sigue siendo infraestructura custodial: Paymos opera la ruta de firma. El control de destinos, las congelaciones, los registros de auditoría y la conciliación con el libro mayor reducen el riesgo alrededor de la custodia; no la convierten en custodia no custodial ni en custodia por umbral.

Cada factura recibe su propia dirección de depósito única, de forma que la conciliación no admite ambigüedad. Los pagos y retiros de Sandbox no tocan fondos reales, así que puedes probar la integración sin generar transferencias en producción.

---

HMAC — cómo sabe la API que una petición es realmente tuya

HMAC significa Hash-based Message Authentication Code. Nombre temible, idea sencilla.

El problema. Tu servidor nos envía «crea un retiro de 1.000 $». Nos surgen dos preguntas: ¿eres tú de verdad o un impostor? ¿Y se manipuló la petición por el camino, cambiando el importe o la dirección? Si te limitaras a meter una contraseña dentro de la petición, cualquiera que intercepte el tráfico la robaría y enviaría peticiones en tu nombre.

Qué hace HMAC. Tú y nosotros compartimos un secreto (tu API secret). Para cada petición calculas una «huella» (una firma): un hash del contenido de la petición junto con el secreto. Envías la petición y la huella, pero no el secreto. Nosotros recalculamos esa misma huella con nuestra copia del secreto. Si coinciden, eres tú de verdad y nada se ha modificado: cambia un solo carácter y la huella deja de encajar.

Analogía. Un sello de lacre en una carta. El secreto es tu cuño único. Cualquiera puede ver el sello, pero no puede falsificarlo sin el cuño. Y si la carta se abre y se reescribe, el sello ya no cuadra con el contenido.

Lo importante: el secreto en sí nunca viaja por la red. Aunque grabara todo tu tráfico, un atacante no podría extraer el secreto ni fabricar una petición nueva: solo tendría firmas de peticiones que ya enviaste. (SHA-256 es el «molino» concreto que tritura cualquier entrada hasta convertirla en una huella de longitud fija que no se puede revertir.)

El formato exacto (para tu integración)

Toda petición autenticada lleva dos cabeceras:

Authorization: HMAC-SHA256 {api_key_id}:{base64(signature)}
X-Request-Timestamp: {unix_seconds}

La firma es un HMAC-SHA256 sobre una cadena canónica:

{timestamp}\n{METHOD}\n{path}\n{query}\n{sha256_hex_lower(body)}

Un cuerpo vacío aporta una cadena vacía en esa posición: no se hashea; los parámetros de consulta se firman exactamente como aparecen en la URL. Todos los detalles, en la página de Autenticación.

Protección contra repetición

¿Podría un atacante reenviar una petición antigua que hubiera grabado, repitiendo cien veces «crea un retiro»? La marca temporal forma parte de la firma y rechazamos toda petición cuyo X-Request-Timestamp se aleje más de ±5 minutos de la hora del servidor (se rechaza con 401). Una petición grabada vive cinco minutos y luego muere. Combinado con la idempotencia (más abajo), ni siquiera dentro de esa ventana un «crea un retiro» repetido envía fondos dos veces.

Analogía. Una entrada con cinco minutos de margen para pasar: la de ayer no sirve.

Comparación en tiempo constante

Cuando comparamos dos firmas, una comparación ingenua se detiene en el primer carácter erróneo, y el tiempo de respuesta revelaría cuántos caracteres ya son correctos, lo que permitiría adivinarlos byte a byte. Nosotros comparamos en tiempo constante: un «no» tarda exactamente lo mismo por mucho que hayas acertado.

Analogía. Una cerradura de combinación que dice «no» en el mismo tiempo tanto si acertaste un dígito como si acertaste cinco. No hay forma de notar que te estás «acercando».

Tipos de clave y rotación

Dos tipos de clave, cada uno atado a un alcance fijo que el servidor aplica en cada llamada:

• Clave Payment — todo el dinero que entra: crear y leer facturas, y gestionar canales de pago y leer sus depósitos. No puede leer saldos ni crear retiros.
• Clave Payout — crear, leer y cancelar retiros, y leer saldos. No puede crear facturas ni llegar a un canal de pago.

Los secretos rotan sin interrupción: generas un secreto nuevo mientras el anterior sigue siendo válido hasta previous_secret_expires_at, exactamente 24 horas después de la rotación. Ese margen es fijo, no un parámetro que puedas enviar. Mientras sigue abierto se aceptan ambos; después, solo el nuevo.

---

Seguridad de los webhooks — el mismo HMAC, al revés

El HMAC de arriba protege tus peticiones hacia nosotros. Un webhook es nosotros llamando a tu puerta («factura pagada»). Mismo truco, invertido: firmamos cada webhook con el secreto de tu endpoint y tú verificas la firma antes de fiarte. De lo contrario, cualquiera que averigüe la URL de tu webhook podría enviar un evento «pagado» falso y engañarte para que entregues mercancía.

X-Webhook-Signature: t={unix_seconds},v1={hex_hmac}

El contenido firmado es {timestamp}.{request_body}. El esquema coincide con el de Stripe, así que las bibliotecas que verifican webhooks de Stripe funcionan aquí casi sin cambios; durante una rotación de secreto emitimos ambas firmas en la misma cabecera. Mira Verificar firmas.

Protección SSRF

SSRF significa Server-Side Request Forgery. Tú fijas una URL de webhook y nuestros servidores hacen peticiones a ella. Un atacante astuto apunta esa URL no hacia fuera, sino hacia dentro de nuestra red —a una dirección de metadatos de la nube o a un panel interno—, de modo que nuestro servidor la consulta en su nombre y convierte a Paymos en intermediario de cosas que solo nuestra red ve.

Eso lo impedimos: el destino de un webhook se valida para comprobar que resuelve a una dirección pública —se rechazan los rangos de loopback, privados, internos y de metadatos de la nube— y la conexión queda fijada a esa dirección validada, de forma que no hay ventana para un ataque de reenlace de DNS. Las redirecciones se rechazan. Un destino que no supera la validación se descarta de inmediato, así que sondear no consume presupuesto de entrega.

Analogía. Un mensajero que solo reparte en direcciones externas reales, se niega a llevar nada «a la sala de servidores de este mismo edificio», comprueba la dirección antes de salir e ignora una nota que diga «en realidad, entrégalo allí».

Reglas de entrega

Las URL de webhook deben usar HTTPS (se exige al guardar el endpoint). La entrega es al menos una vez: deduplica por ID de evento en tu lado (la convención que usan Stripe, GitHub y PayPal). Las entregas fallidas se reintentan con backoff exponencial a lo largo de 11 intentos repartidos en unas 16 horas —el calendario completo está en Entrega y reintentos— y después se marcan como fallidas y quedan disponibles para reenviar desde el panel. Cada intento tiene su propio tiempo límite.

---

Protección de los retiros — varios cerrojos en fila

Sacar dinero es donde una pasarela custodial se juega su reputación, así que es la parte con más capas:

• Lista blanca (obligatoria). Un retiro va solo a direcciones que aprobaste de antemano. Si la lista blanca de una familia de redes está vacía, no se puede ni crear un retiro: no existe el atajo de «el primer retiro fija la dirección». Incluso con las claves robadas, los fondos solo pueden ir a tus propias billeteras, así que robar claves pierde su recompensa. Analogía: una cuenta que solo puede transferir a una lista de destinatarios registrada previamente; un ladrón con tu contraseña no puede añadir un beneficiario nuevo.
• Solo el titular. Crear retiros y editar la lista blanca corresponde al titular de la cuenta, no a un rol de administrador estándar. Debes concederlo expresamente a alguien que no sea el titular, y esa concesión queda auditada.
• Doble factor (2FA). Un código de seis dígitos de una aplicación de autenticación, que cambia cada 30 segundos; una passkey registrada sirve igual como segundo factor. No viene puesto: lo activas tú, y activarlo es lo que arma la verificación reforzada. Con un segundo factor en la cuenta, cambiar la lista blanca de retiros, editar la lista de IP de una clave de API o desactivar el propio segundo factor piden un código nuevo justo al ejecutarse.
• Controles de congelación (cortacircuitos). Podemos congelar todo a la vez, un token concreto en una red concreta o un comercio concreto. La congelación por activo puede activarse automáticamente si los saldos en cadena se separan del libro mayor más allá de un margen seguro.
• Comprobación previa de liquidez. Un retiro se contrasta con los fondos disponibles (comisiones incluidas) antes de aceptarse, así que falla de inmediato con un error claro en lugar de quedarse atascado.
• Idempotencia. Tu identificador de pedido es la clave de idempotencia: envíalo dos veces y recibirás el mismo retiro, nunca una segunda transferencia. Analogía: el resguardo del guardarropa; entrega el mismo resguardo dos veces y te devolverán el mismo abrigo.
• Creación a prueba de carreras. Las peticiones simultáneas de retiro de una misma cuenta se serializan en el servidor, de modo que dos llamadas en paralelo no pueden colarse por la misma comprobación de saldo.

---

Autorización y aislamiento

• Cada petición se comprueba en el servidor antes de hacer nada: el entorno debe coincidir (Sandbox o producción), el tipo de llamante debe estar permitido, el alcance de la credencial debe cubrir la operación y el recurso debe pertenecer a quien llama. Esas comprobaciones son la frontera real; los controles de la interfaz son solo pistas.
• 404, no 403. Si un recurso no existe, o existe pero no es tuyo, recibes un 404. Así, un atacante no puede distinguir «este ID es real pero no es tuyo» de «este ID no existe». Analogía: un portero que responde «aquí no vive nadie así» tanto si la persona no existe como si vive allí y tú no tienes permiso para subir.
• Tu identidad viene de tu credencial, nunca del cuerpo de la petición. Poner el identificador de otro dentro de una petición no hace nada: no se puede actuar en nombre de otro comercio falsificando un ID.
• Permisos granulares. El acceso se rige por permisos detallados basados en roles (retirar, ver saldo, gestionar webhooks…), cada uno concedible por separado. La comprobación en el servidor es la frontera; el panel solo la refleja.

---

Límite de peticiones

Cada comercio tiene sus propios límites de peticiones. Al superar uno recibes 429 Too Many Requests con una cabecera Retry-After, de modo que una integración que se porte mal solo afecta a su propio caudal, no a la plataforma ni a otros comercios.

---

Finalidad en cadena — por qué tu dinero no se evapora

En una blockchain una transacción «aparece» rápido en un bloque, pero la cadena todavía puede reescribir su historia reciente (una reorganización, o reorg), y algo que parecía confirmado puede desvanecerse. Como la tinta fresca: ya está escrita, pero aún se puede correr.

Finalidad significa esperar a que la transacción quede lo bastante enterrada como para no poder revertirse. La tinta se ha secado. Esperamos la finalidad adecuada de cada red antes de mover tu saldo. En las cadenas donde la finalidad es cuestión de profundidad de confirmación, esa profundidad crece con el importe: los tickets pequeños pasan rápido y los grandes esperan más; las cadenas con finalidad nativa inmediata liquidan en cuanto el bloque es final. Estos umbrales se ajustan a las condiciones de la red, no son fijos.

La promesa principal: si una reorganización tumba más tarde un pago que ya habíamos confirmado (algo muy poco frecuente), la pérdida la asume Paymos, no tú. En cuanto se dispara el webhook de confirmación, puedes actuar de inmediato. Como añadido, no hay contracargos (a diferencia de las tarjetas, que el comprador puede revertir durante meses después de la venta) y los pagos tardíos son imposibles por diseño: un pago confirmado después de que una factura venciera no se abona a esa factura vencida.

---

Protección de datos

En tránsito: todo el tráfico va por TLS 1.2+, HSTS está activo en producción y las peticiones sin cifrar se redirigen a HTTPS.

En reposo: las cookies de sesión son HttpOnly, Secure, SameSite=Strict; los enlaces de acceso son de un solo uso, vencen pronto y están cifrados en reposo.

Antifalsificación: las acciones del panel que cambian estado llevan un token antifalsificación que, junto con las cookies SameSite=Strict, mitiga la falsificación de peticiones entre sitios.

Registro de auditoría: cada acción privilegiada deja constancia de quién la hizo, qué se ejecutó, cuál fue el resultado y cuándo. Los valores sensibles —secretos, contraseñas, tokens, hashes, firmas— se ocultan antes de guardar el registro, y eso se aplica en el momento de escribir.

---

Resiliencia operativa

• Seguridad con varios servidores. Funcionar en varios servidores nunca procesa dos veces un pago, un retiro o un webhook: el trabajo simultáneo sobre el mismo elemento se coordina para ocurrir exactamente una vez. Está verificado con pruebas automatizadas, no dado por supuesto.
• Informes de error respetuosos con la privacidad. Los informes de fallo se depuran de datos personales y del contenido de las peticiones antes de salir de nuestros sistemas.
• Infraestructura que se recupera sola. Las comprobaciones automáticas de salud retiran de la rotación cualquier instancia que no esté sana.
• Cambios de esquema seguros. Las migraciones de base de datos se aplican una vez, en orden y solo hacia delante: nunca ejecutamos reversiones destructivas contra datos de producción.

---

Cumplimiento y tratamiento de datos

Sin KYC para empezar. Puedes registrarte y empezar a probar sin aportar documentos de identidad, domicilio o titularidad real, y Paymos tampoco recoge esos documentos de tus clientes. Paymos no evalúa tu negocio, no revisa licencias, no filtra categorías de comercio ni realiza cribado de sanciones sobre tus clientes; esas obligaciones siguen siendo del comercio. Podemos solicitar KYC o KYB más adelante si la actividad requiere una revisión manual, si se superan los límites de la cuenta o si lo exige una autoridad competente, tal y como se describe en nuestra política AML/KYC.

Datos del lado del cliente. Por diseño, Paymos no recoge ningún dato personal de tus clientes en la página de pago: ni correo, ni teléfono, ni nombre, ni datos de tarjeta. El recorrido es factura → página de pago → paga la billetera → listo. Vemos direcciones de billetera e importes, no identidades, de modo que tu exposición al RGPD o a la CCPA a través de Paymos es prácticamente nula.

Datos del lado del comercio. De tu cuenta guardamos el nombre de la empresa, el correo de contacto, el país y los metadatos de los proyectos (URL de webhook, identificadores de claves de API). Una solicitud de supresión bajo el RGPD activa un borrado lógico de 30 días seguido de una purga definitiva; en el rastro de auditoría solo queda un hash del registro borrado.

Ubicación de los datos. Los datos primarios se almacenan en la UE. Los contratos Enterprise pueden fijar una región concreta: escríbenos.

---

Lo que no hacemos

• No afirmamos cosas que no hemos construido. Esta página describe el sistema tal y como está desplegado. Lo que está en la hoja de ruta no aparece aquí hasta que se publica.
• No custodiamos más tiempo del necesario. Los fondos llegan a tu saldo en cuanto se confirma el pago; cuándo retirar lo decides tú.
• No juntamos los saldos de los comercios. Cada saldo está separado. La insolvencia o la disputa de un comercio no puede tocar los fondos de otro. Meterlo todo en un mismo bote fue exactamente lo que hundió a plataformas como FTX.
• No prometemos seguridad del lado del destinatario. Una vez firmado un retiro, la transacción está en cadena y es definitiva. La lista blanca evita erratas y robos de claves; no puede validar que un destino aprobado por ti se comporte bien.

---

Cómo informar de una vulnerabilidad

Envía tus comunicaciones a [email protected].

• Acuse de recibo: en un plazo de dos días hábiles desde un informe completo
• Alcance: la producción de paymos.io y *.paymos.io, la API REST de producción y los SDK y plugins de CMS publicados por Paymos
• Fuera de alcance: denegación de servicio basada en límites de peticiones, ingeniería social y servicios de terceros (tu CDN, tu proveedor de alojamiento, etc.)
• Bug bounty: por ahora no hay programa público; la comunicación privada de hallazgos relevantes se recompensa caso por caso, con reconocimiento si así lo deseas.

Te pedimos que no pruebes contra cuentas de otros comercios, que no realices pruebas destructivas contra producción y que no publiques nada antes de que hayamos tenido ocasión de corregirlo. Nos comprometemos a acusar recibo de un informe completo en dos días hábiles, a mantenerte al tanto de la corrección, a mencionarte (con tu permiso) cuando se publique y a no emprender acciones legales contra la investigación de buena fe dentro del alcance.