Aller au contenu

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.

Deux pages vont plus loin :

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 payeurCe qu'il affirme
product_not_receivedIl a payé et rien n'est arrivé
product_not_as_describedCe qui est arrivé ne correspond pas à ce qui était vendu
duplicate_chargeIl a été débité deux fois pour la même chose
fraudulentIl n'a pas effectué ce paiement
otherTout 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.

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 prestataireCe que devient le litige
Un gainopen ou under_review passe en won
Une perteopen, 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 gainwon 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é.

Que pensez-vous de ce contenu ?