Bitcoin Payment Processor crée des demandes de paiement, rattache les paiements reçus aux commandes et facilite leur suivi documentaire. Il peut être auto-hébergé ou fourni comme service. Ce n’est pas une règle du consensus Bitcoin, et le terme processeur n’indique pas qui contrôle les fonds.
La boutique crée une commande et son serveur demande au processeur une facture indiquant montant et devise. Il conserve le lien entre le numéro interne de commande et l’identifiant de facture. Le client reçoit une page de paiement ou un code QR, et le processeur surveille la réception. Sans ce lien, il est impossible de déterminer avec fiabilité quelle commande est réglée ; le simple retour dans le navigateur ne prouve pas le paiement. [BTCPay Server — eCommerce integration]
BTCPay Server peut dériver les adresses de réception à partir des données publiques d’un portefeuille existant, sans sa clé privée. Cela diffère d’un portefeuille à chaud stocké sur le serveur et de l’accès aux fonds d’un nœud Lightning. Un prestataire peut garder les fonds jusqu’au versement. Examinez la possession réelle des clés, les permissions et la possibilité de retrait, plutôt que le seul nom du produit ou le terme non-custodial. [BTCPay Server — General FAQ] [BitPay — Configuring settlements]
Une facture habituelle de BTCPay Server fixe le taux de change pour une durée limitée. Son expiration n’empêche pas l’arrivée d’un transfert ultérieur. Les paiements insuffisants, excessifs et tardifs ont des états différents et demandent un traitement adapté. Conservez le montant initial et le taux appliqué ; si le prix change, une nouvelle demande peut porter sur un nombre différent de satoshis. [BTCPay Server — Invoice lifecycle]
BTCPay Server distingue Processing, en attente des confirmations configurées, de Settled ; les paiements Lightning réussis passent à Settled sans attendre de bloc. Les noms d’état des autres prestataires ne sont pas automatiquement équivalents : BitPay avertit explicitement que paid ne garantit pas le paiement. La boutique doit définir une règle de délivrance pour chaque état et mode de paiement concernés. Modifier manuellement un état ne crée aucune confirmation du réseau. [BTCPay Server — Invoice lifecycle] [BitPay — Invoice webhooks]
BTCPay vérifie un webhook par HMAC-SHA256 sur les octets originaux du corps et un secret partagé. BitPay décrit des IPN non signées : la notification déclenche une interrogation du statut de facture par API, sans constituer elle-même une preuve fiable. Les notifications peuvent se répéter. L’intégration doit donc reconnaître sûrement un événement redélivré et empêcher une seconde expédition de la même commande ; après une interruption, les états enregistrés doivent être rapprochés de ceux du processeur. [BTCPay Server — Webhook validation example] [BitPay — Invoice webhooks]
La confirmation du paiement client ne coïncide pas nécessairement avec le versement du prestataire. BitPay permet de configurer la devise de règlement et un compte bancaire ou une adresse de cryptomonnaie ; une modification peut exiger une approbation. Vérifiez devises disponibles, limites, délais, frais et contrôle des fonds avant versement. La réception directe dans votre portefeuille n’utilise pas automatiquement ce modèle de versement par un prestataire. [BitPay — Configuring settlements] [BTCPay Server — General FAQ]
Un remboursement exige un nouveau versement et la vérification du destinataire ; il ne modifie pas la transaction bitcoin initiale. Séparez la réclamation portant sur la commande, la décision concernant le montant remboursé et l’envoi effectif des fonds. Conservez les liens commande–facture–paiement, taux de change, frais et remboursements. L’export d’un rapport facilite le suivi, mais ne règle à lui seul ni toutes les obligations comptables locales ni un litige de livraison. Même un transfert confirmé ne règle pas à lui seul le caractère juridiquement définitif de l’opération : vérifiez réclamations, éventuels mécanismes de chargeback et obligations selon le circuit de paiement, le contrat et la juridiction. [BTCPay Server — Refunds] [BTCPay Server — Reporting] [BitPay — Merchant and shopper terms]
Testez les paiements réussis, incomplets, tardifs et notifiés plusieurs fois, ainsi que la reprise après interruption. Accordez à la clé API uniquement les permissions nécessaires et limitez-la à la boutique concernée. Ne placez pas de données client inutiles dans les métadonnées. Prévoyez hébergement, mises à jour, liquidité et assistance ; un logiciel gratuit n’implique pas une exploitation sans coûts. Disponibilité du service, garde des clés et correction de l’intégration sont des conditions distinctes. [BTCPay Server — eCommerce integration] [BTCPay Server — Lightning operations]
La même notification n’est pas un nouvel achat
Dans une intégration fictive, la commande OBJ-101 conserve son identifiant de facture. Une fois le règlement vérifié, le système crée une seule expédition. Si une notification répétée du même événement arrive ensuite, il la rattache à la commande déjà exécutée et ne crée aucune nouvelle expédition. Le simple affichage d’une page de remerciement ne doit pas déclencher cette transition.
Pour une vision complète, lisez aussi BTCPay Server, Bitcoin Point of Sale, Merchant Adoption, Lightning Network, Bitcoin. Cette entrée est également citée par Alza Bitcoin payments, Merchant Adoption, BTCPay Server, Bitcoin Point of Sale.
01Tous les processeurs de paiements gardent-ils mes bitcoins ?+
Non. Certaines solutions créent seulement des demandes et surveillent la réception dans votre portefeuille, tandis que d’autres gèrent les fonds jusqu’au versement. Un même logiciel peut même employer plusieurs modèles de portefeuille. Ce sont les clés, les permissions et le flux réel des fonds qui comptent, pas la seule appellation processeur.
02Une boutique peut-elle expédier lorsque le client revient de la page de paiement ?+
Le retour seul ne suffit pas. La boutique doit vérifier la facture correspondante et son état selon la procédure du processeur. Les notifications sont vérifiées conformément à la documentation et leur répétition ne doit pas déclencher une nouvelle exécution. La remise des biens suit les conditions choisies pour confirmer le paiement.