La Verification of Payee dépend d'une réponse distante de la banque du bénéficiaire. Quand cette banque est lente, surchargée ou temporairement injoignable, votre intégration doit décider quoi faire — et cette décision affecte à la fois l'expérience du payeur et votre posture de conformité. Les pires résultats sont un paiement figé ou une vérification discrètement facturée ou comptée deux fois.
Le résultat non disponible est une fonctionnalité
Le schéma définit un résultat non disponible précisément pour que vous n'ayez pas à inventer une sémantique d'erreur. Quand le côté répondant ne peut pas répondre à temps, traitez-le comme un résultat de première classe plutôt que comme une exception.
- Fixez un timeout synchrone aligné sur votre budget de paiement (souvent quelques secondes).
- En cas de dépassement, présentez au payeur un état neutre non disponible plutôt qu'une erreur effrayante.
- Décidez, par politique, si le payeur peut continuer, doit attendre ou doit être orienté vers une revue.
Réessayer en sécurité
Les retries aident pour les défaillances transitoires mais causent des dégâts s'ils ne sont pas idempotents. Un retry ne doit jamais créer une deuxième vérification logique ou un deuxième débit.
- 1 Attachez un identifiant de requête stable à chaque tentative de vérification.
- 2 Réessayez les erreurs réseau transitoires avec backoff exponentiel et un petit plafond.
- 3 Ne réessayez jamais un résultat définitif (correspondance, correspondance partielle, absence de correspondance) — ne réessayez que les vraies défaillances de transport.
- 4 Réconciliez toute réponse tardive avec l'identifiant de requête pour qu'elle soit enregistrée une seule fois.
Budgétez l'attente, puis décidez
Choisissez un budget synchrone défendable devant vos équipes UX et conformité. Au-delà de ce budget, repliez-vous délibérément — affichez en attente ou non disponible — au lieu de laisser la requête pendre et le payeur abandonner.
RoxPay renvoie les résultats standardisés y compris non disponible, prend en charge les retries idempotents par ID de requête, et se replie sur un webhook pour les réponses tardives — pour que votre politique de timeout reste simple.