Questions sur les avoirs Magento : comment répondre à chaque ticket de remboursement

Pourquoi les credit memos Magento déroutent-ils clients et agents ?

Je suis Rama. Je construis des intégrations chez eesel, dont le code que l'agent eesel utilise pour émettre des remboursements dans Magento, et le credit memo est la partie qui fait le plus trébucher vu de l'intérieur. Le nom sonne comptable. L'e-mail reçu par le client dit "credit memo", pas "remboursement". Et le même document peut signifier "votre carte récupère l'argent", "nous vous avons envoyé un chèque" ou "rien ne s'est encore passé", selon le bouton qu'un administrateur a cliqué.

La définition d'Adobe est claire : un credit memo est "un document qui indique le montant dû au client pour un remboursement total ou partiel", d'après le guide des credit memos. C'est la paperasse. Savoir si l'argent a bougé est un fait distinct, et c'est celui sur lequel porte chaque ticket client.

Ce guide couvre le fonctionnement des credit memos, les tickets qu'ils créent, comment répondre à chacun, ce que votre helpdesk peut voir et où l'IA s'intègre. Pour la plateforme en général, l'avis sur Magento et le détail des tarifs Magento couvrent les bases, et Magento AI explique ce que fait l'IA d'Adobe (surtout du merchandising, pas du support).

Comment fonctionne un credit memo dans Magento ?

Un credit memo ne peut être créé que sur une commande facturée. La page d'Adobe émettre un credit memo indique qu'il "doit d'abord être généré pour une commande facturée", et que vous pouvez émettre des remboursements en ligne et hors ligne, partiels ou totaux, "selon le mode de paiement". Avant qu'une facture existe, vous annulez la commande. Une fois qu'elle existe, une annulation doit passer par un credit memo, selon la documentation d'Adobe sur le traitement des commandes.

Pour le support, le point clé est l'endroit où l'administrateur commence. Un remboursement par carte via la passerelle doit partir de la facture : Sales > Orders > View > Invoices, ouvrir la facture, puis Credit Memo. Le bouton Credit Memo de la commande elle-même convient pour les remboursements hors ligne, mais il ne peut pas atteindre la carte. L'administrateur choisit ensuite l'une de trois façons de terminer :

Les trois descriptions proviennent du guide des credit memos d'Adobe, et le fait que le crédit boutique soit réservé à Adobe Commerce est précisé dans la documentation du crédit boutique. Les achats par chèque et mandat "doivent être remboursés hors ligne". Les achats par carte peuvent suivre l'une ou l'autre voie.

Cette ligne du milieu est la source de la plupart des tickets déroutants. Un agent voit un credit memo sur une commande par carte et dit au client "votre remboursement est en route". Si quelqu'un a cliqué sur Refund Offline pour cette commande par carte, ce n'est pas le cas. Le memo existe, la commande affiche peut-être même Closed, et aucun argent n'a bougé tant que quelqu'un ne le rembourse pas dans le tableau de bord du prestataire de paiement.

Ce que signifient les champs du formulaire

Le bloc Refund Totals est l'endroit où naissent les remboursements partiels et les tickets "pourquoi ai-je reçu moins ?". Voici ce que fait chaque champ, d'après la page des credit memos d'Adobe :

• Refund Shipping part du coût de livraison de la commande, moins ce qui a déjà été remboursé. Il "peut être réduit, mais pas augmenté."
• Adjustment Refund ajoute de l'argent qui n'est lié ni à un article, ni à la livraison, ni à la taxe, comme un geste commercial. Il "ne peut pas porter le remboursement total au-delà du montant payé."
• Adjustment Fee retire de l'argent, "comme des frais de réapprovisionnement".
• Return to Stock remet l'article en stock. Les boutiques peuvent l'automatiser avec le paramètre Automatically Return Credit Memo Item to Stock.
• Email Copy of Credit Memo envoie le document au client. Si la case est décochée et que la boutique n'a pas activé les e-mails automatiques de credit memo, le client n'entend rien.
• Append Comments ajoute le commentaire de l'administrateur à cet e-mail, le seul endroit pour expliquer un remboursement partiel en mots simples.

