● articles / Marchand — back-office

Wallet view-only Monero : comment l'utiliser proprement pour encaisser

2026-05-04 · view-only · view key · marchand · freelance · OPSEC · POS

Tu encaisses des paiements XMR pour ton activité — boutique en ligne, freelance, restaurant. Tu veux que ton terminal de vente voie les paiements arriver pour confirmer la transaction au client. Mais tu ne veux pas que ce terminal puisse dépenser tes fonds — sinon une compromission du POS = vidage de ton wallet. La solution : le wallet view-only.

C’est quoi un view-only wallet

Un wallet Monero standard a deux clés cryptographiques :

• La spend key : permet de dépenser les fonds. C’est elle (combinée à la view key) qui donne contrôle total.
• La view key : permet de voir les transactions reçues, calculer le solde, mais pas de signer un envoi.

Un view-only wallet est un wallet qui contient uniquement la view key (ou la combinaison view key + adresse principale, sans la spend key). Il peut :

• Voir tous les paiements entrants sur le wallet et toutes ses subaddresses.
• Calculer le solde total.
• Générer de nouvelles subaddresses pour des invoices.

Il ne peut pas :

• Envoyer des fonds.
• Signer une transaction.
• Récupérer la spend key (pas mathématiquement possible).

Pour un marchand, c’est exactement ce qu’il faut : le terminal de vente, le serveur backend du site e-commerce, le tablet du POS, peuvent vérifier les paiements en temps réel sans aucun risque que leur compromission entraîne un vol des fonds.

Le setup canonique pour un marchand

Tu utilises deux wallets distincts :

1. Wallet “froid” (full) : sur un ordinateur séparé (idéalement air-gapped, ou hardware wallet). Contient la full seed (view + spend). C’est lui que tu utilises pour les retraits, les paiements à tes fournisseurs, le déplacement des fonds vers de l’épargne XMR ou la conversion en fiat. Ne touche jamais à ton terminal de vente.

2. Wallet “view-only” (sur le POS) : sur le terminal de vente, le serveur web du site, ou tout endroit qui doit voir les paiements arriver. Contient uniquement la view key. Si compromis, l’attaquant ne peut rien voler.

Les deux wallets voient les mêmes paiements (même solde affiché). Seul le froid peut dépenser.

Comment générer le view-only wallet

Étape 1 : récupérer la view key et l’adresse principale

Sur ton wallet froid (Feather, Cake, Monero CLI/GUI, etc.) :

Feather Wallet :

• Menu Wallet → View only wallet.
• Le wallet propose d’exporter un fichier .keys view-only ou de t’afficher la combinaison address + private view key.

Cake Wallet :

• Menu Settings → Backup → cherche View key.
• Tu obtiens : adresse principale (4...) + private view key (chaîne hex).

Monero CLI :

• Commande : viewkey puis address dans le wallet ouvert.
• Tu obtiens les deux valeurs.

Monero GUI :

• Settings → Wallet → bouton Show seed and keys.

Récupère :

• L’adresse principale du wallet (commence par 4).
• La private view key (longue chaîne hex).
• Optionnel : la restore height (numéro du bloc à partir duquel scanner — accélère la synchro initiale).

Étape 2 : créer le wallet view-only sur ton POS

Sur le terminal de vente :

Feather Wallet (recommandé pour POS desktop) :

• Create new wallet → Restore from view-only keys (ou équivalent dans la version récente).
• Colle l’adresse + la view key + le restore height.
• Le wallet synchronise et affiche le solde du wallet froid, vu depuis le froid.

Monero CLI (sur serveur Linux) :

• monero-wallet-cli --generate-from-view-key <fichier> --address <adresse> --viewkey <viewkey> --restore-height <height>.

MoneroPay / monerowp / Bitcart / AcceptXMR :

