Dokumentation

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

Wähle eine noch gepflegte Version. Höhere Vorgaben deiner Distribution gelten zuerst: openSUSE Leap 16 nennt zum Beispiel mehr als 40 GB Speicherplatz.

Mehr Last braucht gegebenenfalls mehr CPU/RAM; RPC-Limits bleiben. Setup ist automatisiert getestet, aber nicht für jede Distribution vollständig auf einem frischen VPS.

Schau dir das Skript an. Mit --check am Ende prüfst du die Voraussetzungen ohne Installation. --help zeigt die Optionen.

Setze die Einrichtung fort. Schlüssel und Einstellungen bleiben erhalten:

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

Weitere Basisdomains können dieselben Dienstnamen nutzen. Auch IPv6-Einträge müssen auf diesen VPS zeigen. Aktiviere den Cloudflare-Proxy erst nach der Domain-Prüfung.

Neue Beträge für erkannte Stablecoins werden aufgerundet: 1,321 USDC → 1,33 USDC, auch ohne Zahlungstoleranz. Minimum: 0,01 Token.

Bestehende Rechnungen, Guthaben und Restbeträge nach Teilzahlungen bleiben exakt. Andere oder eigene Token behalten ihre normale Genauigkeit.

Dein Basic-Auth-Login steht in /root/whollycrypto/config/setup-credentials.txt. Er ist getrennt von E-Mail und Passwort deines Dashboard-Kontos.

Neue Projekte übernehmen Währung und Zeitzone aus den Systemeinstellungen; Stores nutzen die Projektwährung. Bestehende Konto-Zeitzonen änderst du separat unter Settings → Account.

whollycrypto welcome zeigt dir deine Dashboard-Adresse und hilfreiche Links erneut.

1. Öffne Store → Payment methods, wähle eine unterstützte EVM-Chain oder Solana und dann Custom token neben der Suche.
2. Trage Contract oder Mint, Name und Kürzel ein. Wähle einen festen USD-Preis oder einen automatischen DEX-Kurs.

Chain und Dezimalstellen werden geprüft. Der Preis gilt für alle Stores im Projekt; bestehende Rechnungen behalten ihren Kurs. Ein Katalogtreffer allein macht einen Token noch nicht zur verfügbaren Zahlungsart.

Automatische Kurse

DEX Screener sucht Pools zum genauen Contract, etwa bei Uniswap und PancakeSwap. Ein Pool braucht mindestens 10.000 USD Liquidität und einen Trade in der letzten Stunde. Die Kurse werden jede Minute aktualisiert.

Fehlgeschlagene Prüfungen oder Kurse über fünf Minuten blockieren neue Angebote. DEX-Kurse können manipuliert sein. Nutze vertrauenswürdige Standard-Token: ERC-20 oder klassisches SPL. Die Prüfung ist kein Sicherheits-Audit; Token-2022/Erweiterungen werden nicht unterstützt. Ohne passenden Pool kannst du einen festen Preis nutzen.

Rechnung lässt sich nicht erstellen? Prüfe den Scanner-Badge, nicht nur den Node-Status. TRON braucht zwei unabhängige tron-indexer-Anbieter. Das Rechnungsformular zeigt Gründe und Lösungen. Wallets trennt Empfangsbereitschaft von Guthaben und Gas zum Senden.

API/MCP-Fehler enthalten error.details.payment_methods. SDK 2.4.0 erklärt bekannte Fehler sicher: PHP getPaymentMethodIssues(), Python payment_method_issues, Node paymentMethodIssues. Fehlerreferenz →

Krypto-Beträge werden aufgerundet und enthalten den Kursaufschlag des Stores. Eine Rechnung in Fiat tauscht deine Krypto-Zahlung nicht automatisch in Bankguthaben um.

Bei null Bestätigungen gilt die Zahlung schon beim Erkennen als abgeschlossen – ohne den Schutz von Netzwerkbestätigungen. Native EVM-Zahlungen werden als direkte Überweisungen erkannt. Prüfe abweichende oder unklare Zahlungen unter Needs attention.

