Litiges
Quand un payeur conteste un paiement, comment vous répondez, et ce qu'une perte vous coûte.
Un litige, c'est un payeur, ou son réseau de carte, qui conteste l'un de vos paiements : vous y répondez, et il se termine soit avec l'argent conservé, soit avec votre solde débité. Vous ne pouvez pas en créer un par l'API.
Les endpoints de litige exigent la clé secrète
Chaque appel de cette section exige une clé secrète et répond 406 Not Acceptable
avec Private Key Required à une clé publique. Ces appels ont leur place sur votre serveur.
Deux pages vont plus loin :
- Répondre à un litige, avec des justificatifs, en concédant, ou en échangeant avec le payeur.
- Suivre les litiges, les consulter et les webhooks qu'ils envoient.
D'où vient un litige
Un litige vous parvient de l'un de deux endroits.
Le payeur fait passer une demande de remboursement en litige depuis Pocket, le portefeuille Wajub où il retrouve les paiements qu'il a effectués. Un problème y commence par une demande de remboursement qui vous est adressée. Le payeur peut la transformer en litige une fois que vous l'avez refusée, pendant 30 jours après votre réponse, ou quand elle attend depuis 7 jours sans réponse. Il choisit un motif, et le texte de sa demande devient le premier message du fil de discussion du litige.
| Motif choisi par le payeur | Ce qu'il affirme |
|---|---|
product_not_received | Il a payé et rien n'est arrivé |
product_not_as_described | Ce qui est arrivé ne correspond pas à ce qui était vendu |
duplicate_charge | Il a été débité deux fois pour la même chose |
fraudulent | Il n'a pas effectué ce paiement |
other | Tout autre cas, expliqué dans la description |
Un litige ouvert depuis Pocket porte sur le montant demandé par le payeur, plafonné à ce qui reste
sur le paiement une fois retirés ses remboursements et les rétrofacturations que vous avez perdues,
et porte un due_date avant lequel répondre, sept jours après son ouverture.
Le prestataire signale une rétrofacturation. Quand un réseau de carte ou un prestataire notifie
une rétrofacturation sur l'un de vos paiements, Wajub ouvre un litige pour elle. Il porte la
référence du prestataire dans provider_reference, son code de motif dans reason, et le montant
que le prestataire conteste, qui peut être inférieur au paiement. Il porte aussi un due_date :
l'échéance du prestataire quand il en envoie une, sept jours après l'ouverture sinon.
Un avis ultérieur pour la même rétrofacturation, avec le même provider_reference, met à jour son
litige au lieu d'en ouvrir un second, même une fois qu'il est tranché. Une rétrofacturation qui
arrive pendant qu'un litige du payeur ouvert depuis Pocket est en cours sur le paiement ouvre son
propre litige. Le payeur ne peut pas faire passer une demande en litige pendant qu'une
rétrofacturation est en cours sur le paiement, ni ouvrir un second litige depuis Pocket sur ce
paiement.
Les litiges n'existent pas en sandbox
Les litiges viennent de vrais payeurs et de vrais prestataires : un paiement de test n'en produit donc jamais. Ce parcours ne peut pas être répété de bout en bout avant de passer en live. Construisez votre handler à partir des payloads de cette page, puis vérifiez-le sur le premier vrai litige que vous recevez.
Le montant est bloqué tant que le litige est ouvert
Un litige ouvert depuis Pocket, sur un paiement que Wajub a encaissé pour vous, fait passer le montant contesté de votre solde disponible à votre solde en litige, dans la limite de votre solde disponible. Gagner le rend disponible. Perdre le débite, comme décrit plus bas.
Les états d'un litige
Un litige arrive en open. L'envoi de justificatifs le fait passer de lui-même en under_review,
vous ne réglez pas ce statut vous-même. Depuis l'un ou l'autre de ces deux états, il peut se
terminer en won ou en lost. Sur un litige ouvert depuis Pocket, les deux sont définitifs.
C'est Wajub qui tranche un litige ouvert depuis Pocket, et la banque du payeur une rétrofacturation. Aucun endpoint ne vous permet de vous déclarer gagnant ; ce que vous pouvez faire, c'est présenter les justificatifs à ceux qui décident, ou concéder.
Comment une rétrofacturation est tranchée
La banque du payeur tranche une rétrofacturation, par l'intermédiaire du prestataire, et le litige
suit la décision que le prestataire signale. Une décision fixe status et resolved_at, avec
metadata.decided_by à provider et metadata.provider_stage, le nom de l'étape du prestataire
qui a tranché.
| Ce que signale le prestataire | Ce que devient le litige |
|---|---|
| Un gain | open ou under_review passe en won |
| Une perte | open, under_review ou won passe en lost : une rétrofacturation gagnée peut encore être perdue à une étape ultérieure |
| Une nouvelle étape de rétrofacturation qui reprend les fonds, après un gain | won repasse en open : resolved_at est effacé, due_date est fixé de nouveau, à l'échéance du prestataire ou sept jours plus tard, et metadata.reopened_at en garde la date |
lost est définitif : un gain signalé après une perte ne change rien. Chaque changement envoie
dispute.updated, avec dispute.won pour un gain, ou dispute.lost et dispute.closed pour une
perte. Un litige rouvert n'envoie que dispute.updated, et son rappel d'échéance est envoyé de
nouveau.
Ce que coûte une perte
Sur un paiement que Wajub a encaissé pour vous, un litige perdu retire le montant contesté de votre solde, plafonné à ce qui n'est pas déjà sorti par un remboursement sur le même paiement, pour que l'argent ne puisse pas être pris deux fois. Sur un paiement encaissé par votre propre compte chez un prestataire, Wajub ne détient pas l'argent, et le prestataire règle la rétrofacturation directement avec vous.
Des frais de litige forfaitaires s'ajoutent, 15 000 XAF par défaut dans la devise du litige,
quand la perte vient de l'API, avec accept ou close, ou d'une rétrofacturation du prestataire.
Accepter depuis le Dashboard ne les facture pas. Perdre un litige de 25 000 XAF par l'API coûte donc
40 000 XAF, et non 25 000. Les débits ont lieu au changement de statut lui-même, pas lors d'un appel
que vous feriez ensuite, et une seule fois par litige : une rétrofacturation perdue après un gain ou
une réouverture n'est débitée qu'une fois.
Un litige ne change pas le statut du paiement d'origine. Quand vous acceptez, le remboursement que
Wajub crée pour le payeur est un remboursement ordinaire, avec ses propres événements refund.*,
et il apparaît sur le paiement comme n'importe quel autre. Il ne retire pas le montant contesté une
seconde fois. Si le payeur a payé les frais Wajub en plus du prix (bearer: customer), ces frais
vous sont débités aussi, puisque le payeur récupère tout ce qu'il a payé. Le mouvement
d'argent apparaît sur votre solde, et c'est là que vous le rapprochez.
Les remboursements attendent la fin d'une rétrofacturation
Tant qu'une rétrofacturation est open ou under_review sur un paiement, aucun remboursement de ce
paiement n'est effectué : la banque du payeur peut rendre l'argent elle-même. POST /refunds
répond 422 avec ce message :
Transaction cannot be refunded while a chargeback is open: the payer's bank may return the funds itself. It can be refunded again once the dispute is decided.
Accepter un litige du payeur sur le même paiement échoue avec la même réponse, et le litige reste
tel quel, puisque l'accepter rembourse le payeur. Clôturer un paiement en plusieurs fois avec
outcome: refund répond 409 avec le code chargeback_open. Un litige ouvert depuis Pocket ne
bloque aucun remboursement. Les détails sont dans
Remboursements.
Dans le Dashboard
Litiges les liste avec leur statut et le paiement concerné. Ouvrir un litige vous donne la description du payeur, le fil de messages, et les trois mêmes actions que l'API, plus une qu'elle n'expose pas : vous pouvez marquer ici un litige ouvert depuis Pocket comme gagné quand Wajub a tranché en votre faveur. Une rétrofacturation ne peut pas être marquée gagnée : son prestataire la tranche. La même liste porte les demandes de remboursement que les payeurs envoient depuis Pocket, comme une étape à part.
La section exige la permission manage_disputes, distincte de manage_payments, pour qu'un
coéquipier puisse gérer les commandes sans pouvoir concéder un litige à votre place.
Moins de litiges coûte moins cher que d'en gagner
Un litige vous coûte du temps quelle qu'en soit l'issue, et le travail le plus rentable se fait donc avant qu'il n'existe.
Remboursez de bon gré quand un client se plaint et que vous n'avez pas d'argument : un remboursement que vous choisissez vous coûte le montant, un litige perdu vous coûte le montant plus les frais de litige forfaitaires. Gardez vos preuves de livraison là où vous pouvez les joindre en un clic. Et laissez Shield refuser les paiements les plus susceptibles de se retourner contre vous, puisqu'un paiement refusé d'emblée ne peut pas du tout être contesté.
Pages associées
- Shield, détection de fraudeRefusez les paiements risqués avant qu'ils puissent être contestés.
- RemboursementsRendez l'argent selon vos conditions, pas selon les siennes.
- Solde et règlementsOù atterrit le débit d'un litige perdu.
- WebhooksEnregistrez un endpoint et vérifiez la signature des événements de litige.
- Bonnes pratiques de sécuritéLimitez la fraude côté intégration.
- Référence API des litigesChaque champ de la ressource, et les six endpoints.