Annulation d'une commande API lorsque le client a envoyé un lien incorrect

Vérifiez d'abord si la commande a été transmise au fournisseur

Un lien incorrect ne signifie pas toujours que la promotion a déjà démarré. Dans votre base interne, la commande peut être créée mais pas encore envoyée via l'API. Dans ce cas, l'annulation ne dépend que de votre logique de traitement : il suffit de marquer la commande comme annulée, d'arrêter le paiement automatique et de ne pas lancer la transmission.

Vérifiez l'identifiant de la commande, la date de création, le lien, le type de service et le journal des requêtes API. Si la requête au fournisseur n'a pas été envoyée, ne créez pas une nouvelle commande par-dessus l'ancienne. Enregistrez d'abord l'annulation de la demande initiale, sinon le client risque d'obtenir deux lancements sur des liens différents.

Déterminez le statut de la commande chez le fournisseur

Si la requête API a déjà été envoyée, demandez le statut actuel au fournisseur. Les noms des statuts varient, mais on peut généralement les regrouper en plusieurs catégories : en attente, en traitement, exécution partielle, terminée et annulée. Pour la décision, ce qui compte n'est pas le statut dans votre panneau, mais la réponse de la partie qui lance le service.

• En attente : la commande peut encore être annulable.
• En traitement : l'arrêt est parfois possible, mais une partie du volume peut déjà être lancée.
• Exécution partielle : seul le reste peut être annulé, si le fournisseur prend en charge cette opération.
• Terminée : corriger le lien par une annulation n'est plus possible.

L'inconvénient de vérifier uniquement le statut interne est qu'il peut être mis à jour avec du retard. Fiez-vous à la dernière réponse API et à l'heure de sa réception.

Annulez la commande avant le lancement du service

Pour une commande en file d'attente, utilisez la méthode d'annulation si elle est prévue par la documentation du fournisseur. Transmettez l'identifiant obtenu lors de la création de la commande, et non votre numéro interne s'il s'agit de valeurs différentes. Conservez la réponse complète : code de l'opération, statut, texte de l'erreur et heure de la requête.

Ne considérez pas la commande comme annulée tant que l'API n'a pas confirmé l'annulation. La réponse d'acceptation de la requête et l'arrêt effectif du service peuvent être deux événements distincts. Dans certaines intégrations, une confirmation d'acceptation arrive d'abord, et le statut final change plus tard.

L'inconvénient de cette option est que le fournisseur peut ne pas avoir le temps de retirer la commande du traitement. L'annulation renverra alors un refus ou ne s'appliquera qu'à la partie non exécutée.

Ne modifiez pas le lien d'une commande déjà créée sans confirmation

Dans de nombreuses API, le lien est figé au moment de la création de la commande. Tenter de transmettre un nouveau lien avec le même identifiant peut être ignoré, traité comme une erreur ou créer un état imprévisible. Ne comptez pas sur le fait que le renvoi de la requête remplacera automatiquement l'adresse.

Si la documentation prend explicitement en charge la modification du lien, assurez-vous d'abord que le service n'a pas encore commencé à s'exécuter. Ensuite, conservez l'ancienne valeur, la nouvelle valeur et la réponse API. Cela sera utile en cas de litige avec le client ou le fournisseur.

L'inconvénient de la modification est que, même avec une méthode disponible, une partie des actions a pu être dirigée vers l'ancienne page avant la mise à jour. Le lien corrigé ne transfère pas le résultat déjà obtenu.

Que faire en cas d'exécution partielle

Lorsque la promotion a déjà commencé sur un lien incorrect, demandez l'annulation du reste. Dans votre demande au fournisseur, indiquez l'identifiant de la commande, le lien incorrect, le lien correct, le statut actuel et l'heure de détection de l'erreur. Ne modifiez pas plusieurs fois les détails de la demande : cela complique la vérification de l'historique.

Si l'annulation du reste est confirmée, enregistrez le volume déjà exécuté. Le remboursement, s'il est prévu par les règles du fournisseur, ne concerne généralement que la partie non exécutée. Le volume exécuté ne peut pas être techniquement transféré d'une chaîne, d'une vidéo ou d'un profil à un autre.

L'inconvénient de l'annulation partielle est évident : le client peut déjà avoir obtenu un résultat sur la page incorrecte, et le budget de cette partie de la commande n'est pas toujours remboursé.

Si la commande est terminée, formulez la correction dans une demande distincte