Standardmäßig gesperrt. Mit Stores → Invoice → Allow zero-amount invoices erlaubst du Nullbeträge manuell und per API. Sie sind sofort abgeschlossen, ohne Zahlung, Empfangsadresse, Transaktion oder Verarbeitungsgebühr.

Ereignisse: invoice.created, payment.received, invoice.processing, invoice.settled, invoice.expired, invoice.invalid, invoice.cancelled. Nicht jede Rechnung durchläuft jeden Status. Version 2 enthält signierte event_type, event_id und Projekt-/Store-IDs.

Der Body enthält invoice_id (öffentliche UUID), status, amount_status, timing_status, resolution, sequence, amount, currency und order_id. Beträge sind Dezimal-Strings: Eine Rechnung über 49,90 € sendet auch bei USDC-Zahlung "amount": "49.9", "currency": "EUR".

Zu wenig: amount_status = partial. Zu viel: overpaid. Verspätet: timing_status = late. Das sind keine eigenen Rechnungsstatus. paid berücksichtigt deine Unterzahlungstoleranz.

payment_info enthält exakte Beträge, Transfers und Chain-/Token-IDs. Kundendaten und Metadaten gehen ebenfalls nur an deinen privaten Empfänger.

Beim Abschluss stehen paid_chain, paid_asset, paid_payment_method_id und settlement_exchange_rate bereit. Der Kurs bedeutet Asset-Einheiten pro Rechnungswährungseinheit, vor Aufschlag. Ohne Zahlungsnachweis oder historische Daten bleiben die Werte null. Wiederholungen ändern sie nicht.

5.0.1 ergänzt paid_asset_amount (voller Kryptobetrag) und paid_asset_amount_received (Eingang beim Abschluss). Exakte Dezimalstrings zeigen auch tolerierte Fehlbeträge: "100" angefordert, "99" erhalten. Die Werte bleiben gespeichert; ältere Abschlüsse liefern null. Spätere Eingänge stehen in payment_info.

Fehlend ist nicht unbestätigt. remaining_amount zeigt den noch nötigen Betrag nach Toleranz. Bereits empfangenes Geld muss nicht erneut gesendet werden. Beträge und kleinste Einheiten bleiben exakte Strings. Addiere nie verschiedene Assets.

Ursprünglicher Kurs, Aufschlag, Toleranz und Rundung bleiben fest. Marktkurse dienen nur zur Orientierung. Bei gekürzten Listen hilft die Zahlungs-API mit Seitenaufteilung.

Getrennte Signierschlüssel: Store → IPN gilt für IPNs, auch mit eigener ipn_url pro Rechnung. Jeder Endpunkt unter Store → Webhooks hat seinen eigenen Schlüssel, sichtbar beim Anlegen oder Erneuern.

Beide nutzen Wholly-Signature und dieselbe SDK-Prüfung. Nutze den passenden Signierschlüssel, keinen API-Schlüssel. Wenn du den IPN-Schlüssel erneuerst, bleiben die Webhook-Schlüssel unverändert.

Prüfe unveränderten Body, Zeitstempel und Projekt-/Store-Zuordnung. Speichere dauerhaft und antworte dann mit HTTP 2xx. Prüfe die Rechnung über deine fest konfigurierte API-URL gegen die Bestellung. Ereignis- und Zustell-Header sind unsigniert; Version 2 enthält zusätzlich die signierte Ereignis-ID im Body.

Für einen Bestellstatus-Posteingang erkennst du Duplikate anhand von Projekt, Rechnungs-ID und Sequenz. Verschiedene Ereignisse können dieselbe Revision haben: Vergleiche die ursprünglichen Statusfelder, nicht den ganzen JSON-Body. Wenn du jedes Ereignis verarbeitest, nutze die signierte Ereignis-ID. Erfülle eine Bestellung trotzdem nur einmal.

IPN versucht wiederholbare Fehler bis zu achtmal; bei Webhooks kannst du Wiederholungen abschalten. Nachrichten können verspätet, doppelt oder in anderer Reihenfolge eintreffen. Überschreibe nie eine neuere Rechnungsrevision mit einer älteren.

Suche unter Store → IPN / Webhooks → History nach Bestellung, Rechnungs-ID oder E-Mail. Details zeigt gespeicherten Body und Zustellergebnis. Die Verläufe findest du auch in den Rechnungsdetails.

