Das richtige Asset auf der richtigen Chain.

Jede Rechnung bekommt eine neue Adresse. Sichere die ganze Wallet. Eine externe Wallet-App muss eventuell weiter nach abgeleiteten Adressen suchen. Bitcoin Lightning ist eine eigene Zahlungsmethode, siehe unten.

Neue Rechnungsadressen. Akzeptiert werden der native Coin und verifizierte ERC-20-Verträge, die du im Store aktivierst. Normale native Transfers und Token-Transfer-Logs werden geprüft; interne ETH-Bewegungen in Verträgen sind keine unterstützte Zahlungsroute.

Nutze Ethereum Mainnet. Verifizierte ERC-20-Token wie USDC und USDT brauchen später ETH an jeder sendenden Adresse. MetaMask zeigt nach dem Import der Wörter eventuell nur das erste Konto.

Neue Rechnungsadressen. Akzeptiert werden der native Coin und verifizierte ERC-20-Verträge, die du im Store aktivierst. Normale native Transfers und Token-Transfer-Logs werden geprüft; interne ETH-Bewegungen in Verträgen sind keine unterstützte Zahlungsroute.

Wähle Base, nicht Ethereum Mainnet, auch wenn beide ETH und ähnliche Adressen nutzen. Prüfe den Token-Vertrag: Überbrückte und native Varianten sind verschiedene Assets.

SOL und verifizierte klassische SPL-Token sind möglich, etwa passende USDC-/USDT-Mints. Token-2022 samt Erweiterungen wird nicht akzeptiert. Halte SOL für Gebühren und Token-Konten bereit. Nutze die Adresse und Zahlungsanforderung aus dem Checkout.

Neue Rechnungsadressen. Akzeptiert werden der native Coin und verifizierte ERC-20-Verträge, die du im Store aktivierst. Normale native Transfers und Token-Transfer-Logs werden geprüft; interne ETH-Bewegungen in Verträgen sind keine unterstützte Zahlungsroute.

Nutze BNB Smart Chain mit verifizierten EVM-Token-Verträgen, oft BEP-20 genannt. Gemeint ist nicht die frühere Beacon Chain. Gebühren werden in BNB bezahlt, nicht in ETH.

Nur natives TRX. TRC-20-Token, auch USDT auf TRON, sind keine Rechnungs-Zahlungsmethoden. Ein gesunder Basis-Node garantiert noch keinen Zugriff auf den nötigen Transaktionsverlauf.

Rechnungen teilen ein finanziertes Konto und bekommen einen eigenen Destination Tag. Der Kunde muss den genauen Tag mitsenden; eine X-Adresse kann ihn enthalten. XRP-Kontoreserven gelten weiterhin. Ausgegebene Token werden nicht akzeptiert.

Neue Rechnungsadressen. Akzeptiert werden der native Coin und verifizierte ERC-20-Verträge, die du im Store aktivierst. Normale native Transfers und Token-Transfer-Logs werden geprüft; interne ETH-Bewegungen in Verträgen sind keine unterstützte Zahlungsroute.

Diese Integration nutzt HyperEVM, nicht HyperCore oder ein Spot-Einzahlungskonto der Börse. Gebühren brauchen HYPE. Wähle nur verifizierte Verträge auf HyperEVM.

Es werden nur transparente ZEC-Zahlungen erkannt. Nutze keine abgeschirmten Transfers und erwarte dort kein sichtbares Guthaben. Jede Rechnung bekommt eine eigene transparente Empfangsadresse.

Verbinde neben dem Daemon eine externe, projektspezifische View-only-Wallet-RPC. Jede Rechnung bekommt eine Subadresse. Ein öffentlicher Daemon allein erkennt deine Zahlungen nicht. Die ausgabefähige Wallet bleibt außerhalb; Wholly Crypto kann XMR nicht sweepen.

Nur natives ADA, mit Transaktionsverlauf aus einer passenden Quelle wie Koios. Native Cardano-Token sind keine Rechnungs-Assets. Beachte beim Senden die Mindestbeträge für Outputs.

Ein finanziertes gemeinsames Konto nutzt pro Rechnung eine numerische MEMO_ID. Kopiere das Memo mit dem richtigen Typ genau. Kontoreserven gelten weiterhin. Auf Stellar ausgegebene Assets, auch USDC, werden nicht akzeptiert.

Nutze Bitcoin Cash, nicht Bitcoin. Native BCH-Zahlungen gehen an neue Rechnungsadressen. SLP und CashTokens werden nicht akzeptiert. Die Wallet des Kunden muss das angezeigte Adressformat unterstützen.

Nutze normale transparente LTC-Transfers an die neue Rechnungsadresse. Private MWEB-Transfers sind nicht Teil des Rechnungsscanners. Plane Netzwerkgebühren beim Senden ein.

Natives DOGE nutzt eine neue Adresse pro Rechnung. Viele kleine Outputs können beim Zusammenführen teurer sein als eine größere Zahlung. Prüfe Gebühren und Mindestbeträge vor einem Sweep.

