Renvoyer les notifications de paiement confirmé

POST /api/v1/webhooks/resend

Demander une authentification

Inclut X-Bolt-Key, X-Bolt-Timestamp et X-Bolt-Signature. Utilisez un timestamp actuel en millisecondes et signez-le avec le corps exact de la demande.

Quand renvoyer

Utilisez ce point de terminaison lorsque votre système a besoin d'une autre notification d'un paiement confirmé. Le renvoi ne permet pas de collecter le paiement, de rapprocher un transfert ou de créer une commande.

Seules vos propres commandes CONFIRMED ou COMPLETED peuvent être renvoyées. PENDING, PAID et les autres États ne sont pas éligibles.

Une configuration Webhook disponible et active est requise. Si aucune tâche de livraison n'est persistante, le point de terminaison renvoie une erreur au lieu de QUEUED.

01. Paramètres de la requête

application/json

externalOrderIdObligatoire

String

Envoyer le marchand externalOrderId fourni à la création de la commande, et non orderToken. Vous ne pouvez renvoyer des notifications que pour les commandes appartenant à la clé API actuelle.

Exemple de valeur

{"externalOrderId": "INV-20260209-99281"}

Chaîne obligatoire, 6 à 64 caractères. Les lettres, chiffres, traits de soulignement (_) et tirets (-) sont autorisés.

Body

02. Champs de réponse (data)

application/json

notifyUrlString

Adresse de rappel enregistrée sur la commande ; peut être null. La livraison préfère cette adresse et revient à la configuration Webhook associée pour les commandes plus anciennes qui n'en possèdent pas.

externalOrderIdString

Commande marchand ID associée à ce renvoi, correspondant à la demande externalOrderId.

triggerTypeEnum

Toujours MANUAL dans la réponse de ce point de terminaison, indiquant un renvoi demandé par le commerçant. Il ne s'agit pas du type de règlement des paiements.

statusEnum

Renvoyer le statut de la demande. QUEUED signifie que la tâche a été conservée ; il ne s'agit ni du statut de paiement ni d'une preuve de livraison.

QUEUED signifie que la tâche d’envoi a été enregistrée pour un envoi asynchrone, et non que la notification est arrivée. Vérifiez les journaux d’envoi du tableau de bord marchand et la réponse HTTP 2xx du destinataire.

🚀

Gestion des destinataires

Vérifiez X-Bolt-Webhook-Timestamp et X-Bolt-Webhook-Signature, puis dédupliquez par eventId ou par commande marchand ID avant l'exécution. Renvoyez HTTP 2xx pour les notifications en double qui ont déjà été traitées avec succès.

triggerType : MANUAL apparaît dans la réponse de renvoi et les enregistrements de livraison du tableau de bord. Le corps actuel de la requête Webhook ne contient pas triggerType ; ne comptez pas sur lui pour identifier un renvoi.
Chaque appel réussi crée une tâche de livraison indépendante. Les demandes répétées peuvent envoyer plusieurs notifications. Vérifiez les journaux de livraison avant de renvoyer à nouveau. Les rediffusions conservent le eventId logique.
Ce point de terminaison réutilise la destination de rappel de la commande et n'accepte pas un nouveau URL. La modification de la valeur par défaut du tableau de bord ne remplace pas une adresse déjà enregistrée sur la commande.

Safe

Erreurs courantes

Ce sont des cas courants. Utilisez l'état actuel du HTTP et le code/message de réponse pour diagnostiquer les pannes. Une réponse d'erreur n'est pas un résultat de paiement.

401 : Vérifiez la clé API, la signature du corps brut et la milliseconde actuelle du timestamp (dans les 5 minutes suivant l'horloge du serveur).
404 : La commande est manquante, appartient à un autre commerçant ou est en dehors de l'historique autorisé par votre forfait.
400 : La commande n'est pas CONFIRMED / COMPLETED, ou une configuration Webhook disponible et une tâche de livraison stockée avec succès sont manquantes.