data.invoice_id entspricht der Callback-ID. SDK 2.1.0 unterstützt Version 2 und ältere Ereignisse; aktualisiere strikte Empfänger. Gespeicherte Inhalte laufen nach 90 Tagen ab. Erneutes Senden bestätigt keinen Erfolg. Zu wenig Guthaben pausiert Nachrichten, nicht Zahlungen.

1. Verbinde unter Settings → Exchanges einen eigenen API-Schlüssel, prüfe Guthaben und gib Projekte frei. Aktiviere Spot-Handel nur bei Bedarf. Keine Auszahlungsrechte; beschränke den Schlüssel auf deine VPS-IP.
2. Prüfe unter Projekt → Sweep Asset, Einzahlungsnetzwerk und Adresse. Bei Token musst du gegebenenfalls den genauen Contract bestätigen.
3. Wähle je Chain/Token entweder ein anderes Wallet oder eine Börse. Nutze einen direkten Markt oder behalte den Coin. Teste zuerst einen kleinen Betrag.

Märkte aktualisieren sich ungefähr alle zwei Minuten. Veraltete Kurse stoppen neue Umtausche. Genutzt werden nur zugeordnete, gutgeschriebene Einzahlungen. Unklare Orders werden geprüft, nicht blind erneut gesendet. 1% bleibt als Reserve für Gebühren und Rundung auf der Börse, getrennt vom Verarbeitungsguthaben.

Verwahrung durch die Börse, KYC, regionale Grenzen sowie Handels- und Netzwerkgebühren gelten weiterhin. Keine mehrstufigen Trades, Hebel oder Bankauszahlungen. Ohne Verarbeitungsguthaben pausieren neue Umtausche; bestehende Orders werden weiter geprüft.

Neue Installationen starten mit der zugewiesenen Gebühr, normalerweise 1 %. Nach Aktivierung gibt es einmalig 10 USD Startguthaben oder den Gegenwert. Gebühren richten sich nach dem ursprünglichen Fiatwert der bezahlten Rechnung. Die Krypto-Zahlung deiner Kunden wird nicht aufgeteilt.

Gebühren fallen weiter an, auch bei negativem Saldo. Gleiche das Minus aus und lade genug für nutzbares Guthaben über dem erlaubten Spielraum auf. Bei funktionierender Verbindung siehst du Guthabenänderungen normalerweise nach 10–15 Sekunden.

Für Updates muss dein geprüftes Guthaben über null liegen, auch wenn Automatiken einen Spielraum haben. Eine Aufladung installiert Updates nie automatisch.

Pausierte Benachrichtigungen verbrauchen keine Versuche. Gespeicherte Zustellungen werden fortgesetzt, ihre normale Ablaufzeit bleibt bestehen. Gleiche fehlende Ereignisse über die Rechnungs-API ab.

Schaltet der Betreiber Gebühren ab, gelten keine neuen Verarbeitungsgebühren oder Guthaben-Einschränkungen. Alte Gebühren bleiben im Verlauf. Ohne Kopplung kannst du Projekte/Stores einrichten; Rechnungen brauchen geprüfte Abrechnung. Bereits erstellte Rechnungen werden weiter überwacht.

• Umsatz nutzt bezahlte Rechnungswerte und ihren Abschlusszeitpunkt, vor Gebühren/Rückzahlungen – nicht Wallet-Guthaben oder Gewinn.
• Umrechnungen nutzen aktuelle gespeicherte Kurse, keine historischen Buchhaltungskurse. Ursprüngliche Währungssummen bleiben bei fehlenden Kursen verfügbar.
• Rechnungsstatus-Diagramme nutzen das Erstellungsdatum. Needs attention zeigt aktuell offene Probleme.

• Nutze Full (strict), nicht Flexible. Du brauchst keinen Cloudflare-API-Schlüssel.
• Schalte Caching und Browser-/Bot-Challenges für Dashboard, Checkout und API aus.
• Lass /.well-known/acme-challenge/ auf Port 80 ohne erzwungene Umleitungen oder Zugangskontrolle erreichbar, damit Zertifikatserneuerungen klappen.

