Une requête Security Deposits API peut réussir sans que votre logiciel de réservation reçoive la réponse. Répétez la même création avec le même `Idempotency-Key` et un contenu inchangé. PayRequest documente le retour de la demande initiale plutôt que la création d’un doublon.
Ce guide s’adresse aux développeurs de logiciels de location. La présentation de l’API décrit le parcours complet.
Comment fiabiliser une nouvelle tentative avec l’API de caution ?
Distinguez référence de réservation, obligation de caution et tentative réseau. Pour la réservation fictive RENT-104, conservez par exemple `rent-104-deposit-v1` et le contenu exact avant `POST /api/v1/deposits`. Enregistrez ensuite l’identifiant de caution et authorization_url avant d’envoyer le lien au client.
La référence PayRequest décrit OAuth et billing.write pour la création. Gardez les jetons sur le serveur. Créer un lien ne prouve pas que des fonds sont réservés.
Utilisez cette grille de reprise
Cette grille est une recommandation de conception, pas un compte rendu de tests.
| Situation | Prochaine action | À éviter |
|---|---|---|
| La création renvoie un identifiant | Enregistrer identifiant et lien | Nouvelle caution pour renvoyer un message |
| La création dépasse le délai réseau | Répéter contenu et clé identiques | Nouvelle clé aléatoire à chaque tentative |
| Identifiant déjà connu | Relire l’état actuel | Confondre webhook absent et réserve absente |
| Montant ou dates modifiés | Examiner la caution et son remplacement | Contenu différent avec une ancienne clé |
| Réponse de capture perdue | Relire l’état avant toute action | Étendre les garanties de création à la capture |
Exemple : une demande de €500 pour RENT-104 expire côté réseau. La même clé doit renvoyer la demande initiale. Coordonnez aussi deux workers simultanés avec une transaction ou une contrainte d’unicité dans votre base de données.
Quelles garanties sont documentées ?
La référence publique décrit l’idempotence de création, mais pas une durée universelle de conservation ni la même garantie pour capture et libération. N’appliquez pas automatiquement les règles de Stripe à PayRequest.
Utilisez `GET /api/v1/deposits/{id}` si l’identifiant est connu. Le filtre booking_reference peut aider après une réponse perdue. Vérifiez état et échéance du prestataire avant un nouveau lien. Journalisez référence, clé, identifiant, heure et résultat sans jetons ni données de carte.
Que vérifier avant le lancement ?
Simulez une réponse perdue et deux workers concurrents. Vérifiez une seule association de caution et un seul message client. Aucune autorisation réelle n’a été effectuée pour cet article.
Utilisez les cautions PayRequest, séparez le loyer avec les liens de paiement et vérifiez offres et limites. Le guide des webhooks couvre la synchronisation.
Note éditoriale : l’IA a aidé à rédiger le texte et l’illustration. Documentation publique vérifiée le 13 octobre 2026. La grille est une recommandation originale.
