Avant le lancement, vérifiez tout le cycle Security Deposits API : création, autorisation du client, synchronisation, encaissement pris en charge et libération. Une création réussie ne prouve pas que des fonds sont réservés.
Cette checklist propose un plan d’acceptation pour logiciels de location. Ce n’est ni une certification ni un rapport de tests exécutés.
Préparer un test contrôlé de l’API de caution
Confirmez la configuration de test avec PayRequest et votre prestataire. Utilisez des clients fictifs et des accès de test pris en charge ; ne supposez pas l’existence d’un hôte sandbox PayRequest distinct. La référence API exige billing.read pour lire et billing.write pour créer, capturer ou libérer. Gardez les jetons côté serveur et les octets bruts pour vérifier les signatures.
Préparez TEST-104 avec une caution fictive de €350. Enregistrez référence, identifiant, prestataire, état, captured_amount et capture_before. Utilisez des réservations différentes pour capture et libération : ces actions terminent la réserve.
Exécuter la matrice d’acceptation
Les résultats attendus suivent le parcours Stripe documenté. Vérifiez la prise en charge par votre compte et le moyen de paiement.
| Scénario | Contrôle attendu |
|---|---|
| Deux créations avec une même clé | Une association et un message client |
| Client sans autorisation | Pending ; ne pas afficher de fonds réservés |
| Autorisation en traitement | Pending et métadonnées disponibles ; pas de remplacement automatique |
| Autorisation terminée | Authorized et échéance capture_before réelle |
| Capture de €150 sur €350 | Captured ; €200 libérés, aucune seconde capture |
| Deuxième capture après finalisation locale | HTTP 409 documenté ; aucun deuxième débit |
| Libération d’une autre réserve active | Released ; message décrivant une libération |
| Webhook doublé ou tardif | Aucune action répétée ni retour à un ancien état |
Conservez les références de requête et réponse sans secrets ni données de carte. Une capture d’écran aide à examiner le parcours ; l’état API actuel établit la situation financière.
Tester séparément les changements de réservation
Modifiez la date de retour et vérifiez que l’autorisation n’est pas prolongée silencieusement. Stripe impose la capture avant l’échéance réelle. Une date trop proche de cette échéance doit déclencher une revue, pas un encaissement total automatique.
Séparez frais de location via les liens de paiement, disponibilité des réservations et caution. Accord, inspection et action prise en charge déterminent la décision.
Examiner une réponse incertaine avant de réessayer
Simulez une réponse de création perdue et réutilisez la clé. Pour capture ou libération, relisez le dossier avant une nouvelle action ; l’idempotence de création ne garantit pas les autres opérations. Consultez le plan de reprise.
Pending peut inclure une tentative expirée ; expired concerne une réserve confirmée devenue indisponible. Vérifiez aussi mobile, rejet des signatures invalides, séparation des comptes et droits de lecture ou écriture.
Pilotez un seul parcours avec les cautions PayRequest et vérifiez offres et limites. Exigez une preuve pour chaque scénario et un responsable des exceptions.
Note éditoriale : texte et illustration assistés par IA. Documentation examinée le 13 octobre 2026. Aucun mouvement financier réel réalisé ; matrice originale proposée.
