Cette traduction est fournie pour votre commodité. La version anglaise est celle qui a force obligatoire.
1. Garde des clés
C'est le point important, alors lisez-le deux fois. Par défaut, les adresses de réception sont dérivées de matériel clé détenu par l'Opérateur, et non par vous : les paiements arrivent sur les adresses de l'Opérateur et sont crédités sur votre solde, et vous retirez de là. La signature n'est pas automatisée — l'application web n'a pas de chemin qui diffuse un transfert par elle-même ; les retraits et les paiements sont examinés, signés et diffusés par l'Opérateur en dehors de cela. Un commerçant qui ne veut pas que l'Opérateur détienne ses fonds peut demander une dérivation de son propre xPub ; alors les paiements se règlent uniquement sur des adresses que ce commerçant contrôle, et l'Opérateur n'a jamais les clés de celles-ci.
2. Intégrité de l'API et des webhooks
2.1 Signature
Les requêtes API et les webhooks sont signés avec HMAC-SHA256, avec une fenêtre de timestamp pour limiter la répétition, et des clés d'idempotence afin qu'un appel réessayé n'agisse pas deux fois. Les signatures sont comparées en temps constant.
2.2 Webhooks sortants
Les webhooks sortants sont protégés contre les SSRF : uniquement https, envoyés à l'URL configurée par le commerçant, liés à une adresse IP validée, avec des plages privées, CGNAT et NAT64 refusées.
3. Identifiants au repos
Les mots de passe sont hachés avec bcrypt. Le api_secret est chiffré au repos avec AES-256-GCM. Les clés privées, les phrases de récupération et les numéros de carte ne sont jamais stockés.
4. Sécurité du compte
Authentification à deux facteurs TOTP optionnelle avec des codes de récupération. Les sessions sont suivies côté serveur et peuvent être révoquées. Les tokens CSRF protègent les requêtes modifiant l'état. La limitation de débit s'applique par IP et par clé.
5. Renforcement du transport et du navigateur
HSTS, une politique de sécurité du contenu, X-Frame-Options définie sur DENY, X-Content-Type-Options nosniff, et une politique de référence.
6. Intégrité de l'argent
Les règlements sont enregistrés dans un registre en ajout uniquement avec un ancrage d'idempotence UNIQUE, de sorte que le même dépôt ne peut pas être crédité deux fois. Les verrous consultatifs sérialisent les changements de solde, de sorte que les opérations concurrentes ne peuvent pas faire courir un solde dans un état incorrect.
7. Ce que nous ne revendiquons pas
Payora ne détient aucune certification PCI-DSS, SOC 2 ou ISO 27001, ni de licence réglementaire. Quiconque vous dit le contraire a tort. Le logiciel offre des paramètres par défaut solides à l'Opérateur ; la sécurité d'une instance en cours d'exécution dépend également du serveur, de l'hébergement et des pratiques de l'Opérateur.
8. Votre côté de cela
Gardez votre secret API et votre mot de passe privés. Activez l'authentification à deux facteurs. Vérifiez les signatures des webhooks plutôt que de faire confiance à la charge utile. Vérifiez soigneusement les adresses de paiement, y compris tout tag de destination ou mémo, car une transaction envoyée ne peut pas être rappelée.
9. Signalement d'une vulnérabilité
Signalez les problèmes de sécurité à l'Opérateur à support@payora.money. Veuillez donner suffisamment de détails pour reproduire, et veuillez ne pas tester sur les comptes ou les données d'autres personnes.
Dernière mise à jour : 16 juillet 2026. Si nous apportons des modifications importantes à cette page, la version mise à jour sera publiée ici.
