Ein Aufruf der Security Deposits API kann erfolgreich sein, obwohl Ihr Buchungssystem keine Antwort erhält. Wiederholen Sie dieselbe Erstellung mit unverändertem Inhalt und demselben `Idempotency-Key`. Laut PayRequest-Dokumentation wird dadurch die ursprüngliche Kautionsanfrage zurückgegeben.
Dieser Leitfaden richtet sich an Entwickler von Vermietungssoftware. Die API-Einführung beschreibt den gesamten Ablauf.
Wie wird eine Kautions-API-Wiederholung zuverlässig?
Unterscheiden Sie Buchungsreferenz, Kautionsverpflichtung und Netzwerkversuch. Speichern Sie für die fiktive Buchung RENT-104 etwa `rent-104-deposit-v1` und den vollständigen Inhalt vor `POST /api/v1/deposits`. Ordnen Sie anschließend Kautions-ID und authorization_url der Buchung zu, bevor Sie den Kundenlink versenden.
Die PayRequest-Referenz beschreibt OAuth und billing.write für die Erstellung. Tokens gehören auf den Server. Ein erstellter Link beweist noch keine reservierten Mittel.
Nutzen Sie diesen Wiederherstellungsplan
Die Tabelle ist eine Empfehlung für die Integration und kein Bericht über durchgeführte Tests.
| Situation | Nächster Schritt | Vermeiden |
|---|---|---|
| Erstellung liefert eine ID | ID und Link speichern | Neue Kaution für einen erneuten Nachrichtenversand |
| Erstellung läuft in ein Timeout | Gleichen Inhalt und Schlüssel wiederholen | Zufälligen Schlüssel je Versuch |
| ID bereits bekannt | Aktuellen Datensatz abrufen | Fehlenden Webhook als fehlende Reservierung deuten |
| Betrag oder Termine ändern sich | Bestehende Kaution und Ersatzprozess prüfen | Geänderten Inhalt mit altem Schlüssel senden |
| Capture-Antwort fehlt | Status vor weiterer Aktion abrufen | Erstellungsgarantien auf Capture übertragen |
Beispiel: Eine €500-Anfrage für RENT-104 läuft in ein Timeout. Mit demselben Schlüssel soll die ursprüngliche Anfrage zurückkommen. Koordinieren Sie zusätzlich parallele Worker durch eine Datenbanktransaktion oder eine eindeutige lokale Kautionsverpflichtung.
Welche Garantien sind dokumentiert?
Die öffentliche Referenz beschreibt Idempotency bei Erstellung, aber keine allgemeine Aufbewahrungsfrist und keine identische Garantie für Capture oder Freigabe. Übertragen Sie Stripes Idempotency-Regeln nicht automatisch auf PayRequest.
Bei bekannter ID nutzen Sie `GET /api/v1/deposits/{id}`. Der Filter booking_reference hilft bei verlorener Erstellungsantwort. Prüfen Sie Status und tatsächliche Anbieterfrist vor einem Ersatzlink. Protokollieren Sie Referenz, Schlüssel, ID, Zeitpunkt und Ergebnis ohne Tokens oder Kartendaten.
Was prüfen Sie vor dem Start?
Simulieren Sie eine verlorene Antwort und zwei konkurrierende Worker. Erwarten Sie eine Kautionszuordnung und eine Kundennachricht. Für diesen Artikel wurde keine Live-Autorisierung durchgeführt.
Nutzen Sie PayRequest-Kautionen, halten Sie Mietzahlungen über Zahlungslinks getrennt und prüfen Sie Tarife und Grenzen. Der Webhook-Leitfaden behandelt die Statussynchronisierung.
Redaktioneller Hinweis: KI unterstützte Text und Titelbild. Die öffentliche Dokumentation wurde am 13. Oktober 2026 geprüft. Der Wiederherstellungsplan ist eine eigene Gestaltungsempfehlung.