• Ces intégrations marchand acceptent en config : address + view_key + restore_height. Elles instancient un view-only wallet en interne et exposent une API pour vérifier les paiements arrivant sur les subaddresses générées par invoice. C’est le setup type pour un site e-commerce.

Étape 3 : vérifier que le view-only voit les paiements

• Envoie un petit montant (1-2€ équivalent XMR) depuis un autre wallet vers une subaddress du wallet froid.
• Vérifie que les deux wallets (froid et view-only) voient la transaction arriver et le solde se mettre à jour.
• Vérifie que tu peux dépenser depuis le froid, et que tu ne peux pas dépenser depuis le view-only (l’option Send doit être absente ou grisée).

Si tout fonctionne, ton setup est en place.

Génération de subaddresses depuis un view-only

Le view-only peut générer des nouvelles subaddresses pour ton wallet froid — à condition d’avoir aussi la public spend key importée (la plupart des outils marchand le font automatiquement à partir de l’adresse principale).

Concrètement, ton site e-commerce ou ton POS :

1. Reçoit une nouvelle commande.
2. Demande au view-only une nouvelle subaddress (via API ou interface).
3. Affiche cette subaddress (ou son QR) au client.
4. Surveille la blockchain via le view-only.
5. Quand le paiement arrive sur cette subaddress, marque la commande comme payée.

Tout cela sans jamais avoir besoin de la spend key.

OPSEC pour un setup view-only marchand

• Le wallet froid n’a aucune raison d’être en ligne. Il vit sur un ordinateur séparé, idéalement éteint la majorité du temps, allumé seulement pour les retraits.
• La view key reste sensible : elle révèle tous les flux entrants de ton activité (montants, fréquence, subaddresses). Un attaquant qui la vole ne peut pas dépenser, mais peut profiler ton business. Stocke-la avec soin sur le POS, ne la commit pas dans un repo Git, ne l’envoie pas en email.
• Sauvegarde de la full seed : la view key est dérivable de la seed. Si tu perds le froid mais tu as la seed, tu reconstitues tout. Sauvegarde la seed sur papier, hors du POS et hors du froid.
• Ne réutilise pas une subaddress entre deux clients. Génère une subaddress par invoice. C’est la base — voir article subaddresses.
• Restore height : utilise un restore height proche de la création du wallet froid pour éviter que le view-only scanne toute la blockchain Monero (plusieurs heures sinon).

Les pièges à éviter

• Confondre view key et spend key. Si tu mets la spend key sur ton POS, tout le bénéfice du view-only disparaît. Vérifie deux fois.
• Mettre la full seed sur le POS “pour simplifier”. Tu reviens au scénario où la compromission du POS = perte des fonds.
• Compter sur le view-only pour faire un retrait. Il ne peut pas. C’est le point.
• Oublier de sauvegarder la seed du froid. Si tu perds le froid sans seed, tu perds les fonds. Le view-only ne te sauve pas.

Outils Monero-native qui exploitent le pattern view-only

Les solutions POS et e-commerce Monero-native utilisent toutes ce pattern :

• MoneroPay (self-hosted, API HTTP).
• AcceptXMR (lib Rust, pour intégration custom).
• monerowp (plugin WooCommerce).
• XMRetail (POS physique).
• Monero SuperPay (POS + e-commerce).
• Bitcart (multi-coin Monero-native).

Tu leur fournis adresse + view key, ils gèrent le reste. Pour la comparaison de ces outils, voir le profil Marchand / Freelance (articles dédiés à venir).

En résumé

Le pattern : le froid signe les sorties rares, le view-only voit les entrées fréquentes. Compromission de l’élément exposé (le POS) = aucune perte de fonds. C’est exactement la bonne posture pour un marchand sérieux, et Monero la rend triviale à mettre en place.

Sources : documentation getmonero.org sur les view-only wallets, MoneroPay, AcceptXMR, monerowp.

● profils liés

• D. Marchand / Freelance

← Tous les articles ↻ Refaire le diagnostic