Esta traducción se ofrece por comodidad. La versión en inglés es la jurídicamente vinculante.
1. Custodia de claves
Este es el punto importante, así que léelo dos veces. Por defecto, las direcciones de cobro se derivan de material de clave que custodia el Operador, no tú: los pagos llegan a direcciones del Operador y se abonan a tu saldo, y tú retiras desde ahí. La firma no está automatizada: la aplicación web no tiene ninguna vía que difunda una transferencia por sí sola; las retiradas y los pagos los revisa, firma y difunde el Operador fuera de ella. Un comercio que no quiera que el Operador custodie sus fondos en absoluto puede pedir la derivación desde su propio xPub; entonces los pagos llegan a direcciones que solo ese comercio controla, y el Operador no tiene nunca sus claves.
2. Integridad de la API y los webhooks
2.1 Firma
Las peticiones de API y los webhooks se firman con HMAC-SHA256, con una ventana temporal que acota la repetición y claves de idempotencia para que una llamada reintentada no actúe dos veces. Las firmas se comparan en tiempo constante.
2.2 Webhooks salientes
Los webhooks salientes están protegidos frente a SSRF: solo https, enviados a la URL que configuró el comerciante, fijados a una dirección IP validada, con los rangos privados, CGNAT y NAT64 denegados.
3. Credenciales en reposo
Las contraseñas se cifran con bcrypt. El api_secret se cifra en reposo con AES-256-GCM. Las claves privadas, las frases semilla y los números de tarjeta no se almacenan en absoluto.
4. Seguridad de la cuenta
Autenticación en dos pasos TOTP opcional con códigos de recuperación. Las sesiones se registran en el servidor y pueden revocarse. Los tokens CSRF protegen las peticiones que cambian el estado. La limitación de tasa se aplica por IP y por clave.
5. Endurecimiento de transporte y navegador
HSTS, una política de seguridad de contenido, X-Frame-Options con valor DENY, X-Content-Type-Options nosniff y una Referrer-Policy.
6. Integridad del dinero
Las liquidaciones se registran en un libro que solo admite adiciones, con un ancla de idempotencia única, de modo que un mismo depósito no puede abonarse dos veces. Los bloqueos consultivos serializan los cambios de saldo, de modo que las operaciones concurrentes no pueden dejar el saldo en un estado erróneo.
7. Lo que no afirmamos
Payora no posee certificación PCI-DSS, SOC 2 ni ISO 27001, ni licencia de ningún regulador. Quien le diga lo contrario se equivoca. El software ofrece al Operador buenos valores predeterminados; la seguridad de una instancia en funcionamiento depende además del servidor, el alojamiento y las prácticas del Operador.
8. Su parte
Mantenga en privado su secreto de API y su contraseña. Active la autenticación en dos pasos. Verifique las firmas de los webhooks en lugar de fiarse del contenido. Revise con cuidado las direcciones de pago, incluida cualquier etiqueta de destino o memo, porque una transacción enviada no puede recuperarse.
9. Comunicar una vulnerabilidad
Comunique los problemas de seguridad al Operador en support@payora.money. Aporte detalles suficientes para reproducirlo y, por favor, no haga pruebas contra cuentas o datos de otras personas.
Última actualización: 16 de julio de 2026. Si introducimos cambios sustanciales en esta página, la versión actualizada se publicará aquí.
