BTCPay Server auto-hébergé sur un VPS : accepter Bitcoin et Lightning sans prestataire de paiement

Ce qu'est vraiment BTCPay Server, et ce qu'il remplace

BTCPay Server n'est ni un portefeuille ni une entreprise de paiement. C'est la couche logicielle qui se place entre votre site web et votre propre nœud Bitcoin, et qui accomplit le travail fastidieux et nécessaire qu'un prestataire fait normalement pour vous : elle génère une adresse fraîche ou une facture Lightning par commande, indique un montant fiat à un taux qu'elle verrouille pour toute la durée de vie de la facture, surveille la chaîne pour repérer le paiement, décide du moment où le paiement compte comme réglé, et prévient votre boutique. L'argent ne passe jamais par le compte de qui que ce soit sur le chemin qui mène jusqu'à vous, parce qu'il n'existe aucun compte — les adresses appartiennent à un portefeuille que vous contrôlez, et le logiciel ne fait que les surveiller.

Cette différence architecturale à elle seule est toute la raison de le faire tourner. Un prestataire hébergé est une entreprise dotée d'un service conformité, d'une banque, et d'un document de conditions d'utilisation qui se réserve le droit de retenir votre règlement pendant qu'il vous examine. Il vous demandera des documents d'identité, parce qu'il déplace de l'argent en votre nom et que son propre régulateur exige qu'il sache à qui appartient cet argent. L'auto-hébergement supprime l'intermédiaire plutôt que de négocier avec lui : il n'y a pas d'onboarding, pas de revue mensuelle de volume, pas de calendrier de règlement, et rien qu'un tiers puisse geler, parce qu'à aucun moment un tiers ne détient les fonds.

Ce que vous obtenez en échange du travail, c'est un paiement véritablement complet. Des factures avec une expiration et un taux de change verrouillé. On-chain et Lightning dans la même facture, de sorte qu'un client qui paie deux dollars ne se voit pas demander des frais de réseau de trois dollars. Une page point de vente, un bouton de don, une page de financement participatif, un bouton de paiement que vous pouvez coller dans n'importe quel HTML. Des plugins pour les plateformes de boutique courantes, et une API REST complète si votre boutique est quelque chose que vous avez codé vous-même. Remboursements, pull payments, versements. Payjoin, si briser l'heuristique de propriété commune des entrées côté réception vous importe.

Cela vaut la peine d'être précis sur ce qui n'est pas inclus, parce que la plupart des déceptions liées aux paiements auto-hébergés viennent du fait d'attendre un produit là où il n'y a qu'un protocole. Personne ne convertit votre Bitcoin en euros pour le virer sur une banque ; si vous en avez besoin, il vous faut quand même une plateforme d'échange, et cette plateforme vous demandera quand même qui vous êtes. Personne ne garantit les rétrofacturations, même s'il n'y en a aucune à garantir. Personne ne décroche le téléphone à deux heures du matin quand le nœud cesse de suivre la chaîne — c'est désormais votre travail, et c'est la partie de ce guide que les gens sautent.

La machine : ce dont elle a vraiment besoin, et où s'arrête l'offre bon marché

L'application est légère. La pile qui la porte ne l'est pas. Un déploiement par défaut fait tourner Bitcoin Core, un indexeur d'adresses appelé NBXplorer, une base de données PostgreSQL, l'application web BTCPay, un reverse proxy qui gère les certificats, et — si vous l'activez — un nœud Lightning, chacun dans son propre conteneur. L'application web serait parfaitement heureuse sur un raspberry pi. Bitcoin Core, non.

La mémoire est la première chose que les gens sous-dimensionnent. Deux gigaoctets suffiront techniquement à démarrer la pile, et passeront la synchronisation initiale à swapper, ce qui, sur un NVMe partagé, est un excellent moyen de transformer un jour en trois. Quatre gigaoctets sont un plancher raisonnable pour de l'on-chain seul. Huit sont le plancher réaliste dès que Lightning entre en jeu, parce que vous faites alors tourner un second démon qui tient sa propre base de données et sa propre vue du graphe, et parce que bitcoind se comporte bien mieux pendant le téléchargement initial quand vous pouvez lui confier un grand dbcache plutôt que la valeur par défaut, conservatrice. Les notes reduce-memory de Bitcoin Core sont la référence pour savoir quels réglages échangent de la RAM contre du temps.

