Documentation

• Ubuntu 22.04+ ou Debian 12+ ; Mint 21+ et Pop!_OS 22+.
• Fedora 42+ ; Rocky, AlmaLinux, RHEL, Oracle Linux ou CentOS Stream 9–10.
• openSUSE Leap 16+ ou Tumbleweed ; Arch, Manjaro ou EndeavourOS.

Choisis une version encore maintenue par son éditeur. Les exigences supérieures du système d'exploitation priment : openSUSE Leap 16 demande plus de 40 GB d'espace disque.

Davantage de blockchains et de factures simultanées peuvent demander plus de CPU et de RAM. Un VPS plus puissant ne supprime pas les quotas RPC. Les parcours d'installation ont des tests automatisés ; les tests complets sur VPS neufs ne sont pas encore terminés pour toutes les distributions.

Examiner l'installateur. Ajoute --check à la commande pour vérifier la compatibilité sans installer, ou --help pour les options.

Reprends l'installation enregistrée sans remplacer les clés ni les réglages :

bash <(curl -fsSL https://releases.whollycrypto.com/setup_wholly.sh) --resume

D'autres domaines de base peuvent utiliser les mêmes noms de services. Les éventuels enregistrements IPv6 doivent aussi pointer vers ce VPS. N'active un proxy Cloudflare qu'après la validation du domaine.

Les nouveaux montants calculés pour les stablecoins reconnus sont arrondis au supérieur : 1.321 USDC → 1.33 USDC, même avec une tolérance nulle. Minimum : 0.01 token.

Les factures existantes, les soldes et les reliquats de paiements partiels restent exacts. Les autres tokens, y compris les tokens personnalisés, gardent leur précision habituelle.

Tes identifiants Basic Auth sont enregistrés dans /root/whollycrypto/config/setup-credentials.txt. Ils sont distincts de l'e-mail et du mot de passe de la console.

Les nouveaux projets héritent des réglages système de devise et de fuseau horaire par défaut; les magasins utilisent la devise du projet. Les fuseaux horaires des comptes existants se gèrent séparément dans Réglages → Compte.

whollycrypto welcome affiche l'URL de ta console.

1. Les nœuds, taux, domaines, crédits d'installation et mises à jour partagés se gèrent dans le Panneau opérateur.
2. Ouvre Portefeuilles → Créer des portefeuilles de réception pour BTC, ETH et USDC/USDT sur Ethereum. Sauvegarde les deux phrases de récupération indépendantes. Ce projet dédié ne peut pas émettre de factures de vente ; un magasin de réception existant est conservé.
3. Ajoute un commerçant avec une devise de crédit, des frais et l'e-mail de l'administrateur. Partage l'invitation et les identifiants Basic Auth du commerçant en privé. Il choisit son mot de passe. Ne partage jamais les identifiants Basic Auth de l'opérateur.
4. Les commerçants rechargent via ta page de paiement, ou tu enregistres un ajustement de crédit motivé. Du crédit est nécessaire avant de créer des projets ou des magasins. Gère les utilisateurs et l'historique des crédits dans Commerçants → Gérer.

La configuration opérateur demande une quatrième adresse, par exemple operator.example.com, ainsi que ses propres identifiants Basic Auth. Choisis ton libellé, fais pointer le DNS vers le VPS, vérifie le DNS et active HTTPS. Le panneau s'ouvre directement à cette adresse. Tes adresses commerçant, paiement et API restent distinctes.

Utilise les nouveaux identifiants Basic Auth de l'opérateur, puis ton e-mail et ton mot de passe administrateur. Les identifiants Basic Auth du commerçant ne changent pas. L'installation peut reprendre après une erreur DNS ou de certificat. Les opérateurs qui mettent à jour depuis la version 7.0.0 effectuent aussi cette étape ; les adresses déjà en service restent disponibles.

À 3 %, une facture de 100 EUR coûte 3 EUR de crédit au commerçant. Si la devise de son crédit est différente, le taux fiat au moment de la création est enregistré avec les frais.

L'opérateur paie séparément les frais habituels de l'installation Wholly Crypto. Les fonds des clients ne sont pas partagés sur la blockchain. Les achats de crédits ne sont pas facturés une seconde fois.

Seul un règlement vérifié automatiquement crédite une recharge. Ouvrir une page de paiement ou accepter une facture manuellement ne suffit pas. Les annulations créent des écritures dans le registre ; une recharge annulée qui réapparaît nécessite une vérification par l'opérateur.

Un faible crédit hébergé suspend les IPN, webhooks, sweeps et la création de projets ou magasins. Les factures clients existantes et la réception continuent. Un faible crédit d'installation peut suspendre l'automatisation de tous les commerces hébergés. Désactiver un commerçant bloque aussi sa connexion et les nouvelles factures, mais les anciens paiements restent surveillés.

Il s'agit d'une isolation au niveau de l'application, pas d'un VPS distinct pour chaque commerçant. Les commerçants n'ont pas accès aux projets, portefeuilles, identifiants API, plateformes d'échange ou crédits des autres. L'administrateur du serveur peut accéder aux clés des portefeuilles en ligne hébergés. Informe les commerçants avant leur inscription ; utilise un hébergement de confiance, des sauvegardes indépendantes et des ressources adaptées aux charges partagées.

À partir de la version 7.2.0, Portefeuilles gère les soldes reçus, les adresses et les sauvegardes ; Sweep gère les envois et les règles automatiques. Garde de l'ETH pour les frais des tokens. Recharges des commerçants suit leurs achats. Les crédits de l'en-tête paient séparément les frais d'installation. Mon commerce ouvre ta propre console dans un nouvel onglet.

Ouvre Finances pour les frais perçus, les débits d'installation vérifiés, la marge estimée et les crédits actuels des commerçants. Filtre par date, commerçant ou devise du rapport ; exporte en CSV.

Les rapports regroupent les factures par premier règlement et reflètent les dernières annulations de frais. Les soldes prépayés ne sont pas du chiffre d'affaires. Les frais de ton propre commerce restent distincts. Des débits en attente ou des taux manquants rendent les marges concernées indisponibles. Les montants convertis utilisent les taux fiat actuels en cache ; le gas et les coûts d'exploitation ne sont pas inclus.

Ajouter un commerçant crée une invitation. À partir de la version 7.3.0, choisis un crédit de départ offert dans la devise de crédit du commerçant ; zéro est autorisé. Cela ne recharge pas ton solde opérateur. Envoyer l'invitation par e-mail est coché par défaut.

Configure ton fournisseur SMTP dans Réglages → E-mail d'invitation d'abord, avec TLS ou STARTTLS. Le test de connexion n'envoie aucun e-mail. Sinon, décoche l'e-mail et partage le lien en privé. Un échec d'envoi conserve le compte et le crédit ; ne crée pas le commerçant une seconde fois.

Pour obtenir un autre lien ou réinitialiser un mot de passe, ouvre Commerçants → Gérer → Comptes utilisateurs. L'acceptation SMTP ne garantit pas la livraison en boîte de réception. Partage séparément les identifiants Basic Auth du commerçant, jamais ceux de l'opérateur.

Les invitations durent 48 heures ; les liens de réinitialisation, une heure. Chacun ne fonctionne qu'une fois. Remplace ou révoque un lien depuis le même écran. Une réinitialisation ferme les sessions existantes mais laisse la 2FA activée. Les identifiants Basic Auth du commerçant restent nécessaires.

Crée des comptes directement avec un mot de passe ou envoie des invitations. Gère les utilisateurs, projets, magasins, frais et crédits prépayés locaux ; consulte les rapports et abonne-toi aux événements de cycle de vie signés. Le consentement à la garde des fonds à la première connexion, la 2FA et l'isolation des clients restent en place.

Chaque écriture nécessite une clé d'idempotence enregistrée. Les crédits accordés sont des ajustements de compte locaux, pas des recharges d'installation. Les secrets des portefeuilles, les envois de fonds et la configuration du serveur restent hors de cette API.

Utilise api.your-domain.com/v1/operator. Garde les clés opérateur sur ton backend, jamais dans un navigateur ni chez un commerçant hébergé.

Réglages → Carnet d'adresses: enregistre une blockchain et une adresse. Les monnaies natives et les tokens reconnus par CoinGecko apparaissent automatiquement. Lecture seule, gestion par l'administrateur ; les moyens de paiement acceptés ne changent pas.

La lecture des tokens couvre 22 blockchains. Les soldes privés et les couches Bitcoin/CashTokens/Kaspa nécessitent des accès ou des indexeurs distincts. Un échec de lecture affiche une erreur, pas un zéro.

Regroupe les soldes des factures dans un autre portefeuille avec des envois manuels ou des sweeps automatiques. Les transferts de tokens nécessitent aussi la monnaie native de la blockchain pour les frais.

Prix indisponible concerne les taux, pas les soldes.

1. Magasin → Moyens de paiement → EVM ou Solana → Token personnalisé.
2. Saisis le contrat/mint, le nom et le symbole. Choisis un prix fixe en USD ou un prix automatique via DEX.

Le réseau et les décimales sont vérifiés. Les prix du projet ne modifient pas les montants déjà calculés. Une correspondance dans le catalogue ne suffit pas à activer le paiement.

Prix automatiques

DEX Screener exige un pool correspondant au contrat exact, $10,000 de liquidité et un échange dans l'heure. Les taux s'actualisent chaque minute ; un échec ou un taux vieux de cinq minutes bloque les nouveaux calculs de montant.

Les prix DEX peuvent être manipulés ; les contrôles ne sont pas des audits. Utilise des tokens ERC-20 standard ou SPL classiques de confiance. Token-2022 et ses extensions ne sont pas pris en charge. Sans pool adapté, utilise un prix fixe.

Scanner hors ligne ? Les factures gardent les moyens configurés pendant que la détection attend. Vérifie les API prises en charge dans Connexions blockchain ; un fournisseur opérationnel n'est pas forcément compatible avec le scanner. Par défaut : deux fournisseurs indépendants.

Les portefeuilles et les taux restent nécessaires. Les services Monero/Lightning doivent émettre les demandes de paiement.

Les erreurs API/MCP incluent error.details.payment_methods. Le SDK 2.4.0 ajoute des explications sûres : PHP getPaymentMethodIssues(), Python payment_method_issues, Node paymentMethodIssues. Référence des erreurs →

Les montants crypto sont arrondis au supérieur et incluent le spread du magasin. Une facture libellée en fiat ne convertit pas les cryptos reçues en solde bancaire.

Avec zéro confirmation, le règlement est validé dès la détection, sans la protection des confirmations réseau. Les paiements EVM natifs sont détectés comme transferts directs. Examine les paiements inhabituels ou incertains dans À vérifier.

Bloquées par défaut. Active Magasins → Facture → Autoriser les factures de montant nul pour autoriser les totaux nuls manuels ou via API. Ces factures se terminent immédiatement, sans paiement, adresse de réception, transaction ni frais de traitement.

status est l'état de la facture à la création de l'événement ; event_type indique ce qui s'est passé.

• Exemple Ethereum : payment.received + processing, puis invoice.settled + settled.
• Exemple Solana : déjà définitif à la détection, donc payment.received et invoice.settled portent tous deux settled.

Les deux parcours peuvent se produire sur d'autres blockchains. Ce sont des événements distincts, pas forcément deux paiements. Ils peuvent partager sequence mais avoir des valeurs différentes pour event_id . L'ordre de livraison n'est pas garanti ; n'exige pas que processing arrive en premier.

Événements : invoice.created, payment.received, invoice.processing, invoice.settled, invoice.expired, invoice.invalid, invoice.cancelled. Table complète des événements et règles d'exception →

amount_status: none, partial, paid, overpaid. paid inclut la tolérance, pas la finalité. timing_status: on_time ou late. resolution: automatic, manually_settled ou manually_invalidated. Applique ta politique d'exception lorsque requires_review vaut true.

invoice_id correspond à la réponse API. amount, currency et order_id décrivent ta commande d'origine. payment_info ajoute les transferts, les montants crypto exacts, le taux/spread/la tolérance verrouillés et les taux indicatifs. Les données clients et les métadonnées sont privées.

paid_chain, paid_asset, paid_payment_method_id, paid_asset_amount, paid_asset_amount_received et settlement_exchange_rate résument le règlement. Ils restent figés ; les preuves ou l'historique manquants restent null. Pour les reçus ultérieurs, utilise payment_info ou l' API des paiements.

Utilise des chaînes décimales. Ne combine jamais des actifs différents et ne considère pas des fonds non confirmés comme absents. Traite les exceptions explicitement ; un avertissement seul n'autorise jamais l'exécution ni le remboursement. Les recharges internes de gas vérifiées ne sont pas des paiements clients et ne déclenchent pas payment.received.

Secrets de signature distincts : Magasin → IPN signe les livraisons IPN, y compris le champ personnalisé d'une facture ipn_url. Chaque endpoint dans Magasin → Webhooks a son propre secret, affiché lors de sa création ou de sa rotation.

Les deux utilisent Wholly-Signature et le même vérificateur SDK, mais nécessitent le secret correspondant, pas une clé API. La rotation du secret IPN ne modifie pas les secrets des webhooks.

Vérifie le corps brut, l'horodatage et le périmètre projet/magasin. Enregistre durablement, puis renvoie HTTP 2xx. Un worker vérifie la facture actuelle via ton hôte API configuré et exécute la commande une seule fois dans une transaction de base de données. Les en-têtes ne sont pas signés ; utilise l'identité du corps signé de la version 2.

Par événements : déduplique la valeur signée event_id, puis filtre invoice.settled. SDK basé sur l'état : regroupe par projet + invoice_id + sequence, puis vérifie l'état quel que soit le type d'événement. N'ajoute pas de filtre d'événements après ce regroupement. Les deux approches nécessitent une protection distincte contre les doublons au niveau de la commande.

Les nouvelles tentatives conservent le corps et l'identifiant d'événement d'origine. Les anciennes révisions ne doivent pas écraser les plus récentes. L'IPN fait jusqu'à huit tentatives ; celles des webhooks sont facultatives. Un faible crédit suspend les livraisons, pas les paiements.

Magasin → IPN / Webhooks → Historique → Détails affiche le corps enregistré et le résultat. Les payloads expirent après 90 jours. Un renvoi ne prouve pas le règlement.

1. Réglages → Plateformes d'échange : connecte une clé dédiée, vérifie les soldes et autorise les projets. Aucun droit de retrait ; limite la clé à l'IP de ton VPS.
2. Projet → Sweep : vérifie l'actif, le réseau, l'adresse et le contrat du token. Pour chaque blockchain/token, choisis un autre portefeuille ou une plateforme d'échange.

Les marchés s'actualisent toutes les deux minutes. Seuls les dépôts rapprochés et crédités peuvent être convertis ; des marchés périmés bloquent les nouveaux ordres. Une réserve de 1 % de l'actif source reste sur la plateforme pour les frais et arrondis, séparément des crédits de traitement.

Conserver un montant minimum réserve des monnaies/tokens à l'échelle du projet après les sweeps automatiques. Ce réglage est distinct du seuil de déclenchement ; zéro ne conserve rien. Les frais utilisent l'excédent. Les envois manuels ne changent pas.

Reprends les transferts incertains ; ne les remplace jamais. Les portefeuilles restent réservés jusqu'à confirmation ou expiration d'un devis inutilisé. Les gros sweeps nécessitent plusieurs lots.

La garde par la plateforme, le KYC, les limites régionales et les frais s'appliquent. Aucun versement bancaire ni effet de levier. Un faible crédit suspend les nouvelles conversions ; les ordres déjà soumis continuent d'être rapprochés.

Ouvre Recharge automatique après Demandes. Choisis un portefeuille de réception sauvegardé, un seuil, un montant d'achat, une limite quotidienne et un plafond de frais réseau. Autorise et enregistre. L'option est désactivée au départ.

Utilise BTC, ETH ou USDC/USDT sur Ethereum lorsqu'ils sont proposés. Les adresses qui envoient des tokens ont besoin d'ETH ; cette règle ne finance pas le gas manquant. Les opérateurs utilisent des portefeuilles de réception dédiés ; les commerçants hébergés paient leur opérateur.

La recharge approuvée peut s'exécuter même si un faible crédit suspend Sweep. Seul le service destinataire confirme le crédit. Un seul achat automatique s'exécute à la fois. La désactivation arrête les opérations non envoyées, pas les transactions déjà soumises.

Dans Recharge automatique, utilise Vérifier le paiement. Reprends le même paiement valide, ou clos un transfert Ethereum dont l'échec est vérifié et suspends la règle. Les paiements en attente ou incertains restent bloqués pour éviter un double envoi. Un devis expiré ne prouve pas un échec.

Le taux par défaut de 1 % utilise la valeur fiat d'origine de la facture réglée. Les paiements crypto des clients ne sont pas partagés.

Les frais continuent de s'accumuler et le solde devient négatif. Règle le montant négatif et rétablis un crédit utilisable au-dessus du seuil de tolérance de ton compte. Les changements de solde apparaissent normalement sous 10–15 secondes avec une connexion fonctionnelle.

L'installation des mises à jour nécessite un crédit vérifié supérieur à zéro, même avec une tolérance pour l'automatisation. Les recharges n'installent jamais automatiquement les mises à jour.

Les notifications suspendues ne consomment aucune tentative. Les livraisons conservées reprennent ; leur expiration habituelle s'applique toujours. Rapproche les événements manqués via l'API des factures.

Si l'opérateur désactive les frais de traitement, aucun nouveau frais de traitement ni restriction de crédit ne s'applique. Les anciens débits restent dans l'historique. Une installation non associée peut configurer des projets et magasins, mais nécessite une facturation vérifiée pour émettre des factures. Les factures déjà émises restent surveillées.

• Les revenus affichent les montants des factures réglées avant frais et remboursements, selon les dates de règlement. Ce n'est ni le solde du portefeuille ni le bénéfice.
• Les conversions utilisent les taux actuels en cache, pas des taux comptables historiques. Les totaux en devise d'origine restent disponibles si des taux manquent.
• Les graphiques de statut des factures utilisent les dates de création. Les chiffres À vérifier montrent les problèmes actuellement non résolus.

BTC, EVM, SOL et TRX sont complétés par 18 adaptateurs natifs. Utilise un fournisseur capable de soumettre des transactions. ZEC est limité aux adresses transparentes ; ADA conserve les sorties contenant des tokens ; DOT utilise Asset Hub ; HBAR nécessite un relais. Les destinations exigeant un mémo/tag/commentaire sortant nécessitent un portefeuille externe.

1. Ouvre Projet → Portefeuilles → actif → Envoyer. Choisis une entrée du carnet d'adresses ou saisis une destination. Vérifie l'adresse complète et le réseau.
2. Choisis un montant exact ou tout le disponible, puis un niveau de frais. Pour les tokens pris en charge, Utiliser les ETH du projet pour le gas (ou la monnaie native de la blockchain) peut financer les frais manquants depuis le même projet et la même blockchain.
3. Clique sur Préparer le transfert. Vérifie les sources, la destination, le montant, les frais maximaux et toute allocation de gas. Approuver et envoyer autorise ce plan ; la préparation seule n'envoie rien.

Le financement du gas, les confirmations et l'envoi des tokens continuent en arrière-plan après approbation. Suis Activité des transferts, même après avoir fermé la fenêtre. La diffusion n'est pas une confirmation.

ETH à conserver dans le portefeuille du projet : 0 n'ajoute aucune réserve ; cela ne dépense pas tous tes ETH. 0.005 conserve au moins 0.005 ETH pour plus tard ; il te faut donc des fonds supplémentaires pour cette opération. Les règles automatiques enregistrées ne changent pas.

1. Ouvre Configuration du sweep automatique → actif → Configurer. Choisis une adresse de portefeuille ou une destination de plateforme d'échange prise en charge, pas les deux.
2. Définis le minimum du sweep et Conserver un montant minimum. Exemple : déclenchement à 100 USDC, conservation de 20 USDC, envoi de 80 USDC maximum. La réserve s'applique au projet entier, pas à chaque adresse.
3. Pour les tokens, vérifie Utiliser les ETH du projet pour le gas et saisis une Limite quotidienne de financement. Active le sweep automatique, puis Enregistrer la règle et confirme. Ouvrir Configurer seul n'active rien.

La limite quotidienne plafonne le gas natif alloué à chaque règle de token sur 24 heures glissantes. €1 peut être un plafond de départ pour un usage léger, pas un coût garanti ni un débit quotidien. Les transactions de financement ont aussi des frais. Frais réseau maximaux % peut limiter les frais cumulés de financement et de transfert.

Les contrôles s'exécutent automatiquement. Seules les adresses éligibles détenant des tokens reçoivent du gas ; les adresses vides n'en reçoivent pas. Une adresse sous-financée en dessous du minimum de sweep attend. Comprendre les limites de gas →

• Sauvegarde les portefeuilles et teste un petit transfert. Envoie les tokens avant de vider les monnaies natives. Les ETH présents ailleurs dans le projet doivent d'abord atteindre chaque adresse de tokens ; le gas inutilisé reste dans tes portefeuilles.
• Utilise des soldes à jour, des fournisseurs opérationnels et assez de fonds natifs. Les règles automatiques nécessitent un portefeuille actif sauvegardé et l'actif activé dans un magasin activé. Un faible solde de crédits de traitement peut suspendre les envois.
• Dans Activité des transferts, consulte la progression, le financement du gas et les liens d'explorateur. Si le résultat est incertain, actualise le même transfert ; n'en crée pas un autre pour le remplacer. Ne reprends qu'après avoir vérifié la raison et les limites.

Envoi désactivé ? Vérifie whollycrypto transfers status. Vérifie chaque règle activée avant whollycrypto transfers enable: cela s'applique à tout le serveur et peut exécuter immédiatement les règles enregistrées. Arrêter les étapes futures ne peut pas annuler les diffusions.

Magasin → Général : choisis des hôtes commerçant/paiement/API actifs. Les liens suivent la priorité magasin → magasin par défaut → système ; les noms retirés passent au niveau suivant. Configure séparément les hôtes des SDK. Les nouvelles tentatives signées conservent leurs liens d'origine.

• Utilise Full (strict), pas Flexible ; aucune clé API nécessaire.
• Désactive le cache et les vérifications interactives du navigateur ou antibot pour la console, la page de paiement et l'API.
• Autorise /.well-known/acme-challenge/ sur le port 80 sans redirections ni vérifications interactives pour les renouvellements.

Les contrôles interrogent le DNS autoritatif et vérifient l'origine : directe ou Cloudflare. Les visiteurs peuvent avoir d'anciens DNS en cache.

Les enregistrements et suppressions dans la console utilisent POST depuis la version 5.6.2 ; aucune exception « Not GET or POST » n'est nécessaire. La connexion et la protection CSRF restent actives. Sur api.*, autorise les méthodes documentées de l'API publique.

Remplacer les codes ou désactiver la 2FA nécessite ton mot de passe et un code d'authentification ou de récupération inutilisé. Les autres sessions sont déconnectées. Garde les horloges du téléphone et du serveur synchronisées ; la 2FA ne sécurise pas un serveur compromis.

L'icône de thème alterne entre Clair → Tamisé → Sombre et mémorise le choix de ce navigateur. Les thèmes des pages de paiement des magasins sont distincts.

Tu peux ajouter des règles d'accès Cloudflare. Exempte les challenges de renouvellement HTTPS ; évite les vérifications de connexion interactives sur l'API et la page de paiement. Le mode proxy seul n'est pas une restriction IP.

Accès bloqué ? Exécute whollycrypto access-reset --domain merchant.example.com via SSH. Seul ce nom d'hôte est rouvert, sous cinq secondes ; l'authentification du compte reste activée.

Exécute whollycrypto ssl --domain merchant.example.com --reissue pour forcer un remplacement. Les limites d'émission s'appliquent. Si Cloudflare bloque le challenge HTTP, utilise temporairement le mode DNS seul. Les portefeuilles, l'authentification et les domaines ne changent pas.

Ancien outil de mise à jour bloqué ? Exécute ceci une fois. Ta clé installée vérifie l'utilitaire.

bash <(curl -fsSL https://releases.whollycrypto.com/update_wholly.sh)

L'installation et les mises à jour essaient automatiquement le miroir GitHub officiel. Les contrôles de signature, de somme de contrôle et de crédit restent obligatoires.

Les contrôles sont en lecture seule et renvoient un code non nul quand une intervention est nécessaire. --fix répare uniquement les permissions gérées et un lien CLI manquant. Il ne modifie jamais la facturation, ne supprime aucune donnée et ne redémarre aucun service.

whollycrypto reset
# Preview without changing anything:
whollycrypto reset --scope business --check
whollycrypto reset --scope project --project YOUR_PROJECT_IDENTIFIER --check

Choisis un projet, tous les projets commerciaux ou la réparation seule. La réinitialisation des projets efface définitivement les projets sélectionnés, leurs magasins, les enregistrements de portefeuilles et l'historique des paiements. La réparation seule vérifie et corrige les permissions gérées et le lien CLI.

Désactive d'abord les projets sélectionnés, résous les paiements/transferts ouverts et déplace les soldes connus des portefeuilles. Les comptes, domaines, nœuds, crédits, l'identité de facturation et le mode d'installation restent. Les portefeuilles de réception de l'opérateur et les registres de crédits hébergés sont protégés. Cela ne rouvre pas l'assistant de configuration.

Une réinitialisation destructive exige une confirmation saisie et crée une sauvegarde de récupération vérifiée avant l'effacement. Garde aussi une sauvegarde des portefeuilles hors du serveur : les anciennes adresses peuvent encore recevoir des fonds, mais les projets supprimés ne les suivent plus. Les soldes en cache ne prouvent pas que les portefeuilles sont vides.

whollycrypto uninstall --check
whollycrypto uninstall

Arrête la page de paiement, l'API et les workers ; supprime les fichiers d'exécution et l'intégration serveur gérée après sauvegarde et confirmation saisie. Les paiements ou transferts en attente bloquent la suppression. Les fichiers sont déplacés dans la sauvegarde de récupération au lieu d'être effacés.

La base, la configuration, les clés et les sauvegardes restent. Les paquets partagés Nginx/PostgreSQL et les certificats TLS ne sont pas touchés. La commande affiche une commande de récupération hors ligne ; ne lance pas une nouvelle installation sur les données conservées.

Les commandes de réinitialisation/suppression concernent les installations VPS natives, pas Docker ni Umbrel. Pour les conteneurs, utilise les commandes de sauvegarde et d'arrêt de ton intégration ; conserve les volumes. Aucune des deux commandes destructives n'accepte --yes.

whollycrypto htaccess

Sélectionne un utilisateur, choisis un nom et un mot de passe, puis confirme. Cela réinitialise la première invite de connexion du navigateur, pas ton compte console. Les autres utilisateurs et les identifiants API ne changent pas.

whollycrypto admin-reset

Choisis un administrateur par e-mail et confirme le nouveau mot de passe. Les sessions et les blocages de connexion du compte sont supprimés ; les restrictions IP restent.

Les réinitialisations normales conservent la 2FA. Si tu as perdu l'authentificateur et les codes de récupération, exécute explicitement whollycrypto admin-reset --email admin@example.com --reset-2fa. Configure à nouveau la 2FA après la connexion.

Nécessite la base de données, pas l'application ni l'ancien mot de passe. Les autres comptes, portefeuilles et permissions ne changent pas ; les comptes désactivés le restent.

Tu as perdu l'authentificateur et les codes de récupération ? Choisis un compte en tant que root.

whollycrypto 2fa-reset
# Or select the account directly:
whollycrypto 2fa-reset --email user@example.com

Supprime les sessions, l'authentificateur et les codes de récupération. Connecte-toi avec le mot de passe existant et configure à nouveau la 2FA. Les permissions, portefeuilles et Basic Auth ne changent pas ; les comptes désactivés le restent.

Nécessite la base de données, pas l'application ni les crédits. Sans interaction : --email et --yes.

Entrée génère un mot de passe dans /root/whollycrypto/config/credential-resets/: privé, non chiffré, utilisable après réussite. Les mots de passe saisis manuellement ne sont pas enregistrés.

whollycrypto htaccess --user admin --new-user operator
whollycrypto admin-reset --email admin@example.com

Sans terminal, indique le compte existant ainsi que --generate ou --password-file /root/private-password.txt, et --yes. Les fichiers de mots de passe doivent appartenir à root, avec le mode 600. Ne mets jamais de mots de passe dans les commandes ou les variables d'environnement.

--yes saute uniquement la confirmation. Termine d'abord la récupération d'une mise à jour interrompue ; des changements de compte simultanés arrêtent les réinitialisations.