Un vendeur refuse après l’autorisation carte : quel montant capturer ?

Un acheteur valide un panier de 260 € réparti entre trois vendeurs. La carte est autorisée, puis l’un des marchands refuse sa sous-commande. Le checkout affiche pourtant « paiement réussi » et le support promet un remboursement de 87 €. Si aucun montant n’a encore été capturé, cette annonce décrit la mauvaise opération. Si les 260 € ont déjà été encaissés, réduire simplement le total affiché laisse au contraire une dette envers l’acheteur.

En pratique, la décision doit partir de l’état financier confirmé et de la composition encore acceptée par l’acheteur. Autorisation, capture, remboursement et transfert au vendeur restent quatre objets distincts. Un refus commercial ne permet pas de déduire lequel a déjà eu lieu, ni de supposer qu’une capture supplémentaire sera possible plus tard.

Nous suivrons un scénario fictif avec trois groupes indépendants, des frais figés et une exécution partielle déjà acceptée. Une recette locale vérifie les six ordres d’arrivée des réponses vendeurs, les notifications répétées et les sorties lorsque le paiement est expiré, inconnu ou déjà capturé. Les résultats calculent des intentions ; aucun débit, remboursement ou appel PSP n’est exécuté.

La création d’une marketplace opérateur doit traiter ce risque dès la conception de la promesse acheteur. Le travail sur les parcours de paiement et de sécurité marketplace consiste à relier les engagements vendeurs aux capacités effectivement disponibles chez le prestataire, avec une vue compréhensible pour l’exploitation et le client.

Dans quel cas poursuivre le panier après un refus vendeur

Vérifier que les groupes sont réellement indépendants

La poursuite partielle convient à certains achats dont chaque groupe conserve son utilité : plusieurs fournitures sans dépendance, des accessoires indépendants ou des réassorts distincts. Elle ne convient pas automatiquement à un ensemble fonctionnel dont une pièce manque. L’acheteur qui attend un kit complet ne reçoit pas la même proposition lorsque seul le composant central est retiré.

Notre cas suppose que cette possibilité était expliquée et acceptée dans le parcours. Si la règle prévoit une nouvelle décision de l’acheteur, le système doit la recueillir avant de poursuivre. Le montant inférieur ne prouve pas que la nouvelle composition reste acceptable. Les conditions applicables doivent être définies avec les responsables produit et commerciaux selon le modèle de vente retenu.

Garder les règles du panier initial consultables

Le dossier conserve les offres, les vendeurs, les quantités, les frais, les remises et la version de la proposition acceptée. Le refus ne recalcule pas silencieusement la commande comme un nouveau panier. Cette photographie permet de déterminer ce qui était imputé au groupe retiré et ce qui reste dû pour les groupes conservés.

Les règles peuvent être plus complexes que notre exemple : livraison gratuite conditionnelle, remise commune ou minimum par vendeur. Si le retrait change les conditions d’un autre groupe, le calcul doit produire une nouvelle proposition ou appliquer une politique déjà qualifiée. Il ne doit pas faire payer à un autre vendeur les conséquences d’une règle que celui-ci n’avait pas acceptée.

Séparer la décision vendeur de l’état du paiement

Lire le paiement au lieu de l’inférer depuis le checkout

Le retour vers la page de succès ne constitue pas une preuve suffisante de capture. L’application rapproche l’identifiant de paiement, sa devise, son montant disponible, les montants déjà capturés et remboursés, ainsi que son état actuel. Une réponse absente ou contradictoire ouvre une vérification ; elle ne devient pas automatiquement un échec à retenter.

Une vente aux enchères ajoute une décision en amont : la clôture et ses prolongations doivent être confirmées avant d’engager le parcours de paiement. Un compteur arrivé à zéro ne désigne pas à lui seul le montant ni l’acheteur à débiter.

La documentation Stripe sur la séparation autorisation-capture, vérifiée le 25 octobre 2026, décrit l’état requires_capture, l’échéance capture_before pour la carte et la libération du montant restant lors d’une capture partielle ordinaire. La plupart des paiements ne permettent qu’une capture ; la durée disponible dépend du paiement concerné.

Conserver deux chronologies que le support peut rapprocher