Le disque vient en second, et c'est lui qui détermine votre offre. La chaîne non élaguée dépasse les sept cents gigaoctets et en ajoute environ soixante par an, si bien qu'un nœud d'archive ne tient plus sur aucun de nos paliers VPS et relève d'une machine dédiée, où une paire en miroir vous laisse encore un téraoctet. L'élagage change complètement la donne — le nœud conserve une fenêtre glissante des blocs récents et jette le reste, et pour un point de paiement, ce n'est absolument pas un compromis, parce qu'un marchand n'a jamais besoin de servir des blocs historiques à qui que ce soit. Ajoutez la base de données de l'indexeur, PostgreSQL, les images et volumes Docker, le stockage propre au nœud Lightning, et les journaux, et un déploiement élagué tient confortablement dans une classe de machine de l'ordre de la centaine de gigaoctets, avec de la marge pour grandir.

Le CPU compte surtout pour une semaine de votre vie. La validation des signatures pendant le téléchargement initial de la chaîne est la chose la plus lourde que ce serveur fera jamais ; ensuite, vérifier un bloc toutes les dix minutes et répondre à une poignée de requêtes de facturation est proche de l'inactivité. Achetez des cœurs pour la synchronisation, pas pour le régime permanent — ou prenez l'offre plus petite et acceptez que la synchronisation prenne plus longtemps, ce qui est un compromis parfaitement raisonnable si vous n'êtes pas pressé.

L'élagage économise du disque, pas du temps — et la synchronisation est le facteur limitant

Le malentendu le plus courant sur le fonctionnement d'un nœud, c'est de croire que l'élagage le rend rapide. Ce n'est pas le cas. Un nœud élagué télécharge chaque bloc depuis le bloc de genèse et valide chaque signature dans chacun d'eux, exactement comme un nœud d'archive ; la seule différence est qu'une fois un bloc validé et devenu inutile, il est supprimé au lieu d'être conservé. Vous économisez du disque. Vous n'économisez rien sur la bande passante et rien sur le temps. Quelqu'un qui s'attend à ce qu'un nœud élagué soit prêt en une heure passera cette heure-là persuadé que quelque chose est cassé.

Le temps que cela prend réellement dépend presque entièrement de la quantité de cache que vous lui avez donnée et de la vitesse du disque. Sur du NVMe avec plusieurs gigaoctets de dbcache et quatre cœurs non partagés, un jour est une attente raisonnable. Sur une petite offre avec le cache par défaut et un voisin chargé, deux ou trois jours sont normaux, et le processus passe l'essentiel de ce temps à écrire l'ensemble UTXO sur le disque encore et encore, parce qu'il ne peut pas le tenir en mémoire. C'est le seul moment où une offre temporairement plus grande vaut réellement le coût : montez en gamme pour la synchronisation, redescendez ensuite. Une facturation au mois sans contrat est précisément ce qui rend cette manœuvre bon marché.

Ensuite, une fois la chaîne synchronisée, il y a une seconde attente que presque personne ne planifie. Quand vous connectez un portefeuille qui a déjà de l'historique — une clé publique étendue d'un portefeuille matériel que vous utilisez depuis un an — l'indexeur doit scanner la chaîne à la recherche des adresses qui en dérivent. Sur un nœud élagué, ce scan est limité par ce qui reste encore sur le disque, ce qui explique pourquoi l'ordre de l'installation compte : pointez le portefeuille vers le nœud avant que les anciens blocs ne soient jetés si vous avez besoin que les transactions historiques apparaissent, ou acceptez que la boutique démarre à partir d'aujourd'hui, et voyez-y le nouveau départ propre que c'est généralement.

La règle pratique d'ordonnancement, c'est que la machine doit être en service et en cours de synchronisation bien avant que la boutique n'en ait besoin. Provisionnez-la, lancez le téléchargement, et passez la journée qui suit à faire les parties qui ne dépendent pas de la chaîne : DNS, certificats, le plugin de la boutique, le portefeuille, la routine de sauvegarde. Si vous laissez le nœud pour la fin, vous découvrirez que vous vous êtes engagé sur une date de lancement conditionnée par un processus que personne ne peut accélérer.

Les clés : la décision d'architecture que vous prenez une bonne fois pour toutes