Vous pouvez rembourser une partie d'une facture, plusieurs montants partiels, plusieurs factures sur une commande, ou "trois chemises sur les cinq d'une commande", le tout via des credit memos distincts. Une commande entièrement remboursée passe à Closed. Une commande partiellement remboursée reste en Processing jusqu'à l'expédition de tous les articles, d'après le tableau des statuts de commande d'Adobe.

Quelles questions sur les credit memos les clients posent-ils vraiment ?

Les tickets de credit memo tiennent dans une courte liste, et presque tous se résolvent en lisant l'onglet Credit Memos de la commande. Voici comment je répondrais à chacun, avec le champ à regarder.

"J'ai reçu un e-mail de credit memo. C'est quoi ?"

C'est la question la plus courante, et c'est un problème de vocabulaire. Le modèle d'e-mail par défaut de Magento s'appelle littéralement New Credit Memo et s'envoie dès que la case Email Copy of Credit Memo est cochée ou que la boutique a activé les e-mails de credit memo, sous Stores > Configuration > Sales > Sales Emails > Credit Memo, d'après la référence des e-mails de vente d'Adobe.

La réponse : "C'est notre reçu de remboursement. Il indique ce que nous avons remboursé et comment." Dites ensuite comment, car c'est la question suivante. Si ce ticket revient souvent, la solution la moins coûteuse est de modifier l'objet du modèle pour qu'il dise "remboursement" au lieu de "credit memo". C'est un changement unique qui supprime un type entier de ticket.

"Ai-je été remboursé ? Je ne vois rien sur ma carte."

Ouvrez le credit memo et vérifiez deux choses : quel bouton l'a créé, et quand. S'il s'agit d'un Refund en ligne, l'argent a quitté votre côté et le délai dépend désormais du réseau de carte. Adobe ne donne pas de nombre de jours et renvoie à "la documentation fournie par votre prestataire de paiement". Dites-le honnêtement et donnez le délai habituel du processeur tiré de votre propre page de politique, pas un chiffre inventé.

S'il s'agit de Refund Offline sur une commande par carte, c'est un vrai problème, pas une question de délai. Aucun argent n'a bougé. Signalez-le à la personne qui gère les paiements pour qu'elle rembourse dans le tableau de bord de la passerelle, et ne dites pas au client que c'est en route avant qu'elle l'ait fait.

Les clients connectés peuvent vérifier eux-mêmes sous My Orders > View > Refunds, qui affiche les articles remboursés, la livraison, la taxe et le total, d'après la page d'Adobe sur les remboursements dans le compte client, qu'Adobe range dans sa documentation sur le crédit boutique d'Adobe Commerce. Les y renvoyer avec le numéro de remboursement est déjà une bonne réponse.

"Pourquoi n'ai-je récupéré qu'une partie de mon argent ?"

Lisez les Refund Totals du memo. Les causes habituelles, dans l'ordre où je les vérifierais :

1. La livraison n'a pas été remboursée. Refund Shipping a été réduit ou mis à zéro.
2. Des frais de réapprovisionnement ont été retenus. C'est l'Adjustment Fee.
3. Seuls certains articles ont été remboursés. Qty to Refund a été fixé sous la quantité commandée.
4. Un second memo arrive. Les remboursements partiels peuvent être répartis sur plusieurs memos, et la commande reste en Processing entre-temps.
5. Une partie a été payée par carte cadeau, crédit boutique ou points de fidélité. Ceux-ci reviennent séparément, et les points de fidélité dépendent de deux paramètres globaux, Refund Reward Points Automatically et Deduct Reward Points from Refund Amount Automatically, d'après la configuration des points de fidélité.

