Chaque processeur de paiement au milieu arrive avec ses conditions, son KYC et son bouton qui gèle votre solde. BTCPay Server supprime le milieu. Les factures sont créées sur votre serveur, le client paie à une adresse dérivée de votre portefeuille, et votre propre nœud Bitcoin confirme le paiement. Personne d'autre que vous ne peut l'éteindre.
C'est pour les boutiques, les freelances et les services qui acceptent déjà le bitcoin — ou veulent le faire — et préfèrent ne pas confier ce travail à une entreprise.
Quelle offre
BTCPay tourne sous forme d'environ sept conteneurs : l'application BTCPay, NBXplorer (qui surveille la chaîne), Bitcoin Core, Postgres et un nginx en façade avec Let's Encrypt automatique. Sur notre serveur de test, ils utilisaient environ 0,7 Go de RAM au départ, et Bitcoin Core en prend davantage pendant la synchronisation ; 4 Go suffisent largement. La vraie contrainte, c'est le disque, pas la mémoire.
| Configuration | Offre |
|---|---|
| BTC on-chain, nœud élagué gardant ~5 Go de blocs | Small-IP — 4 vCPU, 4 Go, 35 Go (16 $/mois) |
| La même chose, avec plus de marge pour les logs et les mises à jour | Medium-IP — 6 vCPU, 6 Go, 45 Go (20 $/mois) |
| Lightning, une plus grande fenêtre de blocs ou une deuxième crypto | Pro-32 — 8 vCPU, 32 Go, 400 Go (40 $/mois), sur demande |
Il vous faut une offre avec sa propre IPv4 : les clients joignent BTCPay en HTTPS, et Let's Encrypt doit atteindre le port 80. Choisissez l'Allemagne ou la Finlande, selon ce qui est disponible à la commande — pour une page de paiement, la latence compte à peine. Et puisque tout l'intérêt est d'accepter la crypto, il est logique que le serveur lui-même se paie en crypto, sans KYC.
Installation
Pointez pay.example.com vers le serveur, puis, en root sur un Ubuntu 24.04 ou Debian 12 tout neuf :
mkdir BTCPayServer && cd BTCPayServer
git clone https://github.com/btcpayserver/btcpayserver-docker
cd btcpayserver-docker
export BTCPAY_HOST="pay.example.com"
export LETSENCRYPT_EMAIL="you@yourdomain.com"
export NBITCOIN_NETWORK="mainnet"
export BTCPAYGEN_CRYPTO1="btc"
export BTCPAYGEN_ADDITIONAL_FRAGMENTS="opt-save-storage-xxs"
export BTCPAYGEN_REVERSEPROXY="nginx"
export BTCPAYGEN_LIGHTNING="none"
. ./btcpay-setup.sh -i
C'est opt-save-storage-xxs qui permet de tout faire tenir : Bitcoin Core élague jusqu'à 5 Go de blocs. Le script récupère les images, crée un service systemd btcpayserver et démarre le tout. Au passage, il redémarre aussi le démon Docker — une raison de plus de donner à BTCPay son propre serveur plutôt que de le caser à côté d'autres conteneurs.
Vérifiez le nœud :
bitcoin-cli.sh getblockchaininfo
Comparez blocks à headers, et vérifiez "pruned": true. Après vingt minutes de test, nous en étions à environ 218 000 blocs sur à peu près 972 000 — les premiers sont minuscules, n'extrapolez donc pas. Le vrai travail vient plus tard.
Première connexion : faites-la tout de suite
Ouvrez https://pay.example.com dès qu'il répond. BTCPay vous envoie sur une page d'inscription, et le premier compte devient administrateur du serveur. Si quelqu'un d'autre trouve la page avant vous, votre serveur de paiement est à lui. Inscrivez-vous, puis allez dans Server Settings → Policies et réglez les nouvelles inscriptions comme vous le souhaitez.
Créez ensuite une boutique et connectez votre portefeuille par sa clé publique étendue (xpub) — depuis un portefeuille matériel ou l'export de votre portefeuille de bureau. BTCPay dérive une nouvelle adresse pour chaque facture et ne voit jamais de clé privée. Utilisez pour cela un nouveau portefeuille ou un nouveau compte plutôt qu'un portefeuille avec des années d'historique : un nœud élagué préfère suivre ce qui se passe à partir de maintenant.
Tant que le nœud n'a pas rattrapé le réseau, BTCPay indique qu'il est en cours de synchronisation et ne surveille pas les paiements. Prévoyez le lancement après la synchronisation, pas le soir de l'installation.
À savoir avant la mise en service
- La première synchronisation est longue. Un nœud élagué télécharge et vérifie quand même toute la chaîne — plus de 700 Go — avant de pouvoir jeter les anciens blocs. Le trafic est illimité à 1 Gbit/s sur nos offres, donc cela ne coûte rien de plus, mais sur un serveur à 4 vCPU, comptez en jours. Le dépôt contient un script de synchronisation rapide ; il saute ce travail en faisant confiance à la copie de l'ensemble UTXO de quelqu'un d'autre, ce qui retire une partie de l'intérêt de faire tourner votre propre nœud.
- Mises à jour.
btcpay-update.shrécupère la dernière version de BTCPay et ses dépendances. Lancez-le à une heure calme, pas en pleine période de soldes. - Quoi sauvegarder. Avec un portefeuille en xpub seul, vos coins ne sont pas sur le serveur. Ce que vous perdriez, ce sont la configuration de la boutique et l'historique des factures dans Postgres — sauvegardez ce volume, et gardez la seed de votre portefeuille dans un endroit sans aucun rapport avec ce serveur.
- Lightning plus tard. Commencez on-chain. Lightning, c'est une plus grande fenêtre de blocs, la gestion des canaux et de la liquidité entrante — un projet à part entière, et une offre Pro que nous mettons en place sur demande.
Mon avis : pour une petite boutique qui reçoit du bitcoin une fois par jour, BTCPay sur Small-IP est la configuration la plus propre qui soit. Si vous avez besoin de paiements par carte ou de versements en monnaie fiduciaire, ce n'est pas l'outil qu'il vous faut.
Sur le même sujet
- Faire tourner son propre nœud Bitcoin sur un VPS — le nœud seul, si vous voulez seulement vérifier votre portefeuille
- Faire tourner son propre nœud Monero sur un VPS
- Crypto VPS — payer ses serveurs en crypto
- VPS pour un site web sur sa propre IP — la boutique qui envoie les clients vers BTCPay
- Configurer un pare-feu ufw
Commentaires
Pas encore de commentaires. Soyez le premier.