La question qui détermine à quel point votre pire jour peut être mauvais est simple : le serveur peut-il dépenser l'argent ? Pour les paiements on-chain, la réponse devrait être non, et BTCPay est conçu pour vous permettre de dire non. Vous importez une clé publique étendue — un xpub, ou ses équivalents modernes — dérivée d'un portefeuille matériel ou d'un signeur hors ligne. Le serveur dérive de cette clé une nouvelle adresse de réception par facture, surveille la chaîne pour les paiements vers ces adresses, et les rapporte. Il ne peut pas construire une dépense valide, parce qu'il n'a jamais vu de clé privée. Une compromission totale de la machine vous coûte alors la machine et les données de commande de vos clients, ce qui est grave, mais cela ne vous coûte pas les recettes.

L'alternative — laisser BTCPay générer et détenir un portefeuille chaud par commodité — est proposée, c'est occasionnellement le bon choix pour de tout petits volumes, et cela devrait être une décision délibérée plutôt que la chose qui est arrivée parce que c'était le bouton par défaut. Si vous la choisissez, traitez le solde sur ce serveur comme vous traiteriez les espèces dans la caisse d'une boutique : videz-le à intervalles réguliers, ne conservez que ce dont une journée de commerce a besoin, et gardez à l'esprit que la seed se trouve sur un disque, dans un datacentre.

Lightning est l'exception qu'on ne peut pas éviter. Un nœud Lightning doit signer des transactions en temps réel pour mettre à jour l'état des canaux, donc ses clés sont nécessairement chaudes, et il n'existe aucun mode en lecture seule qui vous permette quand même de recevoir. Ce n'est pas un défaut de BTCPay ; c'est ce qu'exige le protocole. La bonne réponse consiste à dimensionner le solde Lightning pour la tâche à accomplir — assez d'entrant pour recevoir un jour ou une semaine de commandes, pas votre trésorerie — et à faire sortir régulièrement les recettes accumulées vers du stockage à froid, la même discipline que toute boutique applique à sa caisse.

Une dernière chose a sa place dans cette décision, parce que c'est la partie que les gens laissent de côté jusqu'après l'incident : notez où se trouve la seed, sous une forme sur laquelle votre successeur pourrait agir, et stockez-la quelque part qui n'est ni le serveur ni le même bâtiment que le serveur. Le chiffrement intégral du disque sur le VPS protège le disque au repos contre une copie hors ligne ; cela ne fait rien pour une machine en fonctionnement, et cela n'aide absolument pas si la seule copie de votre seed s'y trouvait.

Lightning est un problème de liquidité déguisé en logiciel

Installer un nœud Lightning est facile. Y recevoir votre premier paiement ne l'est pas, et la raison piège presque tout le monde. Un canal Lightning est un solde à deux faces : quand vous ouvrez un canal et le financez, toute la capacité se trouve de votre côté, ce qui signifie que vous pouvez payer d'autres personnes et que personne ne peut vous payer. Recevoir exige de la capacité entrante — des fonds assis de l'autre côté d'un canal, prêts à se déplacer vers vous. Un nœud fraîchement installé avec trois canaux sortants bien financés ne peut toujours pas accepter le moindre satoshi d'un client, et le paiement n'offrira tout simplement pas Lightning comme option.

Il existe trois façons honnêtes d'y remédier. Vous pouvez acheter de la capacité entrante auprès d'un fournisseur de liquidité, ce qui est le plus rapide et coûte des frais proportionnels au montant et à la durée. Vous pouvez effectuer un submarine swap — payer via Lightning et recevoir on-chain, ce qui déplace votre propre solde vers l'autre côté de vos canaux et convertit du sortant en entrant, au prix des frais du swap. Ou vous pouvez demander à un pair bien connecté d'ouvrir un canal vers vous, ce qui est gratuit si vous avez la relation, et lent si vous ne l'avez pas. Quel que soit votre choix, budgétez-le avant le lancement, et dimensionnez-le en fonction de votre flux de commandes attendu plutôt qu'en choisissant un chiffre rond.

