Source: https://cryptanio.com/de/wiki/zahlung-api-ohne-webhook-pruefen/ Language: de # Zahlungen über die API ohne Webhook prüfen Serverseitige Rechnungsprüfung über die API\: Zahlungsstatus\, begrenztes Polling\, Fehler\, einmalige Auftragsausführung und Wiederaufnahme nach Neustart\. Aktualisiert: 2026-11-14 Sie können eine Zahlung ohne Webhook auf dem Server Ihrer Anwendung prüfen\: die Rechnung regelmäßig über die Cryptanio\-API abrufen\, mit dem Auftrag abgleichen und den Auftrag bei aktuellem Status ` paid ` ausführen\. Dieses regelmäßige Abfragen heißt Polling\. Es erfordert eine Prüfwarteschlange\, Fehlerbehandlung und Schutz vor doppelter Ausführung\: Eine erfolgreiche HTTP\-Antwort allein bestätigt noch keine Zahlung\. Dieses Verfahren eignet sich\, wenn die Anwendung Hintergrundaufgaben ausführen kann\, der Empfang eingehender Benachrichtigungen aber noch unpraktisch ist\. Änderungen werden beim nächsten Abruf erkannt\; Polling liefert keine sofortige Benachrichtigung\. ## Was Sie benötigen {#was-sie-ben-tigen} Speichern Sie in Ihrer Datenbank die Zuordnung zwischen Auftrag und [Rechnung]()\: deren ` id `\, das Projekt\, Ihre ` reference `\, den vereinbarten Preis und den Betriebsmodus\. Bewahren Sie Kennungen als Zeichenfolgen auf\. Prüfen Sie die Rechnung dieses konkreten Auftrags\, nicht eine gefundene Transaktion mit ähnlichem Betrag\. Richten Sie einen serverseitigen API\-Schlüssel mit Leseberechtigung für ` invoices `\, Zugriff auf den Dienst ` payments ` und das erforderliche Projekt ein\. Ein echter Auftrag benötigt den entsprechenden Live\-Modus\. Hinterlegen Sie den Schlüssel weder im Browser noch im Käuferlink oder in einem öffentlichen Protokoll\. Für einen separaten Abgleichprozess genügt Lesezugriff\. ## Schritt 1\. Den aktuellen Zustand abrufen {#schritt-1-den-aktuellen-zustand-abrufen} Das Beispiel liest eine einzelne Rechnung\. Setzen Sie auf dem Server ` CRYPTANIO_API_KEY ` und ` CRYPTANIO_RESOURCE_ID `\; der zweite Wert ist die gespeicherte Rechnungs\-` id `\, nicht die Auftragsnummer oder die [TXID]()\. ```bash #!/usr/bin/env bash set -euo pipefail : "${CRYPTANIO_RESOURCE_ID:?Set CRYPTANIO_RESOURCE_ID}" : "${CRYPTANIO_API_KEY:?Set CRYPTANIO_API_KEY}" urlencode() { local LC_ALL=C text="$1" char index for ((index=0; index<${#text}; index++)); do char="${text:index:1}" case "$char" in [a-zA-Z0-9.~_-]) printf '%s' "$char" ;; *) printf '%%%02X' "'$char" ;; esac done } response_file="$(mktemp)" trap 'rm -f "$response_file"' EXIT transfer_status=0 http_status="$(curl \ --silent --show-error --max-time 30 --request GET \ --header "Authorization: Bearer $CRYPTANIO_API_KEY" \ --header 'Accept: application/json' \ "https://api.cryptanio.com/v1/invoices/$(urlencode "$CRYPTANIO_RESOURCE_ID")" \ --output "$response_file" --write-out '%{http_code}')" || transfer_status=$? if [[ "$http_status" == 2?? ]]; then cat "$response_file" exit "$transfer_status" fi printf 'HTTP %s\n' "$http_status" >&2 cat "$response_file" >&2 exit 1 ``` [Beispiel herunterladen]() Parsen Sie nach HTTP 200 das JSON und gleichen Sie ` id `\, ` project_id `\, ` reference ` und ` sandbox ` mit Ihren Daten ab\. Bei einem echten Auftrag wird ` sandbox=false ` erwartet\. Haben Sie einen Preis in ` invoice_currency ` und ` invoice_amount ` gespeichert\, prüfen Sie auch diese Felder\. Eine fremde Rechnung oder ein Datensatz eines anderen Modus darf den Auftrag nicht verändern\. Der Link ` checkout_url ` aus GET ist zur Ansicht bestimmt\. Ersetzen Sie damit nicht den interaktiven Link aus der Antwort auf die Rechnungserstellung\: Das Lesen des Status erstellt keine neue Zahlung und gibt keinen neuen interaktiven Checkout aus\. ## Schritt 2\. Warten und erfolgreiche Zahlung unterscheiden {#schritt-2-warten-und-erfolgreiche-zahlung-unterscheiden} Treffen Sie Ihre Entscheidung anhand des Rechnungsfelds ` status `\: - ` pending ` – die Zahlung wird erwartet\; ` seen ` – eine Überweisung wurde erkannt\, die Zahlung ist aber noch nicht abgeschlossen\; - ` partial ` – ein Teilbetrag ist bestätigt\, die Wartephase läuft nach den Zahlungsregeln weiter\; - ` underpaid `\, ` overpaid `\, ` late ` – eine Prüfung ist erforderlich\; berücksichtigen Sie ` needs_decision ` und die Entscheidung des Verkäufers\; - ` paid ` – die Rechnung ist als bezahlt verbucht\; nach Prüfung der Auftragszuordnung können Sie die Ausführung vorbereiten\; - ` expired `\, ` canceled ` – beenden Sie die aktive Wartephase des Käufers\, bewahren Sie den Datensatz aber für spätere Abgleiche auf\. Ein Fristablauf schließt einen verspäteten Eingang nicht aus\. Auch eine manuelle Entscheidung und ein Transaktionsrollback können die weitere Behandlung ändern\. Erklären Sie keinen Zustand für dauerhaft endgültig und löschen Sie beim Schließen der Seite nicht die Zuordnung zwischen Auftrag und Rechnung\. Eine bestätigte Transaktion und eine bezahlte Rechnung sind unterschiedliche Dinge\. Bestätigungen belegen nicht\, dass der erforderliche Vermögenswert\, Betrag und die Zahlungsdaten genau zu diesem Auftrag gehören\. Die [Anleitung zur Prüfung eines unbezahlten Auftrags]() erläutert diese Unterschiede\. ## Schritt 3\. Betrag und Zahlungsversuch berücksichtigen {#schritt-3-betrag-und-zahlungsversuch-ber-cksichtigen} Beim Wechsel der Zahlungsart können zu einer Rechnung mehrere Versuche entstehen\. Berücksichtigen Sie bei einer bezahlten Rechnung ` settled_attempt_id ` und ` settled_attempt `\. Prüfen Sie beim Durchsehen des Verlaufs ` attempt_history.has_more ` und den Fortsetzungscursor\; verwenden Sie für Überweisungen des gewählten Versuchs ` payment_history `\. Die erste Seite enthält nicht zwangsläufig den vollständigen Verlauf\. ` amount ` ist der genaue zu sendende Kryptobetrag\. ` amount_raw ` und ` paid ` sind Zeichenfolgen mit Ganzzahlen in den kleinsten Einheiten des Vermögenswerts\; ` decimals ` legt die Skalierung fest\. Vergleichen Sie sie weder als Gleitkommazahlen noch alphabetisch wie gewöhnliche Zeichenfolgen\. Ihre eigene Betragsprüfung darf den Rechnungsstatus und die Projektregeln nicht ersetzen\: Eine Überzahlung kann angenommen oder zur Prüfung weitergeleitet werden\. Auch Unterzahlungen dürfen Sie nicht ohne Prüfung der Bedingungen zusammenrechnen\. ## Schritt 4\. Polling und Wiederholungen begrenzen {#schritt-4-polling-und-wiederholungen-begrenzen} Stellen Sie Prüfungen in eine serverseitige Warteschlange mit begrenzter Parallelität\. Mehrere Browser\-Tabs des Käufers dürfen keine unabhängigen Abfrageschleifen erzeugen\. Berücksichtigen Sie den gesamten Datenverkehr des Kontos\: Verschiedene API\-Schlüssel und Modi teilen sich das Kontingent\. Die aktuellen Grenzen finden Sie in der [API\-Referenz]()\. Wählen Sie Wartezeiten passend zu Ihrem Ablauf und lassen Sie Spielraum für andere Anfragen\. Verwenden Sie bei Netzwerkfehlern oder HTTP 500\/503 begrenzte Wiederholungen mit zunehmender Verzögerung und zufälliger Streuung\. Verringern Sie bei HTTP 429 den gesamten Anfrageverkehr\; ist ` Retry-After ` vorhanden\, halten Sie die angegebene Pause ein\. Ein fehlender Header darf nicht zu einer sofortigen Wiederholung führen\. Jede Anfrage benötigt einen Timeout und jede Wiederholungsserie eine Grenze\, nach der die Aufgabe für eine spätere Prüfung erhalten bleibt\. HTTP 401\/403 erfordern eine Prüfung des Schlüssels und seiner Berechtigungen\. Prüfen Sie bei 404 die ID\, das Projekt und den Modus\: Zugriffsbeschränkungen können eine Rechnung verbergen\. Diese Fehler bedeuten nicht\, dass der Kunde nichts bezahlt hat\. ## Schritt 5\. Ausführung und Wiederaufnahme dauerhaft speichern {#schritt-5-ausf-hrung-und-wiederaufnahme-dauerhaft-speichern} Speichern Sie bei ` paid ` den Auftragsstatus und die Ausführungsaufgabe konsistent\. Verwenden Sie einen eindeutigen Auftragsschlüssel und Schutz vor paralleler Verarbeitung\. Ein erneuter Abruf von ` paid ` darf Zugang oder Ware nicht erneut ausgeben\; ein Fehler nach der Übergabe darf keine zweite Ausführung erzeugen\. Halten Sie die letzte erfolgreiche Prüfung und die nächste Aufgabe in einem dauerhaften Speicher fest\. Nehmen Sie nach einem Neustart offene Prüfungen und Aufgaben wieder auf\, statt den Ablauf erst beim Öffnen der Seite zu starten\. Begrenzen Sie die aktive Wartephase nach den Fristen Ihres Prozesses\; ein separater Hintergrundabgleich muss verspätete Zahlungen\, Entscheidungen und Rollbacks berücksichtigen\, auch bei bereits bezahlten Aufträgen\. Prüfen Sie unmittelbar vor einer noch ausstehenden Ausführung erneut\, ob sie erlaubt ist\; sehen Sie für bereits erteilte Zugänge eine erneute Prüfung vor\. Prüfen Sie mit vorbereiteten Antworten ein wiederholtes ` paid `\, einen Timeout\, einen Neustart und einen Übergang nach einem Rollback\. Das Ergebnis ist korrekt\, wenn der Auftrag einmal ausgeführt wird und eine unklare oder strittige Zahlung in Prüfung bleibt\. Später können Sie Polling durch einen [Webhook]() ergänzen und dabei denselben Ausführungsschutz beibehalten\. Schlagwörter: [Zahlungen](https://cryptanio.com/de/wiki/tag/payments/), [API](https://cryptanio.com/de/wiki/tag/api/) ## Verwandte Artikel - [Was ist eine Zahlungsrechnung](https://cryptanio.com/de/wiki/was-ist-eine-rechnung/) - [Was ist eine TXID und wo findet man die Transaktions\-ID\?](https://cryptanio.com/de/wiki/transaktions-id-txid/) - [Warum eine Bestellung nach dem Senden von Kryptowährung unbezahlt bleibt](https://cryptanio.com/de/wiki/bestellung-nach-kryptozahlung-nicht-bezahlt/)