Een verzoek aan de Security Deposits API kan slagen terwijl je boekingssysteem het antwoord niet ontvangt. Herhaal dezelfde logische aanmaak met dezelfde `Idempotency-Key` en ongewijzigde gegevens. PayRequest documenteert dat deze herhaling het oorspronkelijke borgverzoek teruggeeft.
Dit stappenplan is voor ontwikkelaars van verhuur- en reserveringssoftware. De algemene API-uitleg beschrijft de volledige workflow.
Hoe maak je een borg-API-retry betrouwbaar?
Scheid de boekingsreferentie, de borgverplichting en de afzonderlijke netwerkpoging. Bewaar voor fictieve boeking RENT-104 bijvoorbeeld de sleutel `rent-104-deposit-v1` en de exacte aanvraag vóór `POST /api/v1/deposits`. Sla daarna het borg-ID en de authorization_url op. Verstuur de klantlink pas wanneer die koppeling is bewaard.
De API-documentatie beschrijft OAuth en billing.write voor aanmaken. Bewaar tokens op de server. Een aangemaakte link betekent nog niet dat geld is gereserveerd.
Gebruik dit hersteloverzicht bij time-outs
Dit overzicht is een ontwerpaanbeveling voor je integratie; het zijn geen gerapporteerde testresultaten.
| Situatie | Volgende stap | Vermijd |
|---|---|---|
| Aanmaken geeft een borg-ID terug | Bewaar ID en klantlink | Een nieuwe borg maken om een bericht opnieuw te sturen |
| Aanmaken geeft een time-out | Herhaal dezelfde gegevens en sleutel | Een willekeurige sleutel per poging |
| Borg-ID is al bekend | Haal actuele status op | Ontbrekende webhook gelijkstellen aan ontbrekende borg |
| Bedrag of datums veranderen | Beoordeel de bestaande borg en vervangingsroute | Andere gegevens onder een oude sleutel |
| Capture geeft een time-out | Haal status op vóór een nieuwe actie | Aanmaakgaranties toepassen op capture |
Stel dat de aanvraag voor €500 bij RENT-104 een time-out geeft. Met dezelfde sleutel hoort PayRequest het oorspronkelijke verzoek terug te geven. Gebruik daarnaast een database-transactie of unieke borgverplichting om twee gelijktijdige workers te coördineren. De API vervangt deze lokale controle niet.
Welke garanties zijn gedocumenteerd?
De openbare referentie beschrijft idempotency bij aanmaken, maar geen universele bewaartermijn of dezelfde garantie voor capture en vrijgave. Neem regels uit Stripe-idempotency niet automatisch over voor PayRequest.
Gebruik `GET /api/v1/deposits/{id}` bij een bekend ID. Het filter op booking_reference kan helpen wanneer het antwoord verloren ging. Controleer actuele status en providerdeadline voordat je een vervangende link stuurt. Bewaar referentie, sleutel, ID, pogingstijd en uitkomst; houd tokens en kaartgegevens buiten logs.
Wat controleer je vóór livegang?
Simuleer een verloren antwoord, herhaal dezelfde sleutel en controleer één borgkoppeling en één klantbericht. Controleer ook gelijktijdige workers en een aangepaste boeking. Er is voor dit artikel geen live autorisatie uitgevoerd.
Gebruik PayRequest borgverzoeken, houd de huurprijs apart via betaallinks en controleer abonnementen en limieten. De webhookhandleiding behandelt de volgende stap.
Redactionele toelichting: AI hielp bij tekst en illustratie. De openbare documentatie is gecontroleerd op 13 oktober 2026. Het hersteloverzicht is een oorspronkelijke ontwerpaanbeveling.