Les canaux exigent aussi un entretien que l'on-chain n'exige pas. La capacité entrante se consomme à mesure que les clients vous paient : chaque paiement reçu déplace du solde de leur côté d'un canal vers le vôtre, si bien qu'une boutique qui ne fait que recevoir épuisera progressivement sa capacité à recevoir et devra se rééquilibrer ou passer par un swap. Les canaux se ferment, parfois unilatéralement quand un pair disparaît, et une fermeture forcée place vos fonds derrière un verrou temporel pendant un moment et coûte des frais on-chain. Les nœuds doivent être en ligne pour accepter les paiements et surveiller les contreparties malhonnêtes. Rien de tout cela n'est difficile, mais tout cela est permanent, et c'est la raison pour laquelle de nombreuses boutiques font tourner Lightning pour les petites commandes et règlent tranquillement on-chain tout ce qui dépasse un certain seuil.

La récompense pour cette peine est bien réelle. Les frais on-chain sont indifférents à la taille du paiement, ce qui rend une commande à cinq dollars économiquement absurde quand le mempool est chargé, et parfaitement raisonnable quand il ne l'est pas — et vous ne contrôlez pas lequel des deux cas s'applique le jour de votre lancement. Les paiements Lightning se règlent en moins d'une seconde pour une fraction de centime, quelle que soit la congestion, et pour tout ce qui est au prix d'un café, d'un téléchargement, d'une recharge d'API ou d'un abonnement mensuel, c'est la différence entre un paiement qui fonctionne et un autre qui perd tranquillement la vente.

La sauvegarde qui vous détruit : ne faites jamais revenir un nœud Lightning en arrière

Cette section est la raison de lire ce guide même si vous connaissez déjà tout le reste. Restaurer un nœud Lightning à partir d'une ancienne copie de ses données n'est pas un acte neutre, et dans de mauvaises circonstances, cela détruit les soldes de vos canaux. Le réflexe ordinaire d'administration système — prendre un instantané, restaurer l'instantané quand quelque chose casse — est précisément le réflexe qui cause la perte.

Le mécanisme en jeu est la pénalité de triche du protocole. Chaque mise à jour de canal remplace la précédente, et chaque partie remet à l'autre les moyens de la punir si elle publie un jour un état obsolète. C'est ce qui rend un canal à deux parties sûr sans arbitre. Cela signifie aussi qu'un nœud restauré à partir de la copie d'hier croit sincèrement qu'un ancien état est l'état actuel, et s'il agit selon cette croyance — en fermant de force, ou simplement parce qu'on le lui demande — la contrepartie est en droit de prendre l'intégralité du solde du canal, et son logiciel le fera automatiquement. Vous n'aviez pas l'intention de tricher. Le protocole ne peut pas faire la différence, et il n'est pas conçu pour cela.

La règle est donc absolue, et mérite d'être écrite au mur : ne restaurez jamais un nœud Lightning à un état antérieur. Ni depuis un instantané du système de fichiers, ni depuis un dump de base de données, ni depuis une copie du répertoire de données que vous avez faite la semaine dernière, ni depuis les instantanés horaires fournis avec le serveur. Les instantanés sont excellents pour le reste de la machine et dangereux pour exactement ce répertoire-là, et le danger est silencieux — le nœud démarrera, aura l'air en bonne santé, et vous coûtera de l'argent plus tard.

Ce que vous conservez à la place, c'est une sauvegarde statique de canal : un petit fichier, mis à jour chaque fois qu'un canal s'ouvre ou se ferme, qui contient juste assez d'information pour demander à chaque contrepartie de fermer coopérativement et de vous rendre vos fonds. LND l'appelle channel.backup et en documente la sémantique dans son guide de récupération ; Core Lightning propose un équivalent, accompagné d'un plugin qui maintient une copie répliquée en continu de la base de données. Restaurer l'un de ces fichiers ne reprend pas vos canaux là où ils en étaient — cela les ferme tous de force et récupère le solde, ce qui est le seul résultat correct et sûr après une perte totale. Stockez-la hors de la machine, gardez-la à jour, et gardez à l'esprit que c'est une police d'assurance, pas un bouton de reprise.

Pour tout le reste, sauvegardez normalement et généreusement. Le déploiement BTCPay embarque son propre script de sauvegarde qui arrête la pile, dump la base de données et la configuration de façon cohérente, puis relance tout ; exécutez-le selon un calendrier et copiez le résultat ailleurs, idéalement sur un second serveur dans une autre juridiction. La base de données contient vos factures, boutiques, utilisateurs, clés API et réglages — pas votre argent, mais tout votre historique, qui est ce qui vous manquera vraiment.