D’un côté, chaque sous-commande reçoit une réponse vendeur : en attente, acceptée ou refusée selon le workflow choisi. De l’autre, le paiement possède ses propres opérations et confirmations. Les deux chronologies partagent la référence de commande et sa version, mais une réponse vendeur ne modifie pas directement un montant financier déjà confirmé.

L’écran opérateur doit montrer ce décalage lorsqu’il existe : « vendeur B refusé, paiement à rapprocher » est plus exact que « commande remboursée ». Cette distinction évite qu’une équipe ferme le dossier commercial alors que le remboursement reste seulement demandé ou que la libération d’autorisation n’a pas encore été confirmée.

Scénario de décision : 260 € autorisés, 173 € conservés

Calculer depuis les allocations figées

Le vendeur A représente 100 € de produits et 5 € de livraison. B représente 80 € et 7 € ; C représente 60 € et 8 €. Les montants sont fictifs, exprimés en euros et déjà arrêtés pour l’acheteur. L’exercice ne calcule pas la TVA ni les règles de commission : il reçoit ces allocations finales comme entrées.

Ne pas transformer la différence en opération par réflexe

La différence de 87 € correspond au groupe B retiré, livraison comprise selon l’hypothèse retenue. Avec une autorisation encore capturable et aucune capture antérieure, le plan prépare une capture finale de 173 €. Avec un encaissement confirmé de 260 €, il prépare une intention de remboursement de 87 €. Les deux situations produisent le même total commercial final, mais pas le même mouvement.

Si les 173 € ont déjà été capturés, aucun nouveau remboursement n’est attendu dans ce scénario. Si le PSP indique un état inconnu, le programme demande un rapprochement et ne choisit aucune écriture. Le risque est de croire qu’un calcul arithmétique juste suffit : il faut aussi savoir sur quel état financier cette différence est appliquée.

• Si l’état financier est inconnu, alors rapprocher le paiement avant de choisir une action ; aucune différence n’est envoyée au PSP.
• Si les groupes et le consentement sont confirmés et que 260 € restent capturables, alors préparer une capture finale de 173 € dans le parcours à capture unique.
• Si 260 € sont déjà capturés, alors retrouver les remboursements confirmés avant de calculer le solde de 87 € à restituer.
• Si la proposition ou les conditions acceptées ont changé, alors soumettre la nouvelle décision à l’acheteur avant de poursuivre.

Attendre la décision utile avant une capture finale unique

Ne pas consommer l’autorisation au premier vendeur accepté

Supposons que A accepte immédiatement et que C réponde plus tard. Capturer 105 € dès la première réponse peut fermer la capacité d’utiliser le reste de l’autorisation dans un parcours à capture unique. Le système se retrouve alors à demander un nouveau paiement pour C, alors que l’acheteur pensait avoir terminé son achat initial.

La stratégie de notre recette attend que chaque groupe ait une décision terminale, puis calcule un seul montant final. Elle nécessite un délai vendeur compatible avec l’échéance du paiement et avec la promesse commerciale. Elle n’est donc pas une recommandation universelle : si les confirmations sont structurellement longues, il faut revoir l’ordre des étapes ou le mode de paiement.

Traiter la multicapture comme une capacité qualifiée

La documentation Stripe sur la multicapture décrit des conditions d’accès et d’éligibilité spécifiques. Elle exclut notamment les flux « separate charges and transfers » utilisant source_transaction. Une option disponible dans un autre compte ou un autre montage ne suffit donc pas à valider votre parcours Connect.

Avant d’adopter plusieurs captures, vérifiez compte, moyen de paiement, flux de fonds, mode de capture et règle de clôture dans l’environnement du prestataire. Le dossier métier doit préciser quand le reliquat peut encore être utilisé et quand il est libéré. Notre exemple reste volontairement dans le périmètre d’une capture finale unique et ne simule pas cette fonction avancée.

Faire décider l’échéance sans capturer une vente incertaine

Définir une limite de réponse vendeur utilisable

L’exploitation a besoin d’une limite antérieure à la dernière échéance financière exploitable. Cette marge sert à relire le paiement, traiter les réponses et exécuter la décision ; elle ne prolonge pas l’autorisation. Elle doit être déterminée à partir du parcours observé, des dépendances et des horaires de prise en charge.

