BTCPay Server est un processeur de paiements libre sous licence MIT, exploitable sur sa propre instance ou chez un hébergeur tiers. Le projet fournit un logiciel, pas un compte de garde universel ni un service d’arbitrage des litiges commerciaux. La confiance dépend du raccordement réel du serveur, du portefeuille et des services de paiement.
Le commerçant relie une caisse ou une boutique en ligne à une facture et au mode de réception choisi. BTCPay Server crée des adresses de paiement on-chain et des demandes Lightning, suit les paiements et présente les factures. Il comprend aussi des applications de caisse et de dons ainsi que des interfaces d’intégration. Le code ouvert permet inspection et modification, mais ne prouve pas à lui seul la sécurité d’une installation précise. [BTCPay Server — Source repository]
Un portefeuille on-chain existant peut être connecté par une clé publique étendue : le serveur dérive des adresses de réception sans avoir besoin de sa clé privée. Un portefeuille à chaud créé sur le serveur présente un autre modèle de risque. Des permissions sur un nœud Lightning peuvent aussi permettre de disposer de ses fonds. Séparez les clés de réception, de signature et d’administration ; le mot self-hosted ne détermine pas à lui seul qui peut dépenser l’argent. [BTCPay Server — Wallet setup] [BTCPay Server — General FAQ]
Un tiers exploite le serveur tandis que l’utilisateur peut recevoir directement dans son portefeuille. Cela ne supprime pas la confiance : un serveur malveillant ou compromis peut remplacer la clé publique et détourner les paiements futurs. Les pièces déjà reçues dans votre portefeuille et les nouvelles coordonnées de paiement affichées sont deux sujets distincts. Contrôlez aussi la réception indépendamment de la caisse. La même attaque peut toucher une instance personnelle compromise ; l’hébergeur influence également disponibilité et confidentialité. [BTCPay Server — Third-party hosting risks]
La boutique configure devise, source du taux, expiration et confirmations requises. Processing pour un paiement on-chain attend la condition définie ; Settled indique qu’elle est remplie. Un paiement Lightning réussi n’a pas à attendre un bloc. Traitez aussi paiements insuffisants, excessifs, tardifs et modifications manuelles d’état, qui ne créent aucune confirmation du réseau. Convertir un prix en bitcoin n’est pas vendre contre une monnaie fiat : un plugin ou prestataire de conversion ajoute ses frais et sa propre relation de confiance. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies] [BTCPay Server — General FAQ]
La boutique doit conserver le lien entre commande et identifiant de facture. Greenfield API permet de limiter les permissions à la boutique ; n’accordez pas à la clé plus d’accès que nécessaire. Vérifiez les webhooks selon la documentation et traitez les événements répétés sans seconde expédition. Le retour du client sur une page de remerciement ne prouve pas seul le paiement. Après une interruption, rapprochez les registres locaux des états réels des factures et paiements. [BTCPay Server — eCommerce integration]
Un nœud personnel exige disponibilité, gestion des canaux et liquidité entrante. Un service de liquidité, un swap ou un portefeuille dépositaire résolvent des parties différentes du problème et ne constituent pas le même modèle. Avec un service dépositaire, le prestataire conserve le contrôle des fonds ; pour les autres variantes, vérifiez les permissions et risques précis. Le logo BTCPay Server ne garantit ni le succès de chaque paiement ni l’absence de frais. [BTCPay Server — Lightning options]
Sauvegardez données des boutiques, factures, configuration et données de portefeuille nécessaires selon le déploiement ; une seed ne remplace pas la base des commandes. La documentation Docker exige de vérifier la restauration des sauvegardes. Un ancien état de canal Lightning peut causer une perte de fonds s’il est restauré incorrectement. Une migration planifiée avec arrêt propre du nœud initial diffère d’une reprise après sinistre ; une fois le remplaçant lancé, ne redémarrez pas la copie initiale du même nœud. La procédure doit correspondre au backend utilisé. [BTCPay Server — Backup and restore]
Prévoyez mises à jour, protection de l’accès administrateur, exposition réseau, surveillance de disponibilité et sauvegardes vérifiées. Hébergement, matériel, frais réseau, liquidité et assistance peuvent coûter de l’argent même si le logiciel ne prélève aucun pourcentage sur chaque paiement. Limitez les données client conservées. Le commerçant gère remboursements et litiges de livraison, pas les développeurs du projet ; exporter les factures ne garantit pas le respect de toutes les obligations comptables. [BTCPay Server — Maintenance] [BTCPay Server — General FAQ] [BTCPay Server — eCommerce integration]
Une panne de caisse ne signifie pas perdre les pièces déjà reçues
Dans une boutique fictive, le serveur ne connaît que les données publiques d’un portefeuille externe. Si l’hébergement tombe en panne, les pièces on-chain déjà reçues restent contrôlées par ses clés, mais la caisse peut ne plus créer de factures ou signaler les paiements. L’opérateur restaure le service, vérifie la configuration de réception et rapproche commandes et portefeuille. Cet exemple ne s’applique ni à un portefeuille à chaud sur le serveur perdu ni à un état périmé de canaux Lightning.
Pour une vision complète, lisez aussi Bitcoin Payment Processor, Bitcoin Point of Sale, Auto-garde, Lightning Network, Merchant Adoption, Bitcoin. Cette entrée est également citée par Bitcoin Coffee, Bitcoin Payment Processor, Bitcoin Point of Sale, Bitcoin Donations.
01BTCPay Server implique-t-il automatiquement l’autogarde ?+
Non. Cela dépend du portefeuille connecté, du service Lightning et des permissions réelles. Recevoir dans un portefeuille externe uniquement par une clé publique diffère d’un portefeuille à chaud chez un tiers ou d’un backend dépositaire. Il faut aussi pouvoir se fier aux coordonnées de paiement affichées.
02Une sauvegarde de la seed suffit-elle à la restauration ?+
La seed peut restaurer le portefeuille on-chain correspondant, mais pas automatiquement les factures, les paramètres des boutiques ni les états des canaux Lightning. Ces éléments ont leurs propres sauvegardes et procédures. La restauration doit être testée ; une copie périmée d’un nœud Lightning actif ne peut pas être considérée sans risque comme une simple sauvegarde de fichiers.