L'emplacement du serveur fait partie de la pile de paiement

Il est facile de penser à l'hébergement comme une commodité sous-jacente à la partie intéressante. Pour un point de paiement, ce n'est pas le cas, parce que le paiement est l'unique composant dont la disponibilité équivaut directement au chiffre d'affaires, et parce qu'un serveur est un objet physique dans une juridiction légale, avec un fournisseur que l'on peut contacter à son sujet. Quand votre infrastructure de paiement est un prestataire hébergé, la posture de conformité de ce fournisseur est votre posture de conformité. Quand vous vous auto-hébergez, c'est la posture de votre fournisseur d'hébergement qui joue ce rôle — et si vous vous êtes auto-hébergé spécifiquement pour échapper au pouvoir discrétionnaire d'une entreprise de paiement, il serait imprudent de remettre ce même pouvoir discrétionnaire à l'entreprise qui fait tourner la machine.

Il y a trois propriétés qui méritent une attention délibérée. La première est l'identité que détient l'hébergeur : un compte ouvert avec une adresse e-mail et payé en cryptomonnaie n'a rien à remettre et rien à geler, ce qui est exactement le raisonnement qui vous a poussé à vous auto-héberger au départ. L'hébergement no-KYC explique ce que cela signifie et ne signifie pas en pratique, y compris son corollaire inconfortable — un fournisseur qui n'a jamais su qui vous étiez ne peut pas vous rendre votre compte si vous en perdez l'accès.

La deuxième est la juridiction. Un point de paiement qui sert des clients dans de nombreux pays se trouve dans exactement un seul, et le droit de celui-ci détermine qui peut contraindre le fournisseur, sur quelle base, et à quelle vitesse. Nos quatre régions — Islande, Pays-Bas, Roumanie et Suisse — diffèrent de façon significative à cet égard et en latence vers différentes bases de clients, et le choix d'une juridiction détaille correctement ces arbitrages. Il y a aussi un angle opérationnel plus terre-à-terre : placez le nœud près de vos clients si la latence du paiement compte, et près du reste de votre infrastructure si ce n'est pas le cas.

La troisième est le paiement de l'hébergement lui-même, qui est la boucle que la plupart des gens laissent ouverte. Faire tourner un paiement anonyme et non-custodial sur un serveur facturé à une carte de crédit à votre propre nom crée précisément le lien que vous avez construit le reste de la pile pour éviter. Payer la machine en Monero ou en Bitcoin referme cette boucle — le même raisonnement, appliqué un niveau plus bas. Cela signifie aussi que la facture d'infrastructure ne peut pas être interrompue par le propre modèle de risque d'un émetteur de carte, un mode de défaillance qui a réellement mis des boutiques hors ligne.

Enfin, les exigences ennuyeuses de fiabilité sont plus strictes ici que pour un blog. Un nœud Lightning hors ligne ne peut pas recevoir, ne peut pas surveiller une contrepartie malhonnête, et peut être fermé de force par des pairs qui ne peuvent pas le joindre. Un nœud Bitcoin qui prend du retard sur la chaîne montre aux clients des factures qu'il ne peut pas régler. La bande passante illimitée compte plus qu'il n'y paraît, parce qu'un nœud qui participe véritablement au réseau sert des blocs à ses pairs, et une offre avec compteur vous présentera une facture qui n'a rien à voir avec le trafic de votre boutique.

L'ordre d'installation qui évite une seconde synchronisation

Le déploiement que tout le monde utilise est la distribution Docker officielle : un dépôt que vous clonez sur un serveur neuf, un jeu de variables d'environnement qui décrit ce que vous voulez, et un script d'installation qui génère un fichier compose et fait démarrer toute la pile. C'est véritablement clé en main, et la raison pour laquelle les installations tournent mal n'est presque jamais le script — c'est de faire les choses dans un ordre qui vous force à refaire l'étape coûteuse.

Commencez par une machine propre et l'enregistrement DNS. L'installeur demande un certificat pour le nom d'hôte que vous lui donnez, et cette demande part vers une autorité de certification qui se reconnectera à votre adresse sur le port 80. Si l'enregistrement ne résout pas encore, ou si les ports sont fermés, la pile démarre sans TLS et c'est à vous de déterminer laquelle des trois choses a échoué. Créez l'enregistrement A, confirmez qu'il répond depuis un endroit qui n'est pas votre propre ordinateur portable, ouvrez les ports 80 et 443, et alors seulement, lancez l'installeur.