La réponse est alors précise : "Nous avons remboursé les deux articles que vous avez retournés, 84,00 $, mais pas les 10 $ de livraison d'origine, que notre politique de retours ne couvre pas." Si un administrateur a laissé un commentaire sur le memo, il vous dit généralement de quel cas il s'agit.

"Puis-je avoir du crédit boutique plutôt qu'un remboursement ?" (ou l'inverse)

Sur Adobe Commerce, un administrateur coche Refund to Store Credit sur le memo et le client le voit dans son compte sous Store Credit, avec la date et l'heure. Sur Magento Open Source, la fonction n'existe pas, donc "crédit boutique" désigne en général un code promo ou une carte cadeau que votre équipe émet à la main. Sachez quelle édition vous utilisez avant de promettre quoi que ce soit. (BigCommerce gère cela très différemment ; voir le guide du crédit boutique BigCommerce si vous utilisez les deux.)

Un piège de la documentation : si une commande de carte cadeau est remboursée, "vous devez annuler manuellement le compte de carte cadeau associé", d'après le workflow des cartes cadeaux d'Adobe. Rembourser la commande ne désactive pas la carte de lui-même.

"Pourquoi ne pouvez-vous pas encore rembourser ma commande ?"

Celle-ci vient autant du côté agent que du côté client. Passez-la par les mêmes contrôles que Magento :

• Pas encore de facture : annulez à la place. Il n'y a rien à créditer.
• Facture réglée sur Not Capture : "Vous ne pouvez pas créer de credit memo tant que le paiement n'a pas été capturé", d'après la page d'Adobe sur les remboursements de crédit boutique.
• Authorize and Capture, mais non réglé : "Les remboursements ne peuvent pas être émis tant que la transaction n'est pas réglée." Cette attente est généralement courte et gérée par le processeur.

Les doubles débits et les remboursements contestés relèvent d'un flux distinct, traité dans l'IA pour les litiges de facturation. Pour le reste, dire à un client "votre paiement est encore en cours de règlement, nous le rembourserons dès que la banque le permettra" est une bien meilleure réponse que "nous ne pouvons pas rembourser cela".

"Où est mon reçu de remboursement ?"

Les administrateurs peuvent imprimer un credit memo en PDF depuis Sales > Operations > Credit Memos, un par un avec Print ou en lot avec Actions > PDF Credit Memos. Les clients peuvent l'imprimer depuis l'onglet Refunds de leur commande avec Print Refund. Les deux réponses fonctionnent ; la seconde vous épargne un ticket la prochaine fois.

Que devrait vérifier votre équipe avant de répondre ?

Une courte liste de contrôle vaut mieux qu'un long document de politique ici, car chaque question sur un credit memo revient aux quatre mêmes champs. Avant que quiconque, humain ou IA, réponde :

La grille Credit Memos sous Sales affiche chaque memo avec son numéro de commande, son statut et son montant remboursé, pratique pour les tickets "j'ai été débité deux fois, remboursez-en un" où il faut voir ce qui est déjà reparti.

Faites le memo correctement du premier coup, car l'administrateur n'a pas d'annulation simple. Un fil Reddit de 2020 demandant comment annuler un credit memo saisi avec de mauvaises informations a obtenu cette réponse :

"You could add another credit memo if the previously credit memo was a partial refund. Not if it was a full refund. You'll have to get your devs to edit it manually at the db level."

u/Spartaness, "How do you reverse a credit memo ?", Reddit

Les paiements fractionnés sont l'autre piège classique. Un ancien message de r/Magento décrit des remboursements sur des commandes payées en partie par carte et en partie par crédit boutique, où Magento utilisait d'abord le crédit boutique et laissait le remboursement carte incomplet. Cela date de l'époque de Magento 1, mais c'est pourquoi je lis toujours le détail du paiement sur le memo, pas seulement le total, avant de dire à un client ce qui est revenu sur sa carte.

"every time we refund an order that was paid by credit card and store credit, the system would always use the store credit first thus making the CC refund not complete"

u/Orange_night, "Refund Credit memo last", Reddit

Si vous utilisez Adobe Commerce avec les retours activés, il y a une couche de plus. Un retour (RMA) enregistre que vous avez autorisé le retour de l'article, avec une résolution Exchange, Refund ou Store Credit, d'après le guide des retours d'Adobe. L'argent repart toujours par un credit memo, et la documentation ne dit pas qu'approuver un retour en crée un pour vous. Donc "mon retour a été approuvé, où est mon argent ?" signifie chercher un memo, pas seulement regarder le statut du retour. Magento Open Source n'a aucun module de retours, c'est pourquoi les remboursements y portent tout le travail. Le guide sur la gestion des retours traite plus en profondeur le côté retours.

Que peut voir votre helpdesk des remboursements Magento ?

Moins que vous ne l'espérez, dans la plupart des cas. J'ai vérifié la documentation Magento de chaque helpdesk :

Aucun ne documente l'affichage du credit memo lui-même, avec son bouton et ses Refund Totals, dans le ticket. C'est la lacune. Un agent peut voir qu'une commande est Closed sans savoir si l'argent est retourné sur la carte ou nulle part. Le guide Gorgias Magento approfondit cette intégration, et meilleure IA pour Magento compare les autres options.

Où l'IA s'intègre-t-elle dans les tickets de credit memo ?

Répartissez le travail selon ce qui peut mal tourner. Expliquer ce qu'est un credit memo ne coûte rien si l'IA se trompe légèrement sur un mot. Rembourser une carte, c'est de l'argent réel difficile à récupérer. Je classerais les tickets en trois voies :

• L'IA répond seule : ce qu'est un credit memo, combien de temps prennent les remboursements par carte selon votre politique, où trouver le reçu. Ce sont des réponses de politique. Un chatbot IA pour Magento entraîné sur votre page de remboursement s'en charge bien, par e-mail ou par chat en direct Magento.
• L'IA consulte et rédige : "ai-je été remboursé ?", "pourquoi seulement une partie ?", "la livraison était-elle incluse ?". Il faut la commande en direct et ses memos. L'IA les lit et rédige la réponse, et une personne la vérifie pour tout cas inhabituel. Des macros de remboursement prêtes à l'emploi aident aussi ici.
• Une personne décide : rembourser une commande par carte, des ajustements commerciaux, lever des frais de réapprovisionnement. Ce sont des décisions de jugement où il y a de l'argent en jeu. Une matrice d'approbation des remboursements propose un modèle pour tracer cette ligne.

Je l'ai vu sur de vraies boîtes de réception, pas dans des démos. Lors d'un essai en trafic réel mené par eesel sur la boîte Zendesk et Shopify d'une marque e-commerce, les brouillons pour les questions sur l'état des remboursements ont été jugés utiles 100% du temps et ceux sur les retours et remboursements 93.8%, mais seulement 12% ont été envoyés sans modification. Retrouver le remboursement est facile pour l'IA ; décider quoi en dire gagne encore à passer par une personne.

Cette répartition est déjà celle des clients d'eesel pour les remboursements. STIL Classics, une marque d'agendas sur Gorgias et Shopify, fait consulter la commande par eesel qui laisse un brouillon en note interne, "rédigé comme si le remboursement ou le remplacement avait déjà été traité, parce que la personne qui l'envoie l'aura fait auparavant". L'équipe traite le remboursement, modifie et envoie ; eesel a préparé environ 320 tickets et consulté environ 230 commandes en un mois. Question Beauty va plus loin et laisse eesel répondre seul à environ 960 tickets par mois, tandis que les remboursements, retours et rétrofacturations sont toujours confiés à une personne avec une note. Aucun des deux ne tourne sur Magento, mais la règle s'applique : l'IA fait la lecture, une personne déplace l'argent.

La même répartition apparaît dans le guide IA pour les demandes de remboursement et dans les workflows d'approbation du support client, si vous voulez la version générale.

Comment eesel gère les credit memos Magento

L'intégration Magento d'eesel lit les commandes en direct par numéro de commande exact ou e-mail, ainsi que le suivi, l'état du paiement (méthode, s'il est réglé, solde dû), les produits et le stock, d'après la documentation Magento d'eesel. Elle fonctionne sur Magento 2, aussi bien Open Source qu'Adobe Commerce.

