Bitcoin Point of Sale est une interface de caisse pour la vente en personne : elle chiffre l'achat, crée une demande de paiement, associe le paiement reçu et conserve une trace. Elle peut fonctionner sur téléphone, tablette ou terminal ; l'apparence de l'appareil ne détermine pas qui contrôle les fonds.
Le personnel sélectionne les produits ou saisit un montant, puis vérifie devise, pourboire et total. BTCPay Server propose catalogue, panier et clavier numérique. Chaque achat doit être traçable par une commande et une facture ; rouvrir l'écran ne doit pas créer un second enregistrement de vente. [BTCPay Server — Point of Sale app] [BTCPay Server — Invoice lifecycle]
Le prix en monnaie locale est converti selon la source de taux configurée ; la caisse doit afficher le montant attendu en bitcoin et la validité de l'offre. BOLT 11 contient les données de la facture Lightning, notamment le hash de paiement et l'expiration ; le montant peut être facultatif. Pour un achat précis, il faut vérifier montant réel, réseau et destinataire. Calculer le prix ne signifie pas vendre du bitcoin contre une monnaie fiduciaire. [BTCPay Server — Store rates and policies] [Lightning BOLTs — Invoice protocol]
Le code QR transmet seulement des données de paiement. Une capture d'écran du client ne remplace pas l'état dans le système du commerçant. Dans BTCPay Server, Processing attend les confirmations on-chain choisies ; Settled indique que la politique est satisfaite, mais peut aussi être défini manuellement. Un paiement Lightning réussi n'attend pas de confirmation de bloc. La remise du produit repose donc sur un paiement vérifié, pas seulement sur la couleur d'un écran. [BTCPay Server — Invoice lifecycle]
La même tablette peut diriger les recettes vers un portefeuille propre ou utiliser un prestataire dépositaire. Les clés, autorisations et conditions de versement comptent, pas le logo Bitcoin. Même la réception via une clé publique n'exclut pas qu'une caisse ou un serveur compromis substitue une future adresse. Séparez les droits du personnel de ceux permettant de changer le destinataire, gérer le portefeuille ou approuver les remboursements. [BTCPay Server — Wallet setup] [BTCPay Server — Third-party hosting risks] [BTCPay Server — Lightning setup]
Un nœud Lightning propre exige exploitation, canaux et liquidité entrante. Un prestataire peut prendre en charge une partie du travail, mais modifie coûts et confiance. Un échec de routage ou un manque de liquidité n'est pas un paiement réussi. Avant de changer de moyen de paiement, le personnel vérifie le résultat de la tentative initiale pour éviter deux paiements pour un achat. [BTCPay Server — Lightning setup] [Lightning BOLTs — Invoice protocol]
L'indisponibilité d'internet, du backend ou de la source de taux peut empêcher une nouvelle demande ou la vérification de réception. Un code affiché ou imprimé peut rester lisible sans état à jour. La procédure doit prévoir connexion de secours, report de vente et recherche ultérieure du paiement. Examinez séparément sous-paiements, trop-perçus et paiements après expiration ; modifier manuellement un état ne change pas l'historique du réseau. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies]
Rendre des fonds nécessite un lien avec l'achat initial, un montant et une devise convenus, une destination vérifiée et une approbation autorisée. BTCPay Server sépare la création d'une demande de remboursement de l'envoi du versement. Le transfert initial n'est pas effacé. Le personnel doit distinguer demande créée, versement en attente et remboursement effectivement terminé. [BTCPay Server — Refund workflow]
À la fin du service, rapprochez commandes, paiements reçus, frais, remboursements et éventuels versements du prestataire. BTCPay Server exporte des rapports de paiements, produits vendus et portefeuille on-chain ; un export seul ne garantit pas le respect des obligations comptables et fiscales locales. Testez les procédures du personnel, les pannes et la restauration, limitez l'accès aux données clients et prévoyez les coûts de matériel, de connexion et d'exploitation. [BTCPay Server — Reporting] [BTCPay Server — Point of Sale app] [BTCPay Server — Third-party hosting risks]
Deux écrans, un achat
Pour la commande fictive POS-497, le client montre un paiement réussi, mais la tablette du personnel perd sa connexion. Le personnel ne marque pas automatiquement l'achat comme impayé et n'émet pas aussitôt une deuxième demande. Il rétablit la connexion, retrouve la facture initiale et vérifie son montant et la réception réelle. Ensuite seulement, il décide de remettre les produits ou de réessayer et consigne le résultat dans la même commande.
Pour une vision complète, lisez aussi Merchant Adoption, BTCPay Server, Bitcoin Payment Processor, BOLT 11, Confirmation, Bitcoin. Cette entrée est également citée par Merchant Adoption, Bitcoin Payment Processor, BTCPay Server, BTC Map.
01Un code QR suffit-il à la caisse ?+
Le code transmet les données de paiement, mais ne vérifie pas lui-même la réception et n'associe pas le paiement à l'achat. La caisse a besoin d'un état fiable et d'une procédure pour les montants incorrects, l'expiration et la perte de connexion.
02Un paiement Lightning implique-t-il toujours que le commerçant garde lui-même les fonds ?+
Non. La caisse peut utiliser son propre nœud, un autre modèle de service ou un prestataire dépositaire. Vérifiez qui contrôle les clés et le solde, qui assure la réception et à quelles conditions les fonds peuvent être retirés.