Décidez des fragments avant la première exécution, pas après. L'environnement indique au générateur quelles chaînes activer, quelle implémentation Lightning utiliser, s'il faut élaguer et avec quelle agressivité, s'il faut exposer un service onion en plus de l'hôte clearnet, et quel reverse proxy configurer. Plusieurs de ces choix coûtent peu à changer plus tard ; ceux qui touchent au nœud — activer une chaîne, activer ou désactiver l'élagage, changer d'implémentation Lightning — impliquent de retélécharger ou de réindexer quelque chose, et retélécharger quelque chose est ce qui coûte une journée. Lisez la liste des fragments une fois, choisissez délibérément, puis exécutez-la.

Pendant que la chaîne se télécharge, faites le reste. Créez votre boutique et définissez sa devise, l'expiration de ses factures et le nombre de confirmations que vous voulez avant qu'une facture ne compte comme réglée — une décision qui mérite d'être prise délibérément, parce que l'acceptation à zéro confirmation est rapide et parfois erronée, et que six confirmations sont sûres et prennent une heure. Importez le portefeuille en lecture seule. Installez le plugin de boutique et pointez-le vers le serveur avec une clé API restreinte plutôt qu'avec le compte admin. Configurez la source de taux. Envoyez-vous une facture test pour un montant dérisoire et payez-la, on-chain et via Lightning, depuis un portefeuille qui n'est pas sur la même machine — le nombre de déploiements qui n'ont jamais été testés une seule fois avec de l'argent réel est plus élevé que quiconque ne le voudrait.

Notez ensuite la procédure de mise à jour, parce qu'elle existe et tient en une seule commande. La distribution embarque son propre outil de mise à jour qui récupère les nouvelles images et redémarre la pile dans le bon ordre, et un point de paiement qui fait tourner une version vieille d'un an porte tous les bugs corrigés depuis. Mettez-la dans un calendrier, lisez les notes de version avant de l'exécuter, et prenez d'abord la sauvegarde.

Durcir une machine qui détient de l'argent

Les conseils génériques s'appliquent intégralement et sont détaillés dans la checklist de durcissement : des clés plutôt que des mots de passe, pas de connexion root via SSH, un pare-feu à refus par défaut, des mises à jour de sécurité automatiques, et un journal que vous lisez vraiment. Ce qui suit est la partie spécifique à cette machine, et le thème central est que la surface d'attaque d'un point de paiement n'a pas la même forme que celle d'un serveur web.

Gardez l'interface d'administration hors de l'internet public si vous le pouvez. Le tableau de bord de BTCPay est le plan de contrôle de votre argent — il peut créer des pull payments, changer de portefeuilles et émettre des clés API — et il n'a pas besoin d'être joignable par le monde entier simplement parce que les pages de facture le sont. Placer le chemin d'administration derrière un VPN ou un service onion, ou derrière une liste blanche, élimine toute une catégorie de risque au prix d'une étape supplémentaire dans votre propre flux de travail. Un tunnel WireGuard vers le serveur en est la version la moins intrusive.

Traitez les clés API comme l'identifiant principal plutôt que comme une réflexion après coup, parce qu'en pratique, c'est par elles que la boutique communique avec le paiement — et un attaquant procéderait de la même manière. Émettez une clé par intégration, restreignez-la à la boutique et aux permissions dont elle a réellement besoin, stockez-la dans la configuration secrète de la boutique plutôt que dans un dépôt, et faites-la tourner quand quelqu'un quitte l'équipe. Une clé non restreinte sur un hébergeur web compromis équivaut fonctionnellement à remettre le tableau de bord.

Surveillez les deux états de défaillance propres à cette pile, parce qu'aucun des deux ne ressemble à une panne. Un nœud qui a cessé de suivre la chaîne continuera de servir le site et continuera de montrer aux clients des factures qui ne pourront jamais se régler. Un nœud Lightning qui a perdu la connexion à ses pairs continuera d'accepter des commandes on-chain tout en refusant tranquillement chaque paiement Lightning. Surveillez la hauteur de bloc par rapport à une référence publique, surveillez le nombre de canaux et le solde entrant, et alertez sur les deux — c'est la supervision que personne ne met en place avant que cela ne leur coûte, la première fois, une journée de commandes.