Côté écriture, l'action Refund Order d'eesel rembourse un montant, des articles précis ou tout le solde restant, et Magento l'enregistre comme credit memo. Je l'ai construite avec prudence, exprès :

• Commandes payées hors ligne uniquement. Chèque, virement bancaire et paiement à la livraison. Les commandes par carte et autres passerelles sont refusées, car ce remboursement "doit être émis par une personne dans l'administration Magento pour atteindre le compte du client". C'est le piège Refund Offline évoqué plus haut, fermé dans le code : eesel ne créera pas de memo indiquant "remboursé" alors que la carte ne reçoit rien.
• Approbation d'abord, si vous le souhaitez. Les actions d'écriture peuvent attendre qu'une personne les approuve sur la page Activity, et accorder une autorisation Magento n'active pas une action à lui seul.
• Il vérifie son propre travail. La configuration demande les deux autorisations de credit memo, l'une pour émettre et l'autre pour relire le memo. Avec une seule, l'argent peut bouger mais l'agent signale le remboursement comme échoué, d'après le guide de configuration Magento.
• Il faut une facture, comme pour Magento.

Les autres actions incluent l'annulation d'une commande non expédiée, la mise en attente et la libération d'une commande, l'envoi d'un avis de commande et la mise à jour d'une adresse enregistrée. Sur Adobe Commerce, il peut aussi créer un retour.

