Répondre à un litige

Répondre avec des justificatifs

C'est cette étape qui décide de l'issue, et elle mérite d'être soignée. Chaque justificatif est classé sous un type, et vous pouvez faire plusieurs appels pour constituer votre dossier.

Le type est un emplacement, pas une étiquette. Envoyez deux appels avec proof_of_delivery et le second remplace le premier, il ne s'y ajoute pas. Utilisez un type différent pour chaque justificatif distinct, et mettez tout ce que vous voulez dire sur un justificatif dans cet unique appel.

Envoyez un texte, un fichier, ou les deux : un appel sans l'un ni l'autre répond 422, et le litige reste où il était. Sans fichier, le justificatif est enregistré sous la forme de votre seul texte : evidence.proof_of_delivery est alors une chaîne et non un objet. Un fichier est enregistré sous un nom à lui, avec l'extension de son contenu ; le nom que vous lui aviez donné revient dans file_name.

Les fichiers sont privés : aucune adresse ne les ouvre d'elle-même. Chaque réponse de l'API qui renvoie le litige donne à chaque fichier, justificatifs comme pièces jointes des messages, une url, un lien signé valable 30 minutes. Passé ce délai, relisez le litige pour en obtenir un nouveau. Un webhook porte file_path sans lien, car il est conservé et renvoyé bien après l'expiration d'un lien.

Comme un fichier est en jeu, il s'agit d'un envoi de formulaire et non d'un corps JSON.

curl https://api.wajub.com/disputes/dsp_hrgUOE225KMKULRQqYvlh/submit-evidence \
  -H "Authorization: sk.xxxxxxxxxxxxxxxx…" \
  -F "evidence_type=proof_of_delivery" \
  -F "evidence_text=Delivered 12 Sept, signed for by the customer." \
  -F "evidence_file=@/path/to/delivery-note.pdf"

L'appel répond 200 OK avec le litige dans son état actuel, déjà passé en under_review, et vos justificatifs regroupés sous evidence.

Les justificatifs ne peuvent être déposés que tant que le litige est open ou under_review. Une fois en won ou lost, l'appel répond 422 et le dossier est clos.

Concéder, et un appel qui ne fait pas ce que son nom laisse croire

Si le payeur a raison, concédez tôt plutôt que de laisser traîner.

L'acceptation prend un merchant_response facultatif, 2 000 caractères maximum, enregistré sur le litige. Elle passe le litige en lost immédiatement, sans retour possible, et rend l'argent au payeur : Wajub crée un remboursement du montant contesté, plafonné à ce qui reste remboursable sur le paiement.

Ce remboursement porte le motif customer_complaint et le motif du litige dans metadata.dispute_reason, et il rend au payeur tout ce qu'il a payé pour ce montant, y compris des frais qu'il aurait payés en plus. Si le remboursement ne peut pas être créé, l'appel échoue et le litige reste dans son état.

Trois cas ne créent aucun remboursement, et le litige finit quand même lost :

• Une rétrofacturation. La banque du payeur lui a déjà rendu l'argent et le prestataire le reprend à Wajub : un remboursement paierait le payeur deux fois.
• Plus rien à rembourser. Des remboursements antérieurs ont déjà rendu tout le paiement.
• Un litige dans une autre devise que son paiement. Il n'y a pas de montant à rembourser dans la devise du paiement.

Échanger avec le payeur

Un litige porte un fil de messages, ouvert par la description du payeur lui-même. Vous pouvez y répondre.

Les messages prennent content, obligatoire et limité à 5 000 caractères, et un tableau attachments facultatif de fichiers soumis aux mêmes contraintes que les justificatifs. Chaque pièce jointe revient avec file_name, file_path et la même url valable 30 minutes. POST /disputes/{id}/send-message est un alias du même appel. Vos messages sont enregistrés avec un sender_type à merchant, ceux du payeur avec customer, et le fil complet est renvoyé lorsque vous récupérez le litige. Le fil reste ouvert après l'issue : un message sur un litige déjà won ou lost est accepté et enregistré, mais ne change rien au résultat.