Sécurité

La sécurité d’un paiement se joue des deux côtés : chez Galsen Pay et dans votre intégration. Cette page dit ce que fait Galsen Pay, et ce qui dépend de vous. Elle ne promet pas l’impossible : aucun système n’est infaillible, et un test d’intrusion indépendant reste prévu.

Vos responsabilités

• Clés secrètes côté serveur uniquement, dans la configuration (variables d’environnement, coffre de secrets), jamais dans le code, un dépôt Git, une application mobile ou du JavaScript de navigateur.
• Moindre privilège : une clé par service, avec seulement les permissions utiles ; révocation immédiate en cas de doute.
• Vérifiez chaque webhook (signature HMAC, horodatage, dédoublonnage) avant d’agir : voir Webhooks.
• Ne livrez que sur une preuve : le webhook payment.succeeded ou la relecture du paiement, jamais la seule redirection du client.
• Le montant vient de votre serveur : ne créez jamais un paiement avec un montant envoyé par le navigateur.
• Idempotence sur chaque opération d’argent, et aucune nouvelle création quand un statut vaut UNKNOWN.
• Double authentification pour chaque compte du tableau de bord.

Ce que fait Galsen Pay

• Échanges chiffrés en https uniquement (HSTS).
• Clés API conservées sous forme d’empreinte (HMAC) : Galsen Pay ne peut pas les relire, d’où l’affichage unique à la création.
• Clés de test et de production strictement séparées : chaque déploiement refuse les clés de l’autre.
• Tableau de bord : double authentification TOTP (un code ne sert qu’une fois), verrouillage après plusieurs échecs de connexion, jetons de session courts renouvelés à chaque usage, avec révocation de la session si un ancien jeton est rejoué. Les jetons restent sur le serveur du portail, chiffrés dans un cookie inaccessible au JavaScript.
• Actions sensibles (versements, clés, webhook en production, approbation) soumises à une double authentification récente ; approbation par une autre personne.
• Webhooks des fournisseurs vérifiés sur le corps brut, puis confirmés auprès du fournisseur avant tout crédit.
• Webhooks vers vous signés, envoyés uniquement vers des adresses https publiques (protection contre les requêtes vers des réseaux internes).
• Comptabilité en partie double dont l’intégrité est imposée par la base de données : écritures non modifiables, transactions équilibrées, aucun solde marchand négatif.
• Données personnelles des clients chiffrées ; téléphones masqués dans les réponses.
• Limites de débit, contrôles de risque et plafonds par compte ; journal d’audit des actions sensibles.

Signaler une faille

Si vous découvrez une vulnérabilité, prévenez l’équipe Galsen Pay par votre interlocuteur habituel, sans l’exploiter au-delà de ce qui est nécessaire pour la démontrer et sans accéder aux données d’autrui. Nous accusons réception et vous tenons informé de la correction.