Deux limites à connaître. Magento lui-même ne déclenche pas eesel, donc les exécutions démarrent depuis un ticket de helpdesk (Zendesk, Gorgias ou Freshdesk), une mention Slack ou la bulle de chat de votre boutique. Et Magento ne contient aucune politique écrite, donc vos règles de remboursement viennent de votre site web ou de documents importés. Si vous préférez qu'un script s'en charge, la CLI eesel permet à un agent de code comme Claude Code de lancer la connexion Magento, d'importer votre politique de remboursement, puis de poser des questions de test comme "la commande 1042 a-t-elle été remboursée sur la carte ?" et de vérifier les réponses avant toute mise en production. Créer l'intégration Magento et coller ses clés demande toujours quelqu'un ayant un accès administrateur Magento.

La tarification se fait par crédits, pas par utilisateur : gratuite avec 100 crédits, puis à partir de $299 par mois pour 500 crédits, où un ticket ou un chat vaut un crédit quel que soit le nombre de consultations, d'après les tarifs eesel. Pour un pas-à-pas de la configuration, voyez comment ajouter l'IA à Magento, et le guide du widget de chat Magento pour le côté vitrine.

Avant la mise en production, je le testerais sur d'anciens tickets de remboursement, comme le décrit le guide des tests par simulation. Les limites de laisser l'IA s'approcher de l'argent sont traitées dans remboursements et retours par IA, et l'angle e-commerce dans automatisation des remboursements par IA.

Essayez eesel pour vos tickets de remboursement Magento

Si votre file est pleine de "j'ai reçu un credit memo, où est mon argent ?", eesel peut consulter la commande et l'état de son paiement avant que quiconque ouvre le ticket, rédiger la réponse à partir de votre propre politique de remboursement et traiter les remboursements hors ligne après approbation, tandis que les remboursements par carte restent à votre équipe. Il fonctionne dans votre file Gorgias, ou dans Zendesk ou Freshdesk, aux côtés de Magento, et les 100 crédits du forfait gratuit suffisent pour l'essayer sur un lot de vrais tickets de remboursement. Essayez eesel et voyez ce qu'il donne sur les vôtres.