Eine Krypto-Zahlungsintegration zu testen bedeutet nachzuweisen, dass die richtige Bestellung genau einmal und erst nach verifizierter Zahlung ausgeführt wird – nicht bloß, dass sich eine Zahlungsseite öffnet. Trennen Sie Tests der Nachrichtenzustellung, Tests der Bestellzustände Ihrer Anwendung und etwaige genehmigte Abnahmeprüfungen mit echtem Geld. Jeder dieser Tests beantwortet eine andere Frage.
Diese Checkliste richtet sich an Entwickler und Händler, die einen Zahlungsablauf für den Start vorbereiten, einschließlich Zahlungen in USDC oder USDT, sofern der gewählte Vermögenswert und das Netzwerk tatsächlich verfügbar sind. Sie beschreibt ein empfohlenes Testverfahren. Sie ist weder ein Bericht darüber, dass Yolfi diese Tests für Ihre Anwendung bestanden hat, noch eine Aussage, dass Yolfi einen vollständigen Zahlungsablauf im Testnetz bereitstellt.
Wissen, welche Art von Test Sie durchführen
Eine simulierte Zahlungsbenachrichtigung ist kein Blockchain-Transfer. Ein Transfer im Testnetz ist keine Zahlung im Produktionsnetzwerk. Eine erfolgreiche Browserweiterleitung ist keines von beidem.
| Testebene | Was sich damit nachweisen lässt | Was sich damit nicht nachweisen lässt |
|---|---|---|
| Anwendungstests mit kontrollierten Testdaten | Bestellübergänge, Ablehnungsregeln und Umgang mit Duplikaten | Dass der Anbieter Ihren bereitgestellten Empfänger erreichen kann |
| Test-Webhook des Anbieters | Erreichbarkeit des Endpunkts und Verarbeitung der Testdaten des Anbieters | Dass Geld geflossen ist oder eine echte Rechnung bezahlt wurde |
| Transfer im Testnetz, sofern ausdrücklich unterstützt | Verhalten in diesem konkreten Testnetz | Verfügbarkeit des Vermögenswerts in Produktion oder Abwicklung im Hauptnetz |
| Genehmigte Abnahmeprüfung im Echtbetrieb | Beobachtetes Ergebnis einer tatsächlichen Zahlung in Produktion | Dass jedes Netzwerk, jeder Token und jeder Fehlerfall funktioniert |
Der Netzwerkleitfaden von Ethereum erläutert, dass Kontostände und Transaktionshistorien nicht zwischen unabhängigen Netzwerken übertragen werden. Eine gleich aussehende Adresse macht Guthaben aus dem Testnetz nicht im Hauptnetz nutzbar. Prüfen Sie die aktuelle Dokumentation des Anbieters, statt anzunehmen, dass ein allgemeiner Wallet-Test auch für dessen Zahlungsdienst gilt.
Den Testrahmen zunächst schriftlich festhalten
Dokumentieren Sie vor dem ersten Versand die Anwendungsumgebung, das Anbieterkonto, die Empfänger-URL, den Speicherort des Signaturgeheimnisses, die Bestell-IDs und die beabsichtigten Auswirkungen. Verwenden Sie entbehrliche Kundendatensätze und deaktivieren Sie für simulierte Szenarien echte Auslieferungen, kostenpflichtige Zugänge und Kunden-E-Mails.
Halten Sie Test- und Produktionskonfiguration getrennt. Kopieren Sie niemals ein Signaturgeheimnis in einen Artikel, einen Screenshot, eine Fehlermeldung im Ticketsystem oder einen Chatverlauf. Ihre Testnachweise sollten die verwendete Version des Geheimnisses benennen, nicht dessen Wert offenlegen. Fordern Sie von Käufern keine Wiederherstellungsphrasen oder privaten Schlüssel an, um einen fehlgeschlagenen Test zu untersuchen.
Holen Sie für eine Prüfung mit echtem Geld eine ausdrückliche interne Genehmigung für Betrag, Gebühren, Ziel und verantwortliche Person ein. Verwenden Sie eine vom Unternehmen kontrollierte Wallet und einen Betrag, dessen Verlust Sie verkraften können. Senden Sie kein Geld an eine Adresse oder in ein Netzwerk, nur weil diese in einem alten Screenshot, einer generierten Coin-Seite oder einer inoffiziellen Testanleitung vorkamen.
Nachweisen, dass der Server den Bestellbetrag bestimmt
Bei Yolfi API Checkout erstellt der Händlerserver eine Checkout Session mit dem endgültigen Betrag und der Währung. Der Käufer wählt anschließend ein unterstütztes Netzwerk und einen Token aus und erzeugt daraus eine Invoice. Ein wiederverwendbarer Paylink erfüllt einen anderen Zweck als eine dynamische Bestellung mit serverseitig festgelegtem Preis.
Testen Sie bei einem dynamischen Warenkorb zunächst die Preisberechnung und Sitzungszuordnung Ihres eigenen Servers, bevor Sie Geldbewegungen prüfen:
- Ändern Sie einen vom Browser übermittelten Gesamtbetrag und bestätigen Sie, dass er den verbindlichen Bestellpreis nicht überschreiben kann.
- Versuchen Sie, die Bestellreferenz eines anderen Kunden zu verwenden, und bestätigen Sie, dass die Anwendung unbefugten Zugriff verweigert.
- Aktualisieren oder öffnen Sie den Zahlungsablauf erneut und prüfen Sie, ob wiederholte Versuche der vorgesehenen Bestellung zugeordnet bleiben.
- Ändern Sie den Warenkorb nach dem Erstellen der Sitzung und bestätigen Sie, dass die Anwendung eine ausdrückliche Regel zum Ersetzen oder Ablehnen des alten Zahlungsversuchs hat.
Dies sind Abnahmekriterien für die Anwendung, keine Aussagen darüber, dass ein Anbieterendpunkt jede denkbare Anfrage ablehnt. Speichern Sie die Bestellreferenz des Servers zusammen mit der zurückgegebenen Sitzungsreferenz. Erfinden Sie kein API-Feld und nehmen Sie nicht an, dass eine vom Browser kontrollierte Kennung die Berechtigung belegt.
Einen Test-Webhook senden, ohne einen echten Verkauf auszulösen
Die aktuelle Webhook-Dokumentation von Yolfi beschreibt ein Testereignis aus der Verwaltungsoberfläche, das denselben Zustellungsweg, Adapter und Signatur-Header wie echte Ereignisse nutzt. Seine Nutzdaten enthalten livemode: false und eine Ereignis-ID mit evt_test_. Der Test erstellt weder Rechnungen noch Zahlungsereignisse, Abonnements oder Kundendatensätze.
Verwenden Sie dieses Ereignis, um Zustellung und Datenverarbeitung zu prüfen – nicht die Zahlungsabwicklung. Ein Empfänger, der 200 OK zurückgibt, kann trotzdem fälschlicherweise Zugang gewähren oder die Nachricht unbemerkt verwerfen. Prüfen Sie neben dem Zustellungsergebnis auch den daraus entstandenen Anwendungszustand.
Verifizieren Sie Signaturen nach dem dokumentierten Verfahren mit dem endpunktspezifischen Signaturgeheimnis, nicht mit dem API-Schlüssel der Organisation. Stellen Sie sicher, dass Ihr produktiver Ausführungsprozess ein Testereignis nicht als bezahlte Bestellung behandeln kann. Wenn Sie die Bestellausführung mit Testdaten in einer isolierten Testumgebung prüfen, verwenden Sie entbehrliche Datensätze und untersuchen Sie diese getrennt von der Produktion.
Yolfi verlangt ein öffentlich erreichbares HTTP- oder HTTPS-Ziel und folgt keinen Weiterleitungen. Für die lokale Entwicklung empfiehlt die Dokumentation einen öffentlichen HTTPS-Tunnel. Prüfen Sie die genaue endgültige Empfänger-URL: Eine erfolgreiche Anfrage an einen anderen Pfad oder eine nur lokal erreichbare Adresse belegt nicht, dass der Anbieter zustellen kann.
Eine Fehlermatrix statt nur eines Screenshots des Erfolgsfalls verwenden
Prüfen Sie mit kontrollierten Testdaten in Ihrer eigenen isolierten Testumgebung auch Fälle, die der Testsender des Anbieters nicht abbildet. Kennzeichnen Sie diese eindeutig als Anwendungstests; stellen Sie erfundene Anbieterereignisse nicht als Nachweise echter Zahlungen dar.
| Szenario | Erforderliche Beobachtung in Ihrer Anwendung |
|---|---|
| Gültiges Testereignis | Als Test erfasst; keine echte Auslieferung und kein Zahlungsbeleg |
| Fehlende oder ungültige Signatur | Vor jeder Änderung einer Bestellung abgelehnt |
| Zahlung eingeleitet, aber nicht bestätigt | Bestellung bleibt unbezahlt |
| Bestätigte Zahlung für eine unbekannte Bestellung | Zur Untersuchung zurückgestellt; keine Zuordnung zu einem geratenen Kunden |
| Dasselbe signierte Ereignis wird zweimal zugestellt | Ein dauerhaft gespeichertes Geschäftsergebnis, keine doppelte Auslieferung |
| Zwei Verarbeitungsprozesse bearbeiten dasselbe Ereignis | Eine Ausführungsentscheidung trotz gleichzeitiger Verarbeitung |
| Empfänger nicht erreichbar, anschließend wieder verfügbar | Wiederherstellung ohne doppelte Bestellausführung beobachtet |
| Browser schließt sich vor der Rückkehr | Zahlungsabwicklung hängt nicht von der Rückkehrseite ab |
Bei Yolfi signalisiert invoice.created die Einleitung; payment.confirmed ist der dokumentierte Auslöser für die Bestellausführung. Setzen Sie eine Bestellung nicht allein deshalb auf bezahlt, weil die erste Nachricht eingetroffen ist. Der Leitfaden zu idempotenten Webhooks behandelt die dauerhafte Deduplizierung; diese Checkliste konzentriert sich auf Nachweise, dass Ihre Implementierung sich tatsächlich entsprechend verhält.
Testen Sie die Wiederherstellung gezielt. Ein Prozess, der vor dem Speichern eines Ereignisses Erfolg zurückmeldet, kann bei einem Absturz Arbeit verlieren. Ein Prozess, der Waren ausliefert, bevor er den Abschluss dokumentiert, kann nach einem erneuten Versuch nochmals ausliefern. Wählen Sie eine dauerhaft abgesicherte Verarbeitungsarchitektur und testen Sie dann die Unterbrechungspunkte, statt aus einer einzigen erfolgreichen Anfrage auf Zuverlässigkeit zu schließen.
Käuferhinweise und den Ablauf für ungeklärte Zahlungen prüfen
Öffnen Sie den tatsächlichen Zahlungsablauf auf einem Smartphone und einem Desktoprechner. Prüfen Sie vor einem Transfer, ob angezeigter Betrag, gewählter Vermögenswert, Netzwerk, Ziel und Ablaufhinweise verständlich sind. Testen Sie Kopierfunktionen und QR-Scans, ohne anzunehmen, dass ein QR-Code jede sendende Wallet automatisch richtig konfiguriert.
Senden Sie keine nicht unterstützten Token, verwenden Sie nicht absichtlich das falsche Netzwerk und führen Sie keinen unumkehrbaren Transfer allein zum Testen einer Fehlermeldung aus. Spielen Sie solche Fälle für den Kundendienst stattdessen mit kontrollierten Datensätzen durch. Der Leitfaden zur Vermeidung falscher Netzwerke erläutert die Prüfungen, die Käufern angeboten werden sollten.
Spielen Sie eine unbezahlte oder abgelaufene Bestellung durch: Der Käufer sollte einen klaren Status und einen sicheren nächsten Schritt erhalten, kein unbelegtes Versprechen einer Wiederbeschaffung. Nutzen Sie das Verfahren für abgelaufene Rechnungen, um festzulegen, was vor einer erneuten Zahlungsaufforderung zu untersuchen ist. Eine zweite Zahlung darf nicht zur automatischen Antwort auf einen unklaren ersten Versuch werden.
Falls genehmigt, eine Abnahmeprüfung im Echtbetrieb dokumentieren
Fahren Sie erst fort, wenn bestätigt ist, dass der gewählte Vermögenswert und das Produktionsnetzwerk im tatsächlichen Ablauf verfügbar sind. Berücksichtigen Sie erforderliche Netzwerkgebühren und behalten Sie das Ziel unter Unternehmenskontrolle. Ein Test-Webhook des Anbieters rechtfertigt es nicht, echtes Geld über einen ungeprüften Weg zu senden.
Dokumentieren Sie Bestell- und Zahlungsreferenzen, den tatsächlichen Vermögenswert und das Netzwerk, den Betrag, die beobachtete Bestätigung, Nachweise der empfangenden Wallet und den entstandenen Ausführungszustand. Versprechen Sie keine allgemeingültige Anzahl von Bestätigungen oder Abwicklungsdauer. Prüfen Sie das tatsächlich beobachtete Ergebnis, nicht nur einen Wallet-Screenshot.
Gleichen Sie die Zahlung anschließend mit den Bestell- und Belegdatensätzen ab. Die Checkliste zum Zahlungsabgleich hilft, Geldeingänge von Bestellzuordnungen und Gebühren zu unterscheiden. Wenn Sie die Zahlung aus der Abnahmeprüfung erstatten möchten, genehmigen und verifizieren Sie die Erstattung gesondert; gehen Sie nicht von einer automatischen Rückabwicklung aus.
Eine bestandene Prüfung belegt einen beobachteten Zahlungsweg zu einem bestimmten Zeitpunkt. Wiederholen Sie relevante Abnahmetests, wenn sich Zahlungslogik, Empfängerbereitstellung, Geheimnisse oder unterstützte Zahlungswege ändern. Verallgemeinern Sie eine einzelne USDC-Zahlung niemals zum Nachweis, dass alle USDT-Netzwerke funktionieren.
Einen Nachweis zur Freigabe aufbewahren
Speichern Sie einen knappen Bericht mit getesteter Anwendungsversion, Umgebung, Szenarien, erwarteten Ergebnissen, tatsächlichen Ergebnissen und offenen Problemen. Verlinken Sie private Protokolle und Bestelldatensätze, statt Kundenkennungen oder vollständige Wallet-Verläufe zu veröffentlichen.
Verhindern Sie den Start, wenn ein Testereignis eine echte Bestellung ausführen kann, ein Duplikat doppelte Auslieferungen auslösen kann, ungültige Signaturen Zustände ändern können oder bestätigte Zahlungen nicht sicher zugeordnet werden können. Weisen Sie jedem offenen Punkt eine verantwortliche Person zu. Eine grüne Zustellungsanzeige ersetzt diese Geschäftsergebnisse nicht.
Häufig gestellte Fragen
Bewegt ein Test-Webhook von Yolfi Kryptowährungen?
Nein. Der dokumentierte Test prüft Zustellung und Datenverarbeitung, ohne Rechnungen oder Zahlungsdatensätze zu erstellen. Er beweist nicht, dass eine echte Blockchain-Zahlung erfolgreich war.
Ist eine Testnetzzahlung dasselbe wie eine Testumgebung eines Zahlungsdienstes?
Nein. Ein Testnetz ist ein separates Blockchain-Netzwerk. Eine Testumgebung eines Anbieters ist dagegen dienstspezifisch. Prüfen Sie, ob der Anbieter den konkret benötigten Modus unterstützt; dieser Artikel belegt keinen Yolfi-Zahlungsablauf im Testnetz.
Kann ich starten, sobald die Zahlungsseite erfolgreich weiterleitet?
Nicht allein auf dieser Grundlage. Prüfen Sie serverseitige Zahlungsabwicklung, Bestellzuordnung, Schutz vor Duplikaten und Wiederherstellung nach Fehlern. Der Käufer kann den Browser schließen, bevor sich eine Rückkehrseite öffnet.
Muss ich jeden Fehler mit echtem Geld testen?
Nein. Verwenden Sie isolierte Anwendungstests und dokumentierte Anbietersimulationen für die Fehlerbehandlung. Jede Abnahmeprüfung im Echtbetrieb erfordert eine Genehmigung und einen verifizierten, unterstützten Zahlungsweg – keine absichtlichen Transfers in falsche Netzwerke.
Fazit: Das Geschäftsergebnis vor dem Start testen
Beginnen Sie mit einem klaren Testrahmen, weisen Sie die serverseitige Bestellverarbeitung nach und unterscheiden Sie simulierte Ereignisse von verifizierten Geldeingängen. Nutzen Sie Yolfi-Zahlungslinks für geeignete Festpreisangebote oder den dokumentierten API-Ablauf für dynamische Bestellungen. Bewahren Sie anschließend Nachweise auf, dass die Zahlungsabwicklung – nicht die Browserweiterleitung – die Bestellausführung steuert.