Gardez la machine ennuyeuse à tous les autres égards. Un point de paiement est un mauvais endroit pour aussi faire tourner votre serveur mail, votre bac à sable de développement et un serveur de jeu pour vos amis, non pas parce que les logiciels entrent en conflit, mais parce que chaque service supplémentaire est une porte d'entrée de plus et une chose de plus dont la mise à jour peut faire tomber le paiement. Si vous voulez le reste, un second petit serveur coûte moins cher que les frais de transaction que vous êtes en train d'éviter.

Monero et les monnaies que BTCPay ne parle pas nativement

Bitcoin et Lightning sont des citoyens de premier ordre dans BTCPay, et une poignée de chaînes proches de Bitcoin sont prises en charge directement. Tout le reste arrive par le système de plugins introduit avec la deuxième version majeure, et cela vaut la peine de comprendre la différence de maturité avant de promettre une méthode de paiement sur votre page de paiement.

Monero est celle dont on vous parle le plus souvent, et cela fonctionne bel et bien — via un plugin adossé à votre propre monerod et un daemon RPC de portefeuille, tournant aux côtés de la pile Bitcoin. La conception est la même que celle de Bitcoin sur les points qui comptent : vous faites tourner le nœud, vous détenez les clés, le logiciel surveille les paiements. Ce qui diffère, c'est le coût opérationnel. C'est une seconde blockchain à télécharger et à maintenir synchronisée, c'est un second daemon à surveiller et à mettre à jour, et le plugin est maintenu par la communauté plutôt que par l'équipe centrale, ce qui signifie que sa cadence de publication lui est propre. Si Monero est un simple plus agréable à avoir, pesez cela honnêtement ; si la confidentialité au point de vente est toute la raison pour laquelle vos clients sont venus, cela vaut la peine, et la comparaison entre les deux chaînes détaille ce que chacune dissimule réellement.

La règle générale pour toute chaîne supplémentaire est de se demander ce qu'elle vous coûte quand elle casse. Chaque chaîne que vous activez est un nœud qui peut prendre du retard, un portefeuille qu'il faut sauvegarder, une source de taux qui peut devenir obsolète, et une conversation de support avec un client dont le paiement est bloqué. Deux méthodes de paiement bien tenues valent mieux que six négligées, et un paiement qui propose une monnaie dont le nœud est désynchronisé depuis une semaine est pire que s'il ne l'avait jamais proposée.

Il existe aussi une voie intermédiaire légitime que l'on oublie souvent : vous n'êtes pas obligé de faire tourner vous-même chaque chaîne pour l'accepter. Rien ne vous empêche d'afficher une adresse statique pour une chaîne que vous réglez manuellement à faible volume, ou de faire tourner la seconde chaîne sur une machine séparée, de sorte que son profil de ressources et ses pannes soient isolés du paiement qui compte vraiment. L'auto-hébergement n'est pas un engagement tout-ou-rien, et les configurations pragmatiques ont généralement une chaîne bien faite et un repli manuel pour le reste.

Ce que cela coûte, face à ce que facture un prestataire

L'arithmétique est étonnamment facile à faire, parce qu'un paiement auto-hébergé a un coût fixe et aucun pourcentage. Un nœud Bitcoin élagué avec Lightning tient sur une offre à quelques dizaines de dollars par mois ; une boutique plus active qui veut de la marge se place un ou deux paliers au-dessus. Les paiements on-chain coûtent les frais de réseau, que le client paie, et les paiements Lightning coûtent des frais de routage mesurés en fractions de centime. Il n'y a aucune commission par transaction, aucun minimum mensuel, aucun délai de règlement et aucun palier de volume.

Face à cela, un prestataire crypto hébergé prend typiquement environ un pour cent de chaque transaction, et un prestataire carte prend environ deux et demi à trois pour cent plus un montant fixe par transaction. Pour mille dollars de chiffre d'affaires mensuel, un pour cent représente dix dollars — véritablement comparable au serveur, et l'auto-hébergement devient alors un choix neutre que vous feriez par principe plutôt que par calcul économique. Pour vingt mille dollars par mois, le prestataire prend deux cents dollars et le serveur coûte toujours les mêmes vingt dollars, et la décision se prend d'elle-même. Le point de bascule pour la plupart des boutiques se situe quelque part dans les petits milliers, et tout ce qui est au-dessus est de la marge.