Une commande terminée ne peut généralement pas être annulée via l'API. Dans ce cas, ne supprimez pas l'enregistrement et ne modifiez pas le lien dans l'historique : les données d'origine sont nécessaires pour la vérification. Vérifiez si le service a réellement été fourni à l'adresse erronée, et non simplement affiché avec du retard.

Ensuite, deux options se présentent : discuter d'une compensation avec le fournisseur selon ses règles, ou créer une nouvelle commande sur le lien correct après accord avec le client. La nouvelle commande doit avoir un identifiant distinct, un montant et une mention claire de la raison de sa création.

L'inconvénient d'un nouveau lancement est qu'il nécessite un budget supplémentaire, et qu'une compensation pour un service terminé peut être indisponible.

Informez le client de la situation avant tout nouveau lancement

Ne lancez pas de remplacement de votre propre initiative si le lien appartient au client et que l'erreur vient de son côté. Envoyez-lui le lien d'origine, le statut de la commande, la possibilité d'annulation et les conséquences de chaque option. C'est particulièrement important si une partie du service a déjà été exécutée.

• Si la commande n'a pas été transmise, demandez le lien correct et confirmez l'annulation de l'ancienne demande.
• Si la commande est en file d'attente, indiquez que l'annulation a été envoyée mais que la réponse du fournisseur est attendue.
• S'il y a une exécution partielle, précisez que seul le reste peut être arrêté.
• Si la commande est terminée, convenez d'un nouveau lancement ou d'une autre solution.

L'inconvénient d'une concertation prolongée est que, pendant ce temps, la commande en file d'attente peut passer en traitement. C'est pourquoi il faut d'abord envoyer la requête technique d'annulation si cette possibilité existe, puis préciser les actions suivantes.

Conservez les logs et les preuves de l'opération

Pour chaque commande litigieuse, conservez le lien d'origine fourni par le client, la date de réception, le numéro interne, l'identifiant chez le fournisseur, les requêtes API et les réponses. Si le client a envoyé le lien dans une conversation, ne remplacez pas le message par une version modifiée dans la fiche de commande sans conserver l'original.

Notez séparément qui a remarqué l'erreur et quand. Cela aide à distinguer les données transmises de manière erronée d'une erreur du gestionnaire, du formulaire de commande ou d'une substitution automatique. Lors de demandes répétées au fournisseur, utilisez une seule chaîne de données pour éviter les contradictions.

L'inconvénient de la tenue manuelle de logs est qu'elle prend du temps. Mais sans historique, il est plus difficile de confirmer le statut de l'annulation et d'expliquer au client pourquoi les fonds ne peuvent pas être entièrement remboursés.

Vérifiez la gestion des erreurs dans l'intégration

Après un tel incident, vérifiez comment le système transmet les liens à l'API. L'erreur peut ne pas venir uniquement du client : parfois le formulaire tronque les paramètres, substitue une ancienne valeur du cache, accepte un lien de profil au lieu d'un lien de publication ou laisse passer un lien contenant des caractères superflus.

Ajoutez une vérification du format avant la création de la commande : conformité à la plateforme, au type de service et à l'objet attendu. Pour les services sur vidéo, le système doit distinguer le lien d'une vidéo de celui d'une chaîne, et pour les réseaux sociaux, le profil d'une publication individuelle. La vérification ne garantit pas l'exactitude du lien, mais élimine une partie des erreurs manifestes.

Il est préférable de séparer la transmission de la commande de sa création par une courte vérification des données. L'inconvénient de cette étape supplémentaire est que la commande ne partira pas en traitement instantanément, mais vous aurez le temps de remarquer une adresse incorrecte.

Établissez un scénario d'annulation clair pour l'équipe

Décrivez une procédure unique : arrêter l'envoi automatique, vérifier le statut chez le fournisseur, envoyer l'annulation, conserver la réponse, informer le client et seulement ensuite convenir d'un nouveau lancement. Ce scénario n'est pas une formalité : il évite que différents collaborateurs effectuent des actions mutuellement exclusives.

Ne donnez pas accès à l'annulation sans restriction des droits et sans journal des actions. Si plusieurs gestionnaires travaillent simultanément sur une même commande, l'un peut demander l'annulation tandis que l'autre crée un remplacement avant d'avoir reçu la réponse. Cela entraîne des dépenses inutiles et de la confusion dans les calculs.

L'inconvénient d'un scénario strict est une moindre flexibilité dans les cas urgents. Mais pour les commandes API, ce qui compte le plus n'est pas la rapidité d'une action isolée, mais le contrôle du lien qui a effectivement été mis en traitement.