Un vendeur encore silencieux à cette limite n’est pas automatiquement considéré comme refusé par notre programme. La politique de commande doit définir cette sortie et produire une décision traçable. Une indisponibilité de l’API vendeur ne prouve pas davantage un refus commercial. Les deux situations peuvent demander des messages et des responsabilités différents.

Fermer la voie automatique à l’échéance exacte

Dans la recette, l’instant 200 est l’échéance fournie et la comparaison est inclusive : à 200, aucune capture n’est proposée. Le résultat demande de rafraîchir l’état du paiement. Si celui-ci est confirmé annulé tandis que les groupes A et C restent proposés, la suite est une nouvelle décision de paiement, liée au même dossier commercial.

Le système ne capture pas les 260 € pour « sauver » une autorisation dont la vente reste partiellement refusée. Il ne lance pas non plus une nouvelle autorisation sans vérifier le résultat de la précédente. Le support explique ce qui reste disponible et l’action attendue, en conservant l’historique des tentatives pour éviter deux commandes concurrentes.

Si les fonds sont déjà capturés, préparer le bon remboursement

Rapprocher les montants avant de demander une nouvelle action

Avec 260 € capturés et aucun remboursement confirmé, le solde à corriger est de 87 €. Après un remboursement confirmé de 87 €, le net encaissé atteint 173 € et le plan devient équilibré. Une notification répétée du refus de B ne doit pas générer une nouvelle demande indépendante de 87 €.

Conservez une intention stable liée à la commande, à sa révision et à l’opération. Une réponse perdue après demande reste « résultat à rapprocher ». La recette déduplique seulement cette intention dans un registre local ; elle ne démontre pas l’idempotence de l’API du PSP. La réception technique doit vérifier les clés, les réponses et les événements du prestataire réellement utilisé.

Distinguer remboursement acheteur et récupération côté vendeur

Dans le modèle Stripe de paiements et transferts séparés, rembourser le paiement ne renverse pas automatiquement les transferts associés. Une récupération auprès du vendeur et son résultat doivent donc être suivis séparément lorsque de tels transferts ont déjà eu lieu.

Le dossier sur le remboursement après transfert au vendeur traite cette branche en détail. Ici, l’enjeu initial est de sélectionner la bonne opération après refus. Un encaissement partiel correctement choisi peut éviter une correction inutile, mais ne dispense pas du rapprochement si le circuit a déjà avancé.

Exécuter les réponses hors ordre et les cas de blocage

Obtenir le même montant pour six ordres d’arrivée

Le programme de décision après refus vendeur utilise uniquement Python et des montants entiers en centimes. Il teste les six permutations de A accepté, B refusé et C accepté. Chaque notification est également appliquée deux fois. Une fois les décisions complètes, le plan doit toujours proposer 17 300 centimes de capture finale.

Avant la dernière réponse, le résultat reste une attente vendeur. Une acceptation de B après son refus terminal est rejetée par le modèle : changer cette décision exige un nouveau circuit explicite. Cette politique empêche un ancien message de réintroduire silencieusement le groupe B dans une commande déjà recalculée. Elle n’interdit pas au métier de proposer ensuite une autre vente.

python3 marketplace-refus-autorisation.py
# Autorisé : 26 000 centimes ; capture finale proposée : 17 300.
# Déjà capturé en totalité : remboursement proposé de 8 700.
# Paiement inconnu : rapprochement, aucune action financière.
# À l’échéance : nouvelle lecture du paiement, aucune capture.

Vérifier aussi les refus du contrôleur

Le programme bloque la voie automatique si la version acceptée ne correspond plus ou si la poursuite partielle n’est pas admise. Il rejette les montants négatifs, booléens ou supérieurs au total autorisé. Il couvre également le refus de tous les groupes, qui prépare l’annulation d’une autorisation encore utilisable dans le périmètre choisi.

Ces tests n’appellent pas Stripe, ne vérifient pas un contrat commercial et n’exercent pas la concurrence dans votre base. Ils rendent la décision reproductible sur des faits fournis. La recette d’intégration doit ensuite faire varier les réponses réseau, les droits opérateur et les événements PSP pour confirmer que ces faits sont correctement collectés et appliqués.

Expliquer l’issue sans faire lire un relevé comptable

Donner à l’acheteur un résumé stable