Die Prüfung fragt direkt die zuständigen Nameserver ab und prüft den Ursprungsserver. Sie zeigt Direct oder Cloudflare an. Besucher können noch ältere DNS-Daten zwischengespeichert haben.

Neue Codes oder das Abschalten von 2FA brauchen dein Passwort und einen Authenticator- oder ungenutzten Wiederherstellungscode. Andere Sitzungen werden abgemeldet. Halte Handy-/Serveruhren synchron. 2FA schützt keinen bereits gehackten Server.

Das Theme-Symbol wechselt Light → Dim → Dark und merkt sich die Wahl im Browser. Das Store-Checkout-Design bleibt getrennt.

Optional kannst du Cloudflare-Zugriffsregeln ergänzen. Nimm Zertifikatserneuerungen davon aus. Nutze keine Browser-Anmeldeprüfung für API oder Checkout. Der Proxy allein beschränkt keine IPs.

Ausgesperrt? Starte über SSH whollycrypto access-reset --domain merchant.example.com. Nur diese Adresse wird innerhalb von fünf Sekunden wieder geöffnet. Der Anmeldeschutz bleibt aktiv.

Mit whollycrypto ssl --domain merchant.example.com --reissue erzwingst du die Neuausstellung. Ausstellungslimits gelten weiter. Blockiert Cloudflare die HTTP-Prüfung, nutze kurz DNS-only. Wallets, Anmeldeschutz und Domains bleiben gleich.

Updater blockiert? Einmal ausführen; dein installierter Schlüssel prüft den Download.

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

Setup und Updates nutzen bei Ausfällen den offiziellen GitHub-Mirror. Aktiviere GitHub-Fallback auch für das Setup-Skript. Signaturen, Prüfsummen und Guthabenregeln bleiben Pflicht.

Die Prüfung ändert nichts; Probleme ergeben einen Exit-Code ungleich null. --fix repariert nur verwaltete Dateirechte und einen fehlenden CLI-Link. Keine Neustarts, Löschungen oder Gebührenänderungen.

whollycrypto htaccess

Wähle Benutzer, Namen und Passwort und bestätige. Das ändert die erste Browser-Anmeldung, nicht dein Dashboard-Konto. Andere Benutzer und API-Zugangsdaten bleiben gleich.

whollycrypto admin-reset

Wähle den Admin per E-Mail und bestätige das neue Passwort. Sitzungen und Kontosperren werden aufgehoben; IP-Regeln bleiben aktiv.

Normale Resets lassen 2FA aktiv. Sind Authenticator und Wiederherstellungscodes verloren, nutze ausdrücklich whollycrypto admin-reset --email admin@example.com --reset-2fa. Richte 2FA nach der Anmeldung erneut ein.

Braucht die Datenbank, nicht App oder altes Passwort. Andere Konten, Wallets und Rechte bleiben gleich; deaktivierte Konten bleiben deaktiviert.

Authenticator und Wiederherstellungscodes verloren? Wähle als root ein Konto.

whollycrypto 2fa-reset
# Oder das Konto direkt wählen:
whollycrypto 2fa-reset --email user@example.com

Entfernt Sitzungen, Authenticator und Wiederherstellungscodes. Melde dich mit deinem Passwort an und richte 2FA erneut ein. Rechte, Wallets und Basic Auth bleiben gleich; deaktivierte Konten bleiben deaktiviert.

Braucht die Datenbank, nicht die App oder Guthaben. Ohne Terminal: --email und --yes.

Enter erzeugt ein Passwort in /root/whollycrypto/config/credential-resets/: privat, unverschlüsselt, erst nach Erfolg nutzbar. Eigene Passwörter werden nicht gespeichert.

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

Ohne Terminal brauchst du das bestehende Konto plus --generate oder --password-file /root/private-password.txt sowie --yes. Passwortdateien müssen root gehören und Modus 600 haben. Schreibe Passwörter nie in Befehle oder Umgebungsvariablen.

--yes überspringt nur die Bestätigung. Repariere abgebrochene Updates zuerst; gleichzeitige Kontoänderungen stoppen den Reset.