Neue Rechnungsadressen. Akzeptiert werden der native Coin und verifizierte ERC-20-Verträge, die du im Store aktivierst. Normale native Transfers und Token-Transfer-Logs werden geprüft; interne ETH-Bewegungen in Verträgen sind keine unterstützte Zahlungsroute.

Nutze Avalanche C-Chain. X-Chain und P-Chain sind andere Netzwerke und gehören nicht zu dieser Zahlungsmethode. C-Chain-Token brauchen AVAX für Gebühren.

Neue Rechnungsadressen. Akzeptiert werden der native Coin und verifizierte ERC-20-Verträge, die du im Store aktivierst. Normale native Transfers und Token-Transfer-Logs werden geprüft; interne ETH-Bewegungen in Verträgen sind keine unterstützte Zahlungsroute.

Nutze Polygon PoS und POL für Gebühren. Ethereum und Polygon zkEVM sind nicht dasselbe Netzwerk. Prüfe den genauen Token-Vertrag statt nur das Kürzel.

Neue Rechnungsadressen. Akzeptiert werden der native Coin und verifizierte ERC-20-Verträge, die du im Store aktivierst. Normale native Transfers und Token-Transfer-Logs werden geprüft; interne ETH-Bewegungen in Verträgen sind keine unterstützte Zahlungsroute.

Nutze Arbitrum One. ETH auf Ethereum Mainnet oder einem anderen Arbitrum-Netzwerk bezahlt keine Arbitrum-One-Rechnung. Halte ETH auf dieser Chain für Token-Sweeps bereit.

Neue Rechnungsadressen. Akzeptiert werden der native Coin und verifizierte ERC-20-Verträge, die du im Store aktivierst. Normale native Transfers und Token-Transfer-Logs werden geprüft; interne ETH-Bewegungen in Verträgen sind keine unterstützte Zahlungsroute.

Nutze OP Mainnet und seine verifizierten Verträge. Dasselbe Token-Kürzel auf einem anderen Netzwerk ist eine andere Zahlungsmethode. Token-Versand braucht ETH auf OP Mainnet.

Rechnungen nutzen eine gemeinsame Wallet und einen genauen Rechnungskommentar. Die zahlende Wallet muss diesen Kommentar mitsenden. Nur natives TON: Jettons, auch USDT auf TON, werden nicht akzeptiert.

Natives APT wird über passende Aptos-REST-Transaktions-APIs erkannt. Andere Move-Token sind keine Rechnungs-Zahlungsmethoden. Prüfe Netzwerk und Kontoadresse vor dem Bezahlen.

Natives SUI braucht eine passende History-API, etwa unterstützten GraphQL-Zugriff. Ein erfolgreicher Basis-RPC-Check reicht nicht. Andere Sui-Coins oder Token sind keine Rechnungs-Assets.

Gemeint ist natives ATOM auf Cosmos Hub, nicht jede Cosmos-SDK-Chain oder jeder IBC-Token. Der Scanner braucht indizierte Transaktionsereignisse. Nutze die Rechnungsadresse, keine Börsen-Einzahlungsadresse.

Nutze DOT auf Polkadot Asset Hub, nicht auf der Relay Chain. Du brauchst eine passende Asset-Hub-Transaktions-API oder den unterstützten Rohblock-Scanner. Andere Asset-Hub-Token sind keine Rechnungs-Zahlungsmethoden.

Nur natives NEAR. Die Erkennung prüft erfolgreiche Receipts, nicht nur eingereichte Transaktionen. Bewahre Konto- und Ableitungsdaten im Wallet-Backup auf. NEP-Token werden nicht akzeptiert.

Natives ALGO nutzt passende Transaktionsdaten von Indexer oder algod. Mindestguthaben für Konten gelten weiterhin. Algorand Standard Assets, auch USDC-ASAs, werden nicht akzeptiert.

Native HBAR-Rechnungen nutzen einen EVM-Alias, der nach der Finanzierung zum Hedera-Konto aufgelöst wird. Empfangsdaten kommen aus einer Mirror-REST-API; ein EVM-Relay allein reicht nicht. HTS-Token werden nicht akzeptiert.

Natives KAS braucht eine passende REST-Transaktionsquelle und Nachweise aus der akzeptierten Chain. DAG-Fortschritt allein ist keine bestätigte Zahlung. KRC-20-Token sind keine Rechnungs-Assets.

Natives XTZ braucht erfolgreich angewendete Operationen von TzKT oder einer passenden Octez-Quelle. Fehlgeschlagene Operationen bezahlen keine Rechnung. FA1.2- und FA2-Token werden nicht akzeptiert.

Natives DASH nutzt eine neue Adresse pro Rechnung. Lass den Scanner deine Bestätigungsregel prüfen. Eine InstantSend-Anzeige allein bedeutet nicht, dass die Wholly-Crypto-Rechnung abgeschlossen ist.