Chaque processeur de carte et chaque passerelle crypto hébergée se place entre vous et votre client, prélève un pourcentage, conserve la liste de qui vous a payé quoi, et se réserve le droit d'arrêter. BTCPay Server est le logiciel qui les supprime : un processeur de paiement open source, auto-hébergé et non-custodial, où les pièces vont directement dans un portefeuille dont le serveur ne peut pas dépenser le contenu. Six étapes vers une caisse Bitcoin et Lightning fonctionnelle sur une machine louée anonymement — la forme du nœud qui détermine le budget, la clé en lecture seule, le problème de la liquidité entrante, et la règle de sauvegarde que Lightning enfreint. La machine coûte $7.90 par mois. Testé sur Debian 12.
Choisir
Complet, élagué ou nœud externe
Provisionner
Le domaine d'abord, puis quatre ports
Déployer
Un générateur, une commande
Connecter
Clé en lecture seule, jamais une seed
Lightning
Canaux et capacité entrante
Livrer
Caisse, sauvegardes, mises à jour
Un paiement sur une blockchain n'a pas besoin d'une entreprise au milieu. Le client signe une transaction, le réseau la confirme, et l'argent est à vous — il n'y a ni acquéreur, ni délai de règlement, ni personne dont l'accord conditionne le paiement. C'est tout l'intérêt de la chose, et c'est la raison pour laquelle cette technologie existe.
Ensuite, une boutique a besoin de réellement prendre des paiements, et les exigences pratiques arrivent toutes en même temps. Chaque facture a besoin de sa propre adresse, pour que les paiements puissent être distingués les uns des autres. Quelqu'un doit surveiller la chaîne et décider quand une facture est payée. Le montant doit être indiqué dans une devise dans laquelle le client pense, à un taux qui tient assez longtemps pour qu'il appuie sur envoyer. Le statut de la commande doit remonter jusqu'à la boutique. Et tout cela doit fonctionner à deux heures du matin sans que personne ne surveille. Construire tout cela est un projet ; ne pas le construire est la raison pour laquelle presque tout le monde s'inscrit plutôt chez une passerelle hébergée — et, en l'espace d'un formulaire, remet un intermédiaire dans un système qui était conçu pour ne pas en avoir.
Ce que détient cet intermédiaire mérite d'être dit clairement, parce que c'est plus que les frais. Il détient les pièces, au moins jusqu'à ce qu'un versement s'exécute, ce qui signifie qu'il peut en retarder un. Il détient la liste : chaque client, chaque montant, chaque horodatage, chaque produit, dans une base de données que vous ne pouvez ni lire ni supprimer. Il détient un dossier d'identité sur vous, parce qu'une entreprise qui touche l'argent d'autrui est tenue d'en collecter un. Et il détient l'interrupteur, parce que les conditions d'utilisation se réservent le droit de décider que votre activité n'est plus la bienvenue — une décision qui arrive par e-mail, s'applique au solde autant qu'au compte, et n'est pas, en pratique, susceptible de recours.
BTCPay Server est la réponse à exactement ce problème, et à rien d'autre. C'est un processeur de paiement gratuit et open source que vous faites tourner sur votre propre machine : il dérive une adresse par facture, surveille la chaîne, affiche des prix en monnaie fiduciaire, expose une caisse et une API, et parle Lightning. Il ne détient jamais vos pièces, car le portefeuille qu'il surveille est un portefeuille que vous possédez déjà. Quatre façons d'accepter un paiement en crypto, et ce que chacune coûte réellement :
| Propriété | Une passerelle crypto hébergée | Une adresse brute dans le pied de page | BTCPay sur l'instance de quelqu'un d'autre | BTCPay sur votre propre VPS |
|---|---|---|---|---|
| Qui détient les pièces | La passerelle, jusqu'au versement | Vous | Vous — elle surveille, elle ne peut pas dépenser | Vous — elle surveille, elle ne peut pas dépenser |
| Qui peut vous empêcher de vendre | La passerelle, par e-mail | Personne | L'opérateur de l'instance | Personne |
| Qui voit chaque client et chaque montant | La passerelle, en permanence | Tout le monde — une adresse, un total public | L'opérateur de l'instance | Vous |
| Pièce d'identité requise | Oui, avant le premier versement | Non | Tout ce que l'opérateur demande | Non |
| Coût par transaction | Un pourcentage, pour toujours | Rien | Rien | Rien — $7.90 par mois, fixe |
| Distingue une facture d'une autre | Oui | Non — vous réconciliez à la main | Oui | Oui |
| À choisir quand | Vous voulez zéro opération et acceptez les conditions | Dons, une poignée par an | Vous voulez le logiciel, mais pas le serveur | Les recettes sont à vous, et la liste aussi |
La seconde colonne n'est pas une blague non plus — une adresse unique dans un pied de page convient très bien à un lien de don, et prétendre le contraire ne sert qu'à vendre un logiciel dont personne n'a besoin. Cela cesse de convenir dès l'instant où deux personnes paient le même montant le même jour, ou dès l'instant où vous préféreriez que votre revenu annuel ne soit pas un chiffre public que n'importe qui peut additionner.
Un processeur de paiement doit pouvoir répondre honnêtement à une seule question : cette facture a-t-elle été payée ? Y répondre signifie surveiller le réseau Bitcoin, et bien le surveiller signifie faire tourner un nœud qui valide lui-même les blocs plutôt que de croire ce qu'on lui raconte. Ce nœud est tout le budget matériel de ce projet — BTCPay lui-même, l'indexeur et la base de données réunis sont une erreur d'arrondi à côté.
Il existe trois arrangements qui ont du sens, et un seul qui n'en a pas. Un nœud d'archive conserve chaque bloc jamais miné : confortablement au-delà de 700 GB en 2026, et croissant d'environ 50 GB par an. C'est ce qu'il vous faut si vous comptez aussi faire tourner un explorateur de blocs ou une analyse historique, et c'est excessif pour une boutique. Un nœud élagué télécharge et valide intégralement chaque bloc exactement de la même façon, puis jette les anciens et conserve une fenêtre glissante. Le modèle de sécurité est identique — c'est le point que les gens comprennent de travers, parce que « élagué » sonne comme « partiel », et ce n'est pas le cas — et le générateur de déploiement fournit des fragments prêts à l'emploi pour cela.
Un nœud externe est la troisième : pointez la pile vers un nœud Bitcoin que vous exploitez déjà, via une liaison privée. Si vous avez déjà suivi le guide du nœud Lightning, il n'y a aucune raison de garder une seconde copie de la chaîne, et un VPN maillé entre les deux machines est le moyen propre de les relier. L'arrangement qui n'a pas de sens est de pointer une boutique vers le nœud public d'un inconnu : il apprend chaque adresse que vous surveillez, ce qui est votre chiffre d'affaires, et il est en position de mentir sur le fait qu'une facture a été payée.
| Déploiement | Chaîne sur disque | Volume total nécessaire | Ce à quoi vous renoncez |
|---|---|---|---|
| Élagué, fenêtre la plus petite | ~5–25 GB | ~40 GB | Les rescans, et toute marge d'erreur. Le réglage le plus petit n'est pas recommandé. |
| Élagué, fenêtre d'environ 50 GB | ~50 GB | ~80 GB | Rien qu'une boutique remarque. Le plancher raisonnable. |
| Élagué, fenêtre d'environ 100 GB | ~100 GB | ~140 GB | Rien. Le choix par défaut confortable, avec de la place pour Lightning. |
| D'archive, historique complet | 700 GB + | ~960 GB | Rien — mais vous le payez chaque mois, pour toujours. |
| Nœud externe que vous exploitez déjà | Aucun sur cette machine | ~40 GB | Indépendance — la caisse est hors service quand l'autre machine l'est. |
Un nœud élagué ne peut pas rescanner les blocs qu'il a jetés. En pratique, cela signifie qu'il ne peut pas reconstituer l'historique d'un portefeuille dont les transactions précèdent le déploiement — l'indexeur analyse en avançant à partir du jour où vous connectez la clé, si bien que les anciens paiements vers ce compte n'apparaîtront tout simplement pas dans la boutique. Ce n'est pas un problème si vous faites ce que recommande l'étape 04 et donnez à la boutique un compte fraîchement créé ; c'est une après-midi franchement déroutante si vous connectez un portefeuille que vous utilisez depuis trois ans et que la moitié de son historique manque. Décidez lequel des deux vous faites avant d'installer, pas après.
Une décision de plus a sa place ici plutôt que plus tard, parce qu'elle change ce que l'installeur construit : voulez-vous Lightning dès le premier jour ? On-chain uniquement est une configuration complète, et un point de départ parfaitement respectable. Ajouter Lightning plus tard est pris en charge et n'a rien de douloureux, mais c'est un second démon avec ses propres fonds et ses propres règles de sauvegarde, et il y a beaucoup à dire en faveur du fait de prouver que l'argent réel arrive par le chemin simple avant d'introduire le compliqué.
Commandez la machine. Dans le panneau : Commander → VPS → Garrison, image Debian 12, dans le bastion où vous voulez que vivent les données de la boutique — Helsinki, Stockholm, Oslo ou Reykjavík. Garrison est le bon choix par défaut, car il tient un nœud élagué de 100 GB, un nœud Lightning et la base de données sans que vous ayez à repenser au disque avant des années. Sentinel fonctionne avec un élagage plus serré ; Bulwark est le niveau pour un nœud d'archive. Aucune adresse e-mail n'est requise pour ouvrir le compte, et la facture se règle en Monero, Bitcoin, Lightning ou tout autre actif pris en charge — ce qui est la partie plaisante de ce projet en particulier, puisque vous construisez une machine pour prendre des paiements en crypto et que vous la payez avec une crypto.
Exécutez ensuite la checklist de durcissement de la première heure avant toute autre chose — SSH par clé uniquement sur un port déplacé, mises à jour automatiques, pare-feu qui refuse tout par défaut. Cette machine finira par détenir l'enregistrement de tous les clients que vous avez, et le matériel de clé d'un nœud Lightning avec des fonds actifs dedans. Ce n'est pas une machine à laisser avec une authentification par mot de passe pendant une semaine.
Passons maintenant à l'enregistrement DNS, et faites-le avant d'exécuter l'installeur plutôt qu'après. Choisissez le nom d'hôte sur lequel la caisse vivra — shop.example.com, pay.example.com, ce qui convient — et pointez un enregistrement A vers l'adresse du VPS, plus un AAAA si vous voulez qu'elle soit joignable en IPv6. Laissez-le se propager. Le reverse proxy que l'installeur met en place tentera d'obtenir un certificat pour ce nom exact pendant son premier démarrage, en utilisant un défi HTTP qui exige que le nom résolve déjà vers cette machine. Un enregistrement A qui n'est pas encore actif est de loin la façon la plus courante dont une première installation se termine par une erreur déroutante.
Le déploiement fournit un script pour changer le domaine plus tard, donc c'est rattrapable plutôt que fatal. Ce qui n'est pas rattrapable en une seule commande, c'est tout ce qui suit en aval : le certificat est réémis, chaque bouton de paiement et chaque URL de webhook que vous avez distribués pointent vers l'ancien nom, une adresse Lightning est un nom sur un domaine et se déplace avec lui, et n'importe quel plugin de boutique doit être reconfiguré. Choisissez un nom que vous êtes prêt à garder sur l'en-tête pendant des années, et préférez un sous-domaine d'un domaine que vous publiez déjà plutôt qu'un nouveau qui décrit ce que fait la machine.
Rédigez ensuite les règles de pare-feu pendant que rien n'écoute encore. Quatre ports, et seulement quatre. La caisse est par nécessité un point de terminaison HTTPS public — le navigateur d'un client doit pouvoir l'atteindre — et le port 80 reste ouvert parce que le renouvellement du certificat s'en sert. Le port pair-à-pair de Lightning n'est nécessaire que si vous voulez que d'autres nœuds puissent ouvrir des canaux vers vous, ce que l'étape 05 vous conseillera de vouloir. Le port pair-à-pair de Bitcoin n'a besoin d'être ouvert en aucun cas : votre nœud établit très bien des connexions sortantes, et l'ouvrir en entrant ne fait que le rendre plus facile à trouver.
ufw default deny incoming
ufw allow 47222/tcp # administrative SSH, moved off 22
ufw allow 80/tcp # ACME HTTP-01 challenge and the redirect
ufw allow 443/tcp # the checkout
ufw allow 9735/tcp # Lightning peer-to-peer, only if you want inbound channels
ufw enable
ufw status numbered
Deux notes sur les ressources avant de continuer. Donnez du swap à la machine si elle n'en a pas — le téléchargement initial des blocs est l'heure la plus gourmande en mémoire de ce projet, et 4 GB de RAM avec 2 GB de swap se comportent bien mieux que 4 GB seuls. Et vérifiez le calcul de disque de l'étape 01 par rapport au niveau que vous avez réellement commandé, parce qu'un nœud qui remplit son volume en pleine synchronisation n'échoue pas poliment ; il corrompt son propre index et recommence depuis le début.
fallocate -l 2G /swapfile && chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab
df -h / # confirm the volume matches step 01
Le déploiement officiel n'est pas un docker-compose.yml que vous éditez. C'est un générateur : vous décrivez le déploiement que vous voulez dans des variables d'environnement, et un script assemble le fichier compose à partir d'une bibliothèque de fragments — un pour Bitcoin Core, un pour l'indexeur, un pour PostgreSQL, un pour l'application BTCPay, un pour chaque implémentation Lightning, un pour le reverse proxy, et une longue traîne d'extras optionnels. C'est une meilleure conception qu'il n'y paraît au premier abord, parce que les mises à jour régénèrent le fichier plutôt que de vous demander de fusionner les changements de quelqu'un d'autre dans les vôtres. Cela signifie aussi que le bloc d'environnement ci-dessous est la véritable configuration de votre déploiement, et qu'il mérite d'être conservé au même endroit que vos autres notes d'infrastructure.
Clonez le dépôt et exportez l'environnement. Chaque ligne ci-dessous correspond directement à une décision de l'étape 01 : le nom d'hôte est le domaine pointé à l'étape 02, le fragment de stockage est la fenêtre d'élagage choisie, et la variable Lightning est soit une implémentation, soit entièrement omise pour un lancement on-chain uniquement.
mkdir BTCPayServer && cd BTCPayServer
git clone https://github.com/btcpayserver/btcpayserver-docker
cd btcpayserver-docker
export BTCPAY_HOST="pay.example.com" # exactly the name you pointed in step 02
export NBITCOIN_NETWORK="mainnet"
export BTCPAYGEN_CRYPTO1="btc"
export BTCPAYGEN_REVERSEPROXY="nginx"
export BTCPAYGEN_LIGHTNING="clightning" # or "lnd", or omit for on-chain only
export BTCPAYGEN_ADDITIONAL_FRAGMENTS="opt-save-storage-s" # ~50 GB pruned window
export BTCPAY_ENABLE_SSH=true
export LETSENCRYPT_EMAIL="you@example.com"
. ./btcpay-setup.sh -i
Deux détails dans ce bloc méritent chacun une phrase. Le point de tête dans . ./btcpay-setup.sh -i n'est pas une faute de frappe — le script est sourcé plutôt qu'exécuté, si bien que l'environnement qu'il définit reste dans votre shell, et que les commandes d'aide fonctionnent ensuite. Et le nom du fragment de stockage est sensible à la version : le générateur a fourni des variantes élaguant à environ 100, 50, 25 et 5 GB, sous des noms qui ont été ajustés d'une version à l'autre. Lisez la liste des fragments dans le dépôt que vous venez de cloner plutôt que de faire confiance à une valeur copiée d'un article de blog, celui-ci y compris.
L'installeur prendra quelques minutes, tirera beaucoup d'images, obtiendra le certificat et démarrera tout. Puis l'attente commence : le nœud doit télécharger et valider la chaîne avant que la boutique puisse confirmer un paiement, ce qui prend des heures plutôt que des minutes même en élagué, parce que l'élagage jette les blocs après les avoir validés plutôt que de sauter le travail. L'interface web est disponible immédiatement et vous montrera une bannière de synchronisation. N'émettez pas de vraie facture tant qu'elle n'a pas disparu.
./bitcoin-cli.sh getblockchaininfo | grep -E 'blocks|headers|verificationprogress|pruned'
docker ps --format '{{.Names}}\t{{.Status}}'
Une instance toute neuve n'a aucun utilisateur, et le premier compte à s'inscrire devient administrateur. Tant que vous ne l'avez pas pris, quiconque atteint l'URL le peut — et l'URL n'est pas secrète : dès que le certificat a été émis, le nom d'hôte a été publié dans les journaux publics de transparence des certificats, indexés et analysés en continu par des gens qui cherchent exactement cela. Ouvrez le site et inscrivez-vous avant toute autre chose, puis consultez les Paramètres du serveur et confirmez que l'inscription n'est pas ouverte aux inconnus. C'est une fenêtre de cinq minutes que les gens laissent ouverte pendant des jours parce que la boutique n'est « pas encore en ligne ».
Deux fragments optionnels valent la peine d'être connus pendant que vous êtes encore dans la configuration. L'un ajoute un service caché Tor, si bien que la caisse est joignable à une adresse onion v3 en plus de l'adresse clearnet — utile pour les clients qui préféreraient ne pas résoudre votre domaine, et c'est la même idée que le guide du service caché. L'autre ajoute une seconde cryptomonnaie. Les deux se règlent de la même façon, en ajoutant à la variable des fragments additionnels et en relançant le script d'installation ; le générateur reconstruit le fichier compose et ne redémarre que ce qui a changé.
Créez une boutique, puis prenez l'unique décision de cette page qui compte vraiment. BTCPay proposera deux façons de rattacher un portefeuille Bitcoin : en connecter un déjà existant, ou le laisser en générer un nouveau et garder la seed sur le serveur. La première option est en lecture seule, et c'est celle qu'il vous faut. La seconde transforme une machine publique, exposée à internet, en portefeuille chaud détenant votre chiffre d'affaires, et aucun degré de durcissement ne fait de cela un bon compromis pour une machine dont le travail entier est d'être joignable par des inconnus.
Le mécanisme derrière cette recommandation est assez élégant pour mériter d'être compris. Les portefeuilles modernes sont hiérarchiques : une seule seed dérive un arbre de clés, et il existe une clé publique étendue — un xpub, ou sa variante zpub pour le segwit natif — à partir de laquelle chaque adresse de réception d'un compte peut être calculée sans aucune capacité à signer. Donnez-la à la boutique, et elle peut générer une adresse neuve pour chaque facture, surveiller la chaîne pour les paiements vers chacune d'elles, et vous montrer le solde. Elle ne peut pas déplacer un seul satoshi. La moitié privée reste dans votre portefeuille, ou sur votre dispositif matériel, et ne voyage jamais.
Donc : ouvrez Sparrow, Electrum, ou l'application de bureau de votre portefeuille matériel, créez un nouveau compte dédié à cette boutique, et exportez sa clé publique étendue. Dans les paramètres de portefeuille de la boutique, choisissez de connecter un portefeuille existant, collez la clé, et vérifiez les premières adresses que BTCPay dérive par rapport à celles que montre votre portefeuille. Si elles correspondent, le chemin de dérivation est le bon, et la connexion est terminée. Si elles ne correspondent pas, vous avez choisi le mauvais type de script — la différence entre un xpub et un zpub est la différence entre deux ensembles d'adresses entièrement séparés.
Elle ne peut pas dépenser, ce qui est tout l'intérêt — mais elle peut énumérer. Quiconque l'obtient peut dériver chaque adresse que le compte utilisera un jour, et donc lire chaque paiement qu'il a jamais reçu et recevra jamais, aussi longtemps que vous l'utilisez. C'est une divulgation permanente et irrévocable des recettes de votre boutique, et c'est pourquoi le compte que vous connectez devrait être dédié à la boutique plutôt qu'être celui qui détient votre épargne. Traitez la clé comme confidentielle, tenez-la à l'écart des captures d'écran et des tickets de support, et si elle fuite malgré tout, déplacez la boutique vers un nouveau compte plutôt que d'espérer.
Passons maintenant aux paramètres de facturation, là où une boutique se règle vraiment. L'expiration vaut par défaut environ quinze minutes, et c'est un blocage de taux plutôt qu'une limite technique : c'est la durée pendant laquelle vous acceptez de maintenir un prix libellé en monnaie fiduciaire face à un actif volatil. Raccourcissez-la pour un marché volatil, allongez-la si vos clients sont lents. Les confirmations décident du moment où une facture compte comme réglée — zéro confirmation est instantané et convient pour un café, une confirmation est le défaut ordinaire, et six sont réservées aux montants pour lesquels une heure d'attente coûte moins cher que l'alternative. La tolérance de sous-paiement vous permet d'accepter une facture qui arrive légèrement en dessous du montant, ce qui arrive constamment quand le portefeuille d'un client déduit ses frais du montant plutôt que de les ajouter ; un petit pourcentage ici élimine toute une catégorie d'e-mails de support.
Testez-la ensuite avec de l'argent réel, pas avec le testnet. Émettez une demande de paiement pour un montant dérisoire, payez-la depuis un portefeuille sur téléphone, et observez la facture passer de nouvelle à en traitement puis à réglée. Cette seule transaction prouve que le nœud est synchronisé, que le chemin de dérivation est le bon, que le fournisseur de taux fonctionne, que le certificat est valide sur un navigateur mobile, et que l'argent a atterri dans un portefeuille que vous contrôlez. Rien d'autre ne prouve les cinq à la fois.
Le Bitcoin on-chain règle magnifiquement une facture de $400, et mal une facture de $4 : le client attend une confirmation et paie des frais qui peuvent représenter une fraction notable de l'achat. Lightning inverse les deux — règlement en environ deux secondes, frais mesurés en fractions de centime — ce qui explique pourquoi une boutique qui vend des petites choses en a besoin, et pourquoi une boutique qui vend des grosses choses peut s'en passer. Si vous avez défini une implémentation Lightning à l'étape 03, le démon tourne déjà et BTCPay s'y est déjà connecté ; les paramètres de la boutique n'ont plus qu'à activer Lightning comme moyen de paiement.
L'implémentation que vous avez choisie a des conséquences qui méritent d'être nommées. Core Lightning est l'option conservatrice et légère, avec une architecture de plugins propre. LND est la plus largement déployée, et possède le plus grand écosystème d'outils de gestion autour d'elle. Il existe aussi désormais un troisième type d'option — un démon léger qui externalise la gestion des canaux vers un prestataire de service tout en gardant les clés sur votre machine — qui échange une part d'indépendance contre la disparition de tout ce qui est décrit dans les trois paragraphes suivants. C'est un choix légitime pour une boutique qui veut Lightning sans vouloir devenir opérateur de nœud ; c'est simplement un compromis différent, pas un compromis gratuit.
Un canal Lightning détient un montant fixe d'argent, réparti entre les deux extrémités. Quand vous ouvrez un canal et le financez, la totalité de cet argent est de votre côté — ce qui constitue une capacité à envoyer, et une capacité exactement nulle à recevoir. Une boutique a besoin de l'inverse. Un nœud tout juste financé, avec trois canaux en bonne santé, peut donc échouer sur absolument chaque facture entrante, et l'échec ressemble à une erreur de routage plutôt qu'à une erreur de configuration. C'est la raison la plus courante pour laquelle une caisse Lightning auto-hébergée semble cassée dès le premier jour.
Il existe trois façons honnêtes d'obtenir de la capacité entrante, et elles ne s'excluent pas mutuellement. Vous pouvez ouvrir des canaux sortants puis dépenser à travers eux — acheter quelque chose, payer une facture, transférer de l'argent vers une plateforme d'échange — ce qui pousse votre solde vers l'autre côté et convertit de la capacité d'envoi en capacité de réception. Vous pouvez demander à un nœud bien connecté d'ouvrir un canal vers vous, ce qui est une requête normale dans la communauté Lightning, et gratuite à part les frais on-chain du pair. Ou vous pouvez acheter de la liquidité entrante auprès de l'un des nombreux services qui en vendent, ce qui coûte un petit pourcentage et prend des minutes plutôt que des semaines. Il n'y a aucune recommandation d'affiliation sur cette page, et il n'y en aura jamais ; choisissez sur la base de la réputation et du prix actuel.
Une fois que vous pouvez être payé, deux fonctionnalités transforment le nœud en vitrine de boutique. Une adresse Lightning — de la même forme qu'une adresse e-mail, sur votre propre domaine — permet à n'importe qui de vous envoyer de l'argent depuis n'importe quel portefeuille moderne sans qu'une facture existe au préalable, ce qui est le mécanisme de don et de pourboire le plus convivial qui soit. Et le QR code sur la page de la caisse peut proposer les deux rails à la fois, si bien qu'un client avec un portefeuille Lightning paie en quelques secondes, et qu'un client sans en avoir un paie en on-chain, depuis le même écran et sans qu'aucune décision ne vous soit demandée.
Avant que le premier paiement Lightning n'arrive, faites l'étape de sauvegarde qui doit avoir lieu maintenant plutôt que plus tard. Chaque implémentation conserve un petit fichier décrivant l'état actuel de vos canaux — LND l'appelle une sauvegarde statique de canal — et c'est l'artefact qui vous permet de récupérer les fonds si la machine est perdue. Il change à chaque ouverture ou fermeture de canal, donc copiez-le hors de la machine automatiquement plutôt qu'à la main. Lisez l'avertissement de l'étape 06 avant de supposer que votre archive nocturne couvre déjà cela, parce que pour Lightning spécifiquement, ce n'est pas le cas.
Choisissez la plus petite surface de caisse qui corresponde à ce que vous avez déjà. Une demande de paiement est un lien que vous envoyez à quelqu'un — aucun site web requis, et la façon la plus rapide de facturer un client. Une application de point de vente transforme la même instance en caisse avec une liste de produits, ce qui fonctionne depuis un téléphone sur un étal de marché. Un bouton de paiement est un extrait de HTML pour un site statique. Un plugin de boutique ajoute Bitcoin comme moyen de paiement à une vraie vitrine, et reporte automatiquement le statut de la commande. Et l'API REST émet des factures, rapporte leur état et appelle un webhook quand l'une d'elles se règle, ce qui est l'intégration qui vieillit le mieux, car elle ne dépend de rien d'autre que de HTTP et d'un secret partagé.
Quel que soit votre choix, configurez le webhook, puis testez qu'il se déclenche. Une facture qui se règle et ne notifie jamais votre application est le mode de défaillance que personne ne détecte, parce que tout semble correct des deux côtés pris isolément : l'argent est arrivé, le client a vu une page de confirmation, et la commande reste non honorée. Envoyez-vous délibérément un webhook de facture réglée, confirmez que votre point de terminaison l'a reçu, et vérifiez la signature plutôt que de faire confiance à la charge utile — ce point de terminaison est public, et n'importe qui peut y poster.
C'est le seul avertissement de cette page qui peut vous coûter de l'argent plutôt que du temps, et la documentation du projet elle-même le dit dans les mêmes mots : un vieil état de canal Lightning est toxique. Restaurer la copie de la nuit dernière d'une base de données de canaux et laisser le nœud tourner revient à diffuser un état que votre contrepartie a déjà remplacé — ce que le protocole traite comme une tentative de triche, et punit en lui attribuant la totalité du solde du canal. L'archive convient donc à la base de données de la boutique, à la configuration et à l'historique des factures, mais ce n'est pas un plan de récupération pour les canaux. Copiez la sauvegarde statique de canal hors de la machine en continu, gardez la plus récente, et si jamais vous restaurez un serveur entier à partir d'une archive, faites-le en sachant que le côté Lightning a besoin de la procédure de récupération documentée plutôt que d'une restauration directe.
Cela étant compris, la routine est courte. Le déploiement fournit un script de sauvegarde qui archive les volumes et exporte la base de données tout en sautant les données de la blockchain, et il accepte une phrase de passe pour que l'archive soit chiffrée avant de quitter la machine. Exécutez-le sur une minuterie, puis poussez le résultat vers une machine dans une juridiction différente, de la façon que décrit le guide des sauvegardes — un dépôt append-only vaut les dix minutes supplémentaires ici, parce qu'un serveur de paiement compromis ne devrait pas pouvoir effacer l'enregistrement de ce qu'il a traité.
cd ~/BTCPayServer/btcpayserver-docker
export BTCPAY_BACKUP_PASSPHRASE="a long passphrase you keep elsewhere"
./btcpay-backup.sh # archives volumes + database, skips the chain
# then ship the archive offsite, and keep the channel backup separately
Les mises à jour viennent ensuite, et une machine de paiement est la seule machine où « la mettre à jour plus tard, délibérément » est la bonne politique. Le déploiement a son propre script de mise à jour qui régénère le fichier compose et tire les nouvelles images ; exécutez-le quand vous avez lu les notes de version, pas quand une tâche cron en décide ainsi. Prenez d'abord l'archive. Montez d'une version à la fois. Et gardez la version précédente notée quelque part, parce qu'un retour en arrière que vous pouvez faire en une minute est ce qui rend le tout peu risqué.
./btcpay-update.sh # deliberate, after reading the release notes
df -h / # the check that should be an alert, not a habit
Enfin, réglez une alerte et un rappel. L'alerte porte sur l'utilisation du disque — un nœud blockchain est le seul processus de la machine qui grossit tout seul, et un volume plein met la caisse hors service d'une manière lente à diagnostiquer, parce que rien d'autre n'a changé. Déclenchez-la à quatre-vingts pour cent, pas quatre-vingt-quinze. Le rappel est mensuel, et il consiste à ouvrir la boutique et à regarder deux choses : que les factures se règlent toujours, et que les canaux Lightning que vous avez ouverts sont toujours vivants. Un processeur de paiement échoue en silence, et la façon dont vous vous en rendez compte, c'est un client qui vous dit qu'il n'a pas pu payer.
Auto-héberger le processeur est une amélioration réelle et précise, et ce n'est pas un tour de passe-passe. Cinq choses restent vraies une fois tout ce qui précède accompli, et les connaître fait la différence entre une véritable défense et une histoire rassurante.
Le registre Bitcoin est public et permanent. Supprimer la passerelle a supprimé la base de données privée d'une entreprise ; cela n'a pas chiffré la chaîne. Chaque paiement que reçoit votre boutique est visible par quiconque connaît une adresse, pour toujours, et les adresses se regroupent en grappes : un portefeuille qui combine deux paiements en une seule dépense vient de dire au monde entier que ces deux clients ont payé la même boutique. C'est une propriété de l'actif, pas du logiciel, et c'est la raison pour laquelle une entreprise ayant un réel besoin de confidentialité regarde aussi du côté de Monero.
Le nom d'hôte de la caisse est publié dès l'instant où il existe. Les journaux de transparence des certificats sont publics et indexés en continu, si bien que le nom choisi à l'étape 02 est découvrable même si vous ne le liez jamais nulle part. C'est pourquoi le compte administrateur doit être pris dans les premières minutes plutôt que la première semaine, et pourquoi la page de connexion mérite un mot de passe fort et un second facteur dès le premier jour.
La sortie vers le fiat est l'endroit où l'identité revient. Rien dans cette pile ne vous oblige à vous identifier pour accepter un paiement. Convertir le produit de la vente en monnaie bancaire l'exige presque toujours, parce que cette conversion se fait auprès d'une plateforme d'échange ou d'un courtier régulé. L'auto-hébergement déplace l'exigence d'identité du point de vente vers le point de sortie — une amélioration réelle de l'exposition, mais pas la même chose que son absence.
Vos obligations déclaratives n'ont pas déménagé avec le serveur. L'endroit où une entreprise est enregistrée et l'endroit où vit son propriétaire déterminent ce qui est dû et ce qui doit être déclaré. La juridiction de la machine qui émet les factures n'entre pas en ligne de compte. Dans la plupart des endroits, recevoir de la crypto pour des biens ou des services est un revenu ordinaire à la valeur du jour, et le céder plus tard est de nouveau un événement distinct. Une instance auto-hébergée est un meilleur registre qu'un compte chez un processeur que vous pourriez perdre — ce n'est pas un moyen de ne pas en avoir un.
Il n'y a pas de rétrofacturation, et cela joue dans les deux sens. Un paiement confirmé est définitif, et c'est exactement cette propriété qui rend la fraude contre un commerçant quasiment impossible, et qui explique pourquoi les frais sont nuls. C'est aussi pourquoi un client mécontent n'a aucun autre recours que votre bonne volonté. Publiez une politique de remboursement, utilisez la fonction de versement pour l'honorer, et comprenez que vous avez hérité du travail de résolution des litiges que le pourcentage servait autrefois à payer.
Ce que vous avez réellement acheté, précisément : l'argent arrive dans un portefeuille dont vous seul pouvez dépenser le contenu, personne ne peut empêcher la vente, personne ne prend de commission, et la liste de qui vous a payé quoi n'existe que sur une machine que vous louez sous aucun nom particulier. C'est une affirmation étroite, et une affirmation réelle. Elle ne vaut ce qu'elle coûte que si l'étape 06 est faite — un processeur de paiement auto-hébergé sans restauration testée n'est pas une amélioration commerciale, c'est un point unique de défaillance qui détient votre chiffre d'affaires.
| Niveau | Mensuel | Ressources | Ce qu'elle fait tourner confortablement |
|---|---|---|---|
| Sentinel | $3.90 | 2 vCPU · 4 GB · 120 GB · 1 Gbps | Un nœud élagué de 25–50 GB avec Lightning. Ajoutez du swap ; surveillez le disque. |
| Garrison | $7.90 | 4 vCPU · 8 GB · 240 GB · 1 Gbps | Un nœud élagué de 100 GB, Lightning et des années de marge. Le choix par défaut. |
| Ravelin | $16.90 | 8 vCPU · 16 GB · 480 GB · 2.5 Gbps | La même chose, plus une seconde chaîne ou une boutique chargée avec des plugins. |
| Bulwark | $32.90 | 16 vCPU · 32 GB · 960 GB · 5 Gbps | Un nœud d'archive avec de la marge pour continuer à grossir. Seulement si vous avez besoin de l'historique. |
BTCPay, l'indexeur et PostgreSQL réunis pèsent quelques gigaoctets et presque aucun CPU une fois le nœud synchronisé ; une boutique qui prend une centaine de paiements par jour ne troublera pas le plus petit niveau en calcul. Ce sur quoi les niveaux diffèrent, c'est le disque, et le disque est décidé entièrement par l'étape 01. La synchronisation est la seule heure vraiment lourde du projet — elle est limitée par les E/S plutôt que par le CPU, ce qui explique pourquoi le NVMe compte ici, et pas le nombre de cœurs. La bande passante est illimitée à tous les niveaux, donc un nœud Lightning joignable publiquement ne coûte rien de plus à faire tourner.
La première personne à s'inscrire sur une instance toute neuve devient administrateur, et le nom d'hôte a été publié dans les journaux de transparence des certificats dès que le certificat a été émis. Inscrivez-vous dans les minutes qui suivent la fin de l'installation, puis confirmez dans les Paramètres du serveur que l'inscription n'est pas ouverte aux inconnus.
Laisser le serveur générer le portefeuille tient en un clic, et place la seed sur une machine dont le travail est de répondre à des inconnus. Connectez plutôt une clé publique étendue : la boutique surveille, dérive et réconcilie, et ne peut pas dépenser. Gardez la moitié privée dans un portefeuille ou sur un dispositif matériel.
Une base de données de canaux datant d'hier décrit un état que votre contrepartie a déjà remplacé. La remettre en ligne peut lui offrir la totalité du solde du canal en guise de pénalité. L'archive nocturne couvre la boutique ; les canaux ont besoin du chemin de récupération documenté et d'une sauvegarde de canal copiée en continu.
Financer un canal vous donne une capacité à envoyer, pas à recevoir. Un nœud neuf contenant de l'argent échoue quand même sur chaque paiement entrant, et l'erreur ressemble à un problème de routage. Obtenez de la liquidité entrante avant d'annoncer l'option Lightning, pas après la première réclamation.
Connectez un compte vieux de trois ans à un nœud élagué, et ses anciennes transactions n'apparaissent jamais, parce que les blocs qui les contenaient ont été jetés. Rien n'est cassé, et rien ne le signale. Donnez à la boutique un compte fraîchement créé, ou faites tourner un nœud d'archive.
Un nœud est le seul processus qui grossit tout seul, et un disque plein corrompt l'index au lieu de faire une pause polie — ce qui signifie recommencer le téléchargement depuis le début. Faites le calcul de l'étape 01 en fonction du niveau que vous avez commandé, et déclenchez une alerte à quatre-vingts pour cent plutôt qu'à quatre-vingt-quinze.
Onze questions qui reviennent lors de la construction de tout cela — en commençant par les deux qui déterminent si vous devriez seulement le construire.
C'est réellement gratuit, et la forme de cette gratuité compte plus que le prix. BTCPay Server est un logiciel open source publié sous une licence permissive et maintenu par une fondation plutôt que par une entreprise avec un objectif de chiffre d'affaires ; il n'y a aucun frais par transaction, aucun pourcentage, aucun volume minimum, aucun compte à ouvrir et aucun contrat à signer, parce qu'il n'y a aucune contrepartie du tout — vous faites tourner un programme sur votre propre serveur, de la même façon que vous faites tourner un serveur web. Ce que vous payez à la place est réel, mais différent : quelques dollars par mois pour la machine, une soirée pour la mettre en place, et l'obligation permanente de maintenir à jour un service qui manipule des paiements. La comparaison que les gens devraient réellement faire n'est pas « gratuit contre un pour cent ». C'est « une tâche opérationnelle que vous possédez contre une dépendance que vous ne possédez pas », et la réponse honnête est qu'une boutique qui prend vingt paiements par an est probablement mieux servie par une solution hébergée, tandis qu'une boutique qui en prend vingt par semaine y gagne à la fois en coût et en liberté.
C'est vous, et le mécanisme mérite d'être compris plutôt que simplement cru sur parole. La configuration recommandée donne à BTCPay une clé publique étendue issue d'un portefeuille que vous contrôlez déjà. À partir de cette clé, le serveur peut dériver une adresse de réception neuve pour chaque facture et surveiller la chaîne pour les paiements qui lui sont destinés — et il ne peut pas construire une dépense valide, parce que la moitié privée ne quitte jamais votre portefeuille. L'argent se déplace du client directement vers une adresse dont vous seul pouvez vider le contenu ; rien n'est jamais détenu sur le serveur, donc il n'y a rien à retenir, geler, ou perdre en cas de faille. BTCPay proposera aussi de générer un portefeuille pour vous et de garder la seed sur le serveur, ce qui est pratique et constitue la seule configuration que ce guide déconseille pour tout ce qui détient un chiffre d'affaires réel : cela transforme une machine publique, exposée à internet, en portefeuille chaud. Lightning est la véritable exception — les fonds des canaux doivent être actifs pour router — c'est pourquoi le solde Lightning devrait être traité comme une caisse plutôt que comme un coffre-fort.
Cela dépend entièrement d'une seule décision, et l'écart est de deux ordres de grandeur. Un nœud Bitcoin Core d'archive conserve chaque bloc jamais miné : confortablement au-delà de 700 GB en 2026, et en ajoutant environ 50 GB par an, si bien qu'il a besoin d'un niveau dimensionné en conséquence, et qu'il continuera d'en avoir besoin de plus. Un nœud élagué valide chaque bloc exactement de la même façon, puis jette les anciens, en conservant une fenêtre glissante — le générateur de déploiement fournit des fragments qui élaguent à environ 100, 50, 25 ou 5 GB, et tout ce qui va de 50 GB vers le haut est un choix de production parfaitement sérieux pour un commerçant. Ajoutez environ 10 à 20 GB pour l'indexeur, la base de données, le nœud Lightning et le système d'exploitation, et le calcul tombe juste : un niveau de 120 GB fait tourner un déploiement élagué de 25–50 GB, un niveau de 240 GB en fait tourner un de 100 GB avec des années de marge, et l'archive veut 960 GB. Choisissez l'élagage sauf raison spécifique de ne pas le faire ; le modèle de sécurité est identique.
Partiellement, et cela vaut la peine de savoir exactement où se situe la limite. La pile peut être pointée vers un nœud Bitcoin que vous faites déjà tourner ailleurs — une machine sur le même tailnet, ou une autre derrière un tunnel — et c'est un arrangement pleinement pris en charge qui vous épargne une seconde copie de la chaîne si vous avez déjà fait le travail dans le guide du nœud Lightning. Ce que vous ne pouvez pas raisonnablement faire, c'est faire tourner un processeur de paiement contre le nœud public de quelqu'un d'autre, et la raison n'est pas une question de licence mais de confidentialité et de confiance : quiconque répond à vos requêtes apprend chaque adresse que votre boutique surveille, ce qui revient à apprendre votre chiffre d'affaires, et peut aussi vous mentir sur le fait qu'une facture a été payée. Il existe une troisième option vers laquelle les gens se tournent — utiliser une instance BTCPay hébergée, gérée par un tiers — et c'est une façon parfaitement raisonnable de commencer. Sachez simplement que cela déplace les données de la boutique vers un opérateur qui peut les voir, ce qui est justement l'essentiel de ce à quoi servait l'auto-hébergement.
Non, et il est tout à fait raisonnable de la sauter le premier jour. On-chain uniquement est une configuration complète et fonctionnelle : les factures sont payées, le client attend une confirmation, la boutique encaisse. Ce que Lightning apporte, c'est la différence entre « environ dix minutes et des frais qui font mal sur les petits montants » et « deux secondes et une fraction de centime », ce qui est la différence entre une caisse qui fonctionne pour une facture de $400 et une qui fonctionne aussi pour une facture de $4. Le coût, c'est que Lightning est un second démon avec ses propres fonds, ses propres modes de défaillance et sa propre discipline de sauvegarde — y compris le problème de liquidité entrante de l'étape 05 et l'avertissement sur l'état toxique de l'étape 06. Un ordre sensé consiste à lancer en on-chain, confirmer que tout le pipeline fonctionne avec de l'argent réel, puis ajouter Lightning comme un second projet délibéré plutôt que de le greffer dans la même soirée.
N'importe quel portefeuille capable d'exporter une clé publique étendue pour un compte unique — Sparrow, Electrum, BlueWallet, ou un portefeuille matériel via l'un de ceux-ci — et ce qui compte n'est pas la marque, mais le fait qu'il s'agisse d'un compte dédié plutôt que de celui qui détient votre épargne. Deux raisons à cela. La première est la confidentialité, et elle est permanente : une clé publique étendue est un index maître de chaque adresse qu'elle dérivera un jour, si bien que quiconque l'obtient peut énumérer chaque paiement que ce compte a jamais reçu et recevra jamais. Donner à la boutique son propre compte signifie qu'une fuite n'expose que les recettes de la boutique, rien d'autre. La seconde est opérationnelle : un compte dédié rend les revenus de la boutique lisibles sans que vous ayez à passer au crible un historique mélangé, et cela fait du transfert vers un stockage à froid une décision unique et sans surprise. Un portefeuille matériel détenant la clé privée, avec la boutique qui surveille la clé publique, est l'arrangement à viser.
Oui, avec la réserve que chaque chaîne supplémentaire est un nœud supplémentaire entier, avec son propre disque, son propre temps de synchronisation et sa propre maintenance. Le générateur prend en charge directement une deuxième et une troisième cryptomonnaie, et il existe une intégration Monero disponible comme fragment additionnel — le même déploiement présente alors au client un choix de rails à la caisse. Ce que les gens sous-estiment, c'est la facture en ressources : chaque chaîne que vous activez est un démon de plus qui indexe un registre de plus sur le même volume, et deux chaînes sur un niveau dimensionné pour une seule, c'est ainsi qu'une machine de paiement tombe à court de disque un dimanche. Si Monero est important pour votre boutique, lisez le guide du nœud Monero d'abord et envisagez de lui donner sa propre machine ; un processeur de paiement hors service parce qu'un démon sans rapport a rempli le disque est pire qu'un processeur qui ne prend que du Bitcoin.
Quatre façons, dans l'ordre croissant de la quantité de logiciel que vous avez déjà. Si vous n'avez rien, BTCPay fournit un point de vente hébergé et une page de demande de paiement que vous pouvez envoyer comme un lien — cela suffit pour facturer un client ou prendre des paiements sur un étal de marché sans aucun site web. Si vous avez un site statique, un bouton de paiement est un extrait de HTML. Si vous avez une vraie vitrine, il existe des plugins maintenus pour les plateformes e-commerce courantes, qui font de Bitcoin un moyen de paiement supplémentaire au moment de payer, avec le statut de la commande reporté automatiquement. Et si vous avez votre propre application, l'API REST émet des factures, rapporte leur état, et appelle un webhook que vous spécifiez quand l'une d'elles se règle — ce qui est l'intégration qui vieillit le mieux, parce qu'elle ne dépend de rien d'autre que de HTTP. Commencez par une demande de paiement, prouvez que l'argent arrive, puis intégrez.
Pour l'on-chain, non, et c'est la récompense discrète de la conception en lecture seule : les pièces n'ont jamais été sur le serveur. Les adresses sont dérivées d'une clé publique, donc une installation neuve avec la même clé publique étendue redécouvre chaque paiement ; ce que vous perdez en cas de panne totale, c'est la configuration de la boutique et son historique de factures, et c'est précisément à cela que sert le script de sauvegarde. Lightning est une réponse authentiquement différente, et elle mérite sa propre phrase : les fonds des canaux sont vivants, l'état du canal change à chaque paiement, et restaurer une ancienne copie de cet état peut vous coûter le solde du canal intégralement, parce que publier un état déjà remplacé est exactement ce que le protocole punit. La posture correcte est donc asymétrique. Sauvegardez la base de données et la configuration selon un calendrier, chiffrez-la, envoyez-la quelque part qui n'est pas cette machine — et traitez la sauvegarde statique de canal Lightning comme un artefact séparé, copié en continu, plutôt que comme une ligne de l'archive nocturne.
Non, et cela vaut la peine d'être dit crûment, parce que le contraire est tacitement supposé. Supprimer le processeur de paiement supprime un intermédiaire, des frais, et une partie capable de geler vos fonds. Cela ne change pas ce que vous devez, à qui, ni si une vente est imposable — cela découle d'où vous et votre entreprise vous situez, pas d'où se trouve le serveur ni de quel logiciel a émis la facture. Dans la plupart des juridictions, recevoir de la cryptomonnaie pour des biens ou des services est un revenu d'entreprise ordinaire, à la valeur du jour où il a été reçu, et le céder plus tard est de nouveau un événement distinct ; le fait que l'enregistrement vive désormais dans votre propre base de données plutôt que dans celle d'un processeur ne rend pas cela optionnel, et une instance auto-hébergée est en pratique une meilleure piste d'audit qu'une capture d'écran d'un compte que vous n'avez plus. Là où se situe le véritable gain de confidentialité, c'est plus étroit, mais réel : aucun tiers ne détient une liste continue de vos clients et des montants. Demandez à un comptable de votre propre juridiction pour le reste.
Oui — une instance BTCPay est une application web ordinaire, avec une base de données ordinaire et un démon blockchain ordinaire, et il n'y a rien dans la politique d'utilisation acceptable qui la traite différemment d'une boutique ou d'un blog. Les remarques pratiques concernent les ressources plutôt que la politique : un nœud en synchronisation est gourmand en disque et en E/S pendant son premier jour, puis presque inactif, la bande passante est illimitée à tous les niveaux, si bien qu'un nœud Lightning public n'est pas facturé à l'usage, et les ports entrants pour les connexions de pairs sont les vôtres à ouvrir. Ce qui s'aligne avec le reste du site, c'est la symétrie : le compte n'a pas besoin de votre nom légal, la facture se règle en Monero, Bitcoin ou Lightning, et la machine qui connaît désormais chacun de vos clients est louée à une entreprise qui ne sait pas qui vous êtes. Un processeur que vous auto-hébergez sur un compte identifié a déplacé le registre, pas l'exposition.
Garrison — 4 vCPU, 8 GB et 240 GB de NVMe pour $7.90 par mois, à Helsinki, Stockholm, Oslo ou Reykjavík. Suffisant pour un nœud Bitcoin élagué, un démon Lightning, l'indexeur et la boutique, avec de la marge pour des années. Aucun e-mail à l'inscription, aucune pièce d'identité, et aucune entreprise ne détenant la liste de tous ceux qui vous ont un jour payé.
Dernière révision · 2026-10-12 · Références · Documentation de BTCPay Server (déploiement Docker, fragments de stockage, sauvegarde et restauration, paramètres de la boutique), documentation de Bitcoin Core sur l'élagage, documentation des implémentations Lightning sur les sauvegardes statiques de canaux · Fréquence · annuellement
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Your own LN node — bitcoind + LND or Core Lightning, on a VPS.
Votre propre monerod — complet ou élagué, RPC derrière un tunnel, diffusion via Tor.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
Hébergement privé, conçu dans le Nord.