La page commande conserve la référence globale et présente les groupes A et C maintenus, le groupe B indisponible et le total actualisé. Si le paiement était seulement autorisé, le message explique que le montant final prévu est de 173 € et que la part inutilisée suit la libération de l’autorisation. Il n’annonce pas un remboursement de fonds qui n’ont pas été capturés.

Si 260 € étaient encaissés, le parcours indique le remboursement de 87 € avec son état réel : demandé, confirmé par le prestataire ou à rapprocher. Les délais d’affichage bancaire ne doivent pas être inventés. L’acheteur doit surtout comprendre ce qu’il recevra, combien il doit finalement payer et s’il reste une action à accomplir.

Montrer au vendeur et à l’opérateur des actions différentes

Chaque vendeur consulte sa propre sous-commande et son motif de clôture. Il ne peut pas modifier la décision d’un autre groupe ni le paiement global. Le back-office opérateur réunit les allocations, les réponses, la version acceptée et les mouvements. Une action de reprise affiche le périmètre et le montant avant d’être exécutée par un utilisateur habilité.

Le contrat d’intégration définit l’entrée de chaque décision : réponse vendeur, référence de commande et version. Sa sortie est un état attribué et une intention financière éventuelle. La journalisation relie le webhook, la file de traitement et l’action proposée, tandis que le repli conserve les dossiers incertains dans une attente visible pour l’exploitation.

Mesurer les refus qui dégradent la marge et la confiance

Suivre le délai entre autorisation et décision finale

Premier signal faible : le nombre de paniers autorisés reste stable, mais les demandes de nouveau paiement augmentent. Vérifiez si une première capture a consommé l’autorisation avant la réponse des autres vendeurs. Deuxième signal : les remboursements liés aux refus montent alors que le catalogue annonce toujours le même niveau de disponibilité. Le stock ou le délai de confirmation peut être en cause.

Segmentez les mesures par vendeur, moyen de paiement et nombre de groupes. Suivez aussi les montants en attente de rapprochement et leur ancienneté. Un taux de conversion global ne distingue pas une vente exécutée d’un panier autorisé puis partiellement arrêté. La performance commerciale doit rester reliée au résultat de livraison et au coût de support.

Calculer la charge des reprises avec des hypothèses explicites

Par exemple, vingt dossiers fictifs demandant douze minutes de support représentent 240 minutes, soit quatre heures. À un coût interne hypothétique de 35 € par heure, cette charge atteint 140 €, avant frais PSP éventuels et gestes commerciaux. Ce calcul ne prédit pas une économie ; il sert à mesurer une famille de reprises que les seuls montants remboursés ne montrent pas.

La gouvernance fixe un seuil d’escalade selon les conséquences : autorisation proche de son terme, résultat financier inconnu ou réponse vendeur absente. Les responsabilités sont réparties entre opérations marketplace et équipe paiement. Le contrat de reprise précise les preuves à réunir, la journalisation attendue et le repli lorsque la dépendance PSP reste indisponible.

Erreurs fréquentes après l’autorisation d’un panier multivendeur

Employer le même statut pour toute la chaîne

« Payé », « confirmé » et « terminé » sont trop vagues lorsqu’ils désignent à la fois l’acheteur, les vendeurs et les mouvements financiers. Utilisez des états propres à chaque objet, puis une synthèse compréhensible. L’état global doit être calculé depuis des faits conservés, sans masquer une sous-commande encore ouverte.

• Capturer le total pour éviter l’expiration alors qu’un groupe est déjà refusé.
• Promettre plusieurs captures sans vérifier le montage PSP exact.
• Rembourser une autorisation non capturée.
• Réintroduire un vendeur après une réponse tardive sans nouvelle décision.
• Déduire la récupération d’un transfert du seul remboursement acheteur.

Faire varier les conditions pendant la reprise

Le même refus ne doit pas produire 87 € au premier passage puis un autre montant après une mise à jour du tarif de livraison. L’opération repart des allocations et de la politique qualifiées pour cette commande. Si une modification de conditions est nécessaire, elle constitue une nouvelle proposition avec sa propre validation.

La correction manuelle doit emprunter le même service de décision que le traitement automatique. Modifier directement un total dans le back-office sans intention associée peut créer un affichage cohérent et un solde financier faux. La recette doit contrôler simultanément la commande, les allocations et les mouvements confirmés.

Plan d’action pour recevoir un refus sans fausser le paiement

Qualifier un parcours et ses capacités réelles

Choisissez d’abord une famille de paniers indépendants et un moyen de paiement. Identifiez les conditions de poursuite partielle, les règles de frais et la limite de réponse vendeur. Reconstituez quelques dossiers ayant déjà demandé une reprise, puis séparez autorisation, capture, remboursement et transfert. Cette lecture doit produire une matrice d’états et de décisions que produit, opérations et paiement comprennent de la même manière.

Vérifiez ensuite les capacités du compte PSP et du flux de fonds utilisés. Si le modèle suppose une capture finale unique, faites apparaître cette contrainte dans l’orchestration. Si plusieurs captures sont nécessaires, réceptionnez leur disponibilité et leurs restrictions avant de promettre ce comportement. Le choix du checkout doit suivre cette qualification, et les écrans doivent afficher la même version de commande.

Éprouver les exceptions avant d’élargir le panier

Exécutez les six ordres de réponse, les refus répétés, le silence d’un vendeur et la réponse reçue après l’échéance. Ajoutez une capture dont la réponse réseau manque, un remboursement déjà confirmé et une proposition modifiée. Pour chaque cas, comparez l’action financière, le total commercial et le message acheteur. Un dossier ne passe pas la recette si une seule de ces trois lectures diverge.

Ouvrez ensuite un périmètre limité avec une file d’exceptions attribuée. Mesurez les délais, les reprises et les nouveaux paiements demandés avant d’ajouter vendeurs, promotions ou moyens de paiement. La sortie du pilote exige que l’équipe puisse expliquer un refus jusqu’au solde final. Une baisse du nombre d’erreurs HTTP ne suffit pas si l’acheteur reçoit encore une information financière inexacte.

Guides complémentaires pour le panier et les fonds vendeurs

Le refus après autorisation est un point de décision précis. Deux autres chantiers restent nécessaires pour construire le parcours complet et traiter les fonds lorsque le circuit a déjà progressé.

Structurer le panier et les sous-commandes

La conception du panier multivendeur et de sa promesse acheteur détaille le découpage des groupes, les réservations et la présentation des livraisons. Elle fournit le cadre dans lequel la décision de capture doit s’inscrire.

Utilisez ce découpage pour désigner précisément le groupe refusé et ses conséquences. Le paiement ne doit pas devenir l’unique endroit où l’application découvre que plusieurs vendeurs ont des engagements différents.

Diagnostiquer un vendeur qui ne peut pas recevoir ses fonds

Le diagnostic des reversements Stripe Connect bloqués distingue les capacités et les états qui peuvent empêcher la suite du flux financier. Un vendeur ayant accepté sa commande n’est pas nécessairement prêt à recevoir toutes les opérations prévues.

Cette qualification doit être traitée au bon moment du cycle vendeur. Elle complète la décision sur le montant acheteur sans la remplacer par un simple indicateur « compte connecté ».

Conclusion : décider le montant depuis une vente et un paiement confirmés

Un vendeur qui refuse après autorisation oblige la marketplace à rapprocher deux réalités : la composition encore acceptée et les fonds réellement engagés. La même différence de 87 € peut correspondre à une part non capturée ou à un remboursement à demander. Le statut commercial seul ne permet pas de choisir.

Le scénario à trois vendeurs fournit une recette reproductible pour cette décision. Les réponses hors ordre et répétées convergent vers 173 € dans le périmètre retenu. L’échéance, le paiement inconnu et le changement de proposition ferment la voie automatique au lieu de déclencher une action approximative.

La qualité du parcours repose ensuite sur les confirmations du prestataire, la stabilité des allocations et des écrans qui expliquent la prochaine étape. Chaque opération garde son identité et sa preuve ; les transferts vendeurs sont rapprochés séparément lorsque le modèle l’exige. Cette discipline réduit les corrections opaques et donne au support une histoire financière vérifiable.

Dawap accompagne la conception de votre marketplace opérateur depuis les engagements vendeurs jusqu’aux parcours acheteur et paiement. Le point de départ est un scénario de refus représentatif, éprouvé avec vos règles commerciales et les capacités confirmées de vos prestataires.