Test vóór livegang de hele Security Deposits API-workflow: aanmaken, klantautorisatie, statussynchronisatie, ondersteunde afschrijving en vrijgave. Een succesvolle aanmaakrespons bewijst niet dat er geld is gereserveerd.
Deze checklist is een voorgesteld acceptatieplan voor verhuursoftware, geen certificering of rapport van uitgevoerde tests.
Bereid een gecontroleerde borg-API-test voor
Bevestig de ondersteunde testconfiguratie bij PayRequest en je provider. Gebruik fictieve klanten en ondersteunde testgegevens; veronderstel geen afzonderlijk PayRequest-sandboxadres. De API-referentie vereist billing.read voor ophalen en billing.write voor aanmaken, capture en vrijgave. Houd OAuth-tokens op de server en bewaar de oorspronkelijke requestbody voor handtekeningcontrole.
Gebruik fictieve boeking TEST-104 met €350 borg. Bewaar referentie, borg-ID, provider, status, captured_amount en capture_before. Maak afzonderlijke testboekingen voor capture en vrijgave omdat beide de reservering beëindigen.
Doorloop deze borg-API-acceptatiematrix
De verwachte uitkomsten volgen de gedocumenteerde Stripe-route. Controleer ondersteuning voor je account en betaalmethode.
| Scenario | Verwachte controle |
|---|---|
| Twee aanmaakpogingen, dezelfde sleutel | Eén borgkoppeling en één klantbericht |
| Klant heeft niet geautoriseerd | Pending; overdrachtsscherm toont geen gereserveerd geld |
| Autorisatie wordt verwerkt | Pending en metadata indien beschikbaar; geen automatische vervanging |
| Autorisatie voltooid | Authorized en werkelijke capture_before |
| €150 capture uit €350 Stripe-borg | Captured; €200 vrijgegeven, geen tweede capture |
| Tweede capture na lokale finalisatie | Gedocumenteerde HTTP 409; geen tweede afschrijving |
| Andere actieve borg vrijgeven | Released; klantbericht noemt vrijgave |
| Dubbele of late webhook | Geen herhaalde actie of teruggezette eindstatus |
Bewaar controleerbare aanvraag- en responsreferenties zonder geheimen of kaartgegevens. Een screenshot helpt bij beoordeling; de actuele API-status onderbouwt de financiële uitkomst.
Test boekingswijzigingen apart
Verander de retourdatum en controleer dat je systeem de autorisatiedeadline niet stilzwijgend verlengt. Stripe beschrijft dat capture vóór de echte deadline moet gebeuren. Laat een medewerker beoordelen wanneer de nieuwe retourdatum te dicht bij die deadline komt.
Schrijf de hele borg niet automatisch af om verloop te voorkomen. Overeenkomst, inspectie en ondersteunde provideractie bepalen de beslissing. Houd huurprijs via betaallinks, boekingsbeschikbaarheid en borgstatus gescheiden.
Controleer onduidelijke antwoorden vóór retries
Simuleer een verloren aanmaakantwoord en hergebruik de opgeslagen sleutel. Haal bij een verloren capture- of vrijgaveantwoord eerst de actuele borg op. Aanmaak-idempotency bewijst geen garantie voor andere acties. Gebruik het herstelplan voor retries.
Pending kan metadata over verwerking of een verlopen poging bevatten; expired betekent dat een eerder bevestigde reservering verliep. Laat medewerkers dit verschil controleren.
Wanneer is de pilot gereed?
Vraag bewijs per testscenario, een verantwoordelijke voor uitzonderingen en klantteksten die de bevestigde status volgen. Controleer ook mobiel, afwijzing van ongeldige handtekeningen, accountscheiding en lees- versus schrijfrechten.
Begin met PayRequest borgverzoeken, controleer abonnementen en limieten en gebruik de API-referentie als contract.
Redactionele toelichting: AI hielp bij tekst en illustratie. Documentatie is bekeken op 13 oktober 2026. De matrix is oorspronkelijke begeleiding; er zijn geen live financiële acties uitgevoerd.