Le coût qui n'apparaît pas sur la facture, c'est votre attention. Comptez un après-midi pour l'installation, une journée d'attente pour la chaîne, et quelque chose comme une heure par mois ensuite pour les mises à jour, les sauvegardes et un coup d'œil à la supervision — plus un après-midi désagréable par an, quand quelque chose casse au mauvais moment. Si votre taux horaire rend cela plus coûteux que les frais, la réponse honnête est de payer les frais. Personne ne devrait auto-héberger une pile de paiement par idéologie pendant que sa vraie activité attend.

Une réserve a sa place à côté de ce tableau, parce que l'omettre serait malhonnête. La comparaison suppose que vous êtes content de conserver ce que vous recevez. Si chaque paiement doit devenir du fiat sur un compte bancaire le jour même, vous avez réintroduit une plateforme d'échange dans le flux, et cette plateforme a ses propres frais, ses propres exigences d'identité et son propre pouvoir discrétionnaire. Auto-héberger le paiement supprime le prestataire. Cela ne supprime pas la banque, et les boutiques qui en tirent le meilleur parti sont celles qui conservent au moins une partie de leurs recettes dans la monnaie où elles ont été payées.

Quand vous ne devriez pas auto-héberger cela

Il existe des situations où la bonne réponse est de ne rien faire de tout cela, et un guide qui ne le dit jamais essaie de vous vendre quelque chose. Si votre volume mensuel est assez faible pour que le pourcentage d'un prestataire soit inférieur au coût du serveur, l'arithmétique ne fonctionne pas — commencez chez un prestataire hébergé, et migrez quand les chiffres se croisent. Si personne dans votre équipe n'est à l'aise devant une ligne de commande, ne faites pas du paiement l'endroit où cette compétence s'acquiert ; un point de paiement que vous ne pouvez pas déboguer est pire qu'un frais qui vous agace.

Si vous avez véritablement besoin d'un règlement fiat le jour même sur un compte bancaire, l'auto-hébergement résout la mauvaise moitié de votre problème. Le prestataire que vous essayez de supprimer est aussi ce qui effectue la conversion et le virement bancaire, et le remplacer signifie ajouter une plateforme d'échange qui demandera exactement les documents d'identité que vous cherchiez à éviter. Cela peut quand même valoir la peine pour les garanties de garde, mais soyez lucide : le KYC s'est déplacé, il n'a pas disparu.

Et si votre charge est irrégulière au point de rendre une interruption catastrophique — un lancement, un drop, une collecte de fonds avec une échéance — réfléchissez bien avant de faire votre premier déploiement auto-hébergé contre cette échéance. Faites-le tourner en parallèle de quelque chose d'autre pendant un cycle, faites-y transiter de vrais paiements à faible volume, et laissez-le faire ses preuves avant de lui confier le jour qui compte vraiment. Le déplacer plus tard est un problème résolu ; découvrir ses modes de défaillance pendant votre heure la plus chargée ne l'est pas.

Pour tous les autres — une boutique au chiffre d'affaires régulier, un opérateur à l'aise avec un terminal, une entreprise qui préférerait détenir ses propres clés plutôt que discuter avec un service des risques — c'est l'une des rares infrastructures auto-hébergées qui se rentabilise en argent sonnant plutôt qu'en principe. La pile est mature, le déploiement est un script, les modes de défaillance sont connus et documentés, et le seul véritablement impitoyable est la règle du retour en arrière Lightning en haut de cette page. Faites bien les choses sur ce point-là, et le reste est de l'administration système ordinaire.

Si vous voulez commencer, un serveur est provisionné en environ une minute, et la chaîne sera occupée à se synchroniser pendant que vous lisez le reste de la documentation. Choisissez une offre avec huit gigaoctets de mémoire si Lightning fait partie de vos projets, placez-la dans la juridiction où vous voudriez réellement qu'elle soit le jour où quelqu'un pose des questions gênantes, et payez-la avec la même monnaie que celle que vous vous apprêtez à commencer à accepter.