E-commerce
6 août 2026
« Ma carte a expiré, où est mon remboursement ? » « PayPal est fermé, vous pouvez virer sur mon compte ? » « Shopify dit remboursé mais je ne vois rien. » Trois tickets sur un même angle mort : le refund bloqué ou invisible quand le moyen de paiement d'origine n'existe plus.
Shopify indique que les remboursements sont crédités sur le moyen de paiement original, et que les banques routent souvent vers le compte ou la carte de remplacement même si la carte est expirée (Shopify, remboursements 2026). Stripe précise qu'un refund vers carte expirée aboutit fréquemment, mais qu'un échec technique impose une alternative manuelle (Stripe, refunds 2026).
Ce guide #369 traite le support client remboursement carte expirée ou moyen fermé e-commerce. Aucun article paiement existant ne couvrait ce cas ops de bout en bout. Il complète paiements fractionnés (#194) et remboursement partiel (#368) avec l'angle policy REF-EXP, flow REF-EXP-GATE, alternatives IBAN/avoir et macros agents. Il prépare le futur bot statut remboursement (#370).
Summary
Pourquoi les remboursements sur carte expirée bloquent-ils le SAV ?
Un ticket remboursement carte expirée support arrive quand le client a retourné un produit ou annulé une commande, le refund Shopify est lancé, mais le crédit n'apparaît pas sur le compte actuel. Carte expirée, compte PayPal fermé, banque fusionnée : le client panique.
Cinq frustrations client
Refund « perdu » : Shopify affiche remboursé, client voit zéro
Délai banque opaque : 5-10 j sans explication
Refus virement : boutique dit « impossible autre moyen »
Double prélèvement BNPL : refund marchand OK, échéance Klarna toujours active
IBAN demandé par email : client craint phishing
Gorgias estime que 4 à 7 % des tickets post-retour concernent « remboursement non reçu » dont une part significative liée au moyen de paiement (Gorgias, SAV 2026).
Angle #369
Les guides paiement refusé traitent l'échec checkout. Le #194 couvre sync BNPL. Le #368 mentionne avoir si CB expirée. Le #369 isole le workflow refund échoué ou invisible sur moyen fermé : diagnostic, délais, alternatives tracées.
Exemple DTC
Marque mode, 29 tickets ref_exp/mois, agents renvoyaient vers banque sans diagnostic. Après policy REF-EXP + flow REF-EXP-GATE : ref_exp_resolution 89 %, délai médian clôture 4 j, chargeback ref_exp -40 %, CSAT refund 4,4/5.
SLA ref exp
Réponse < 4 h avec statut refund Shopify + délai banque attendu. Si échec processor J+10 : alternative IBAN ou avoir sous 48 h.
Volume typique
Sur boutique 4 000 commandes/mois, comptez 0,3 à 0,8 % tickets liés à refund non visible ou moyen paiement fermé. Pic janvier (cartes expirées fin d'année).
Carte expirée ≠ refund impossible
Erreur fréquente agent : « on ne peut pas rembourser carte expirée ». Souvent le refund part et la banque crédite le compte. Diagnostiquer avant alternative.
Moment parcours
Post-retour J+3 à J+15, post-annulation, post-partial (#368). Client anxieux, ton rassurant + preuves.
En quoi diffère-t-il du BNPL et du paiement refusé ?
Huit contenus voisins, huit rôles support distincts sur remboursement.
Paiements fractionnés (#194)
Fractionné (#194) : sync échéancier Alma/Klarna. Le #369 couvre CB expirée et moyens fermés, pas désync BNPL seul.
Remboursement partiel (#368)
Partial (#368) : avoir si CB expirée. Le #369 détaille workflow complet diagnostic + IBAN.
Paiement refusé
Paiement refusé : échec checkout. Le #369 intervient post-commande refund.
Virement bancaire
Virement (#) : achat par transfer. Le #369 : refund manual IBAN si original transfer seulement.
Litiges paiement
Litiges communication : descripteur relevé. Le #369 : refund routing technique.
Bot statut (#370)
Le futur bot statut (#370) rassurera sans surpromettre. Le #369 pose policy ops et macros.
Chargebacks
Prévention chargeback : ref_exp mal géré = litige. Le #369 trace ARN et alternatives.
Bot retours (#10)
Bot retours (#10) lance RMA. Le #369 intervient post-refund processor.
Promesse #369
Policy REF-EXP, flow REF-EXP-GATE, alternatives grille, 8 macros REF-EXP-*, KPI ref_exp.
Quels scénarios ref_exp tagger avant les macros ?
Cartographier les scénarios remboursement moyen fermé avant macros et procédure finance.
Dix intents ref_exp
ref_exp_card_expired: carte expirée, refund invisibleref_exp_card_replaced: nouvelle carte, cherche sur ancienneref_exp_paypal_closed: compte PayPal fermé ou limitéref_exp_apple_google: wallet, voir relevé deviceref_exp_bnpl_provider: Klarna/Alma, échéancier actifref_exp_bank_transfer_in: achat virement, demande IBAN refundref_exp_processor_failed: Shopify refund failed statusref_exp_wrong_account: client regarde mauvais compte bancaireref_exp_store_credit_ok: accepte avoir vs attendre banqueref_exp_manual_iban: virement manuel après échec processor
Champs ticket obligatoires
order_id, payment_method, refund_status_shopify, refund_date, arn (if any), days_since_refund, ref_exp_intent, alternative_offered, iban_collected (bool), finance_approval.
Mining tickets 90 j
Export « remboursement », « pas reçu », « carte expirée », « PayPal ». Croiser refund Shopify date vs ticket date.
Router helpdesk
Auto-tag ref_exp si order a refund + mots-clés expiré/fermé/non reçu. Queue P2, P1 si > 14 j ou menace chargeback.
Priorisation MVP
Semaine 1 : ref_exp_card_expired + délais banque. Semaine 2 : ref_exp_processor_failed + IBAN. Semaine 3 : ref_exp_bnpl handoff #194.
Comment rédiger la policy REF-EXP et le flow REF-EXP-GATE ?
La policy REF-EXP aligne support, finance et processor sur diagnostic et alternatives.
Douze blocs policy
Définition : refund lancé ou à lancer, crédit non visible client
Étape 1 : vérifier refund status Shopify (success/pending/failed)
Carte expirée : expliquer routing banque 5-10 j avant alternative
Délai attente : 10 j ouvrés CB UE avant escalade alternative
Refund failed processor : alternative obligatoire sous 48 h
Alternatives ordre : 1) attendre banque 2) avoir +5 % 3) virement IBAN manuel
IBAN collection : formulaire sécurisé /pages/refund-iban, pas email libre
Finance approval : IBAN manual > 200 € ou repeat ref_exp
BNPL : handoff workflow #194, pas refund CB direct
PayPal : refund vers balance PayPal même compte fermé temporairement
Documentation : tag ref_exp_* + ARN screenshot order timeline
Pas double refund : vérifier refund_id unique avant manual IBAN
Flow REF-EXP-GATE en sept étapes
Auth : order_id + email
Refund lookup : status, montant, date, ARN
Payment method : CB, PayPal, BNPL, transfer, wallet
REF-TRIAGE : intent ref_exp_* section 3
Délai check : days_since_refund vs seuil 10 j
Client education : macro REF-EXP-EDU banque/carte remplacement
Sortie : wait, avoir, IBAN manual, handoff BNPL (#194)
Carte expirée : message clé
« Les banques créditent généralement le compte lié à la carte, même expirée, sous 5-10 j ouvrés. Vérifiez le compte bancaire complet, pas seule la carte physique. »
Quelle grille d'alternatives appliquer sans double refund ?
La grille alternatives REF-EXP évite double paiement et accélère clôture litige.
Matrice décision
Refund success < 10 j, card expired : éducation + attente, pas IBAN
Refund success > 10 j, client prouve absence : avoir ou IBAN tier 2
Refund failed processor : IBAN ou avoir immédiat
PayPal closed : contacter PayPal support client, refund often reopens access
BNPL active : sync provider #194, pas IBAN parallèle
Client accepte avoir : store credit +5 % bonus, instantané
Virement IBAN manuel
Formulaire sécurisé : IBAN, BIC si hors SEPA, nom titulaire = order billing name. Finance exécute sous 5 j ouvrés. Tag manual_refund_done. Montant = refund Shopify exact.
Vérification identité IBAN
Billing name match + email order + last 4 card digits si CB originale. Supervisor si mismatch nom.
Avoir vs IBAN
Proposer avoir en premier si client rachète souvent. IBAN si client insiste cash ou montant > 300 €.
Anti-fraude ref_exp
Flag si client demande IBAN sur order sans refund Shopify lancé. Refuser jusqu'à retour reçu entrepôt.
Quelles macros REF-EXP-* importer dans le helpdesk ?
Huit macros REF-EXP-* couvrent éducation, attente et alternatives.
REF-EXP-EDU-01 (carte expirée)
« Votre remboursement de [X] € a été lancé le [date] sur le moyen de paiement d'origine. Même si votre carte a expiré, votre banque crédite en général le compte associé sous 5-10 j ouvrés. Vérifiez vos mouvements sur le compte complet. »
REF-EXP-ARN-01
« Référence remboursement (ARN) : [arn]. Communiquez-la à votre banque si besoin. Délai ouverture dossier : 10 j ouvrés. »
REF-EXP-WAIT-01
« Nous sommes à J+[N] depuis le remboursement. Délai normal jusqu'à J+10. Nous vous recontactons si pas de crédit visible. »
REF-EXP-CREDIT-01 (avoir)
« Alternative immédiate : avoir boutique [X] € + bonus 5 % = [Y] €. Code valable 12 mois. Souhaitez-vous l'activer ? »
REF-EXP-IBAN-01
« Après vérification, voici notre formulaire sécurisé pour virement : [lien /pages/refund-iban]. Traitement sous 5 j ouvrés après réception IBAN. »
REF-EXP-PAYPAL-01
« Remboursement envoyé vers votre compte PayPal [email]. Même fermé temporairement, reconnectez-vous ou contactez PayPal avec ref transaction [id]. »
REF-EXP-BNPL-01
« Commande Klarna/Alma : nous synchronisons le remboursement avec votre échéancier. Délai ajustement 3-7 j. Ne payez pas l'échéance si plan annulé. » Voir #194.
REF-EXP-FAILED-01
« Le remboursement automatique a échoué côté processeur. Nous proposons avoir immédiat ou virement IBAN via formulaire sécurisé. »
Import helpdesk
Variables {{refund_amount}}, {{refund_date}}, {{arn}}, {{days_since}}. Lien formulaire IBAN officiel uniquement.
Comment diagnostiquer un refund sur Shopify ?
Le workflow refund expiré Shopify diagnostique timeline et évite double refund.
Diagnostic Admin
Orders → order_id → Timeline : refund events
Status : success, pending, failure + message processor
Copier ARN si disponible (Shopify Payments / Stripe)
Payment method original : visa •••• 4242, PayPal, Klarna
Compare refund_date vs ticket client
Refund failed : retry ou manual
Si processor failure : 1 retry refund même moyen après 24 h. Si 2e échec : REF-EXP-IBAN ou avoir. Note « REF-EXP failed twice ».
Manual IBAN exécution finance
Export hebdo formulaire IBAN validés. Virement SEPA batch. Tag order manual_refund_iban + montant + date. Clôturer ticket ref_exp_resolved.
Wallet Apple Pay / Google Pay
Refund route vers carte tokenisée sous-jacente. Client vérifie app Wallet ou relevé banque lié.
Communication post-manual
Macro confirmation virement exécuté + référence bancaire interne. Inviter CSAT.
Comment configurer l'ops REF-EXP et le formulaire IBAN ?
Le setup ops REF-EXP connecte helpdesk, formulaire IBAN et finance.
Checklist technique
Rédiger policy REF-EXP section 4
Créer page /pages/refund-iban formulaire sécurisé (Shopify Forms)
Sidebar helpdesk : refund status, ARN, payment method, days_since
Importer 8 macros REF-EXP-* helpdesk
Workflow finance approval IBAN > 200 €
Documenter handoff BNPL → #194
Former agents REF-EXP-GATE 30 min
Dashboard ref_exp_volume hebdo
FAQ page /retours
Bloc « Carte expirée ? » : expliquer routing banque 5-10 j, lien SAV si J+10. Réduit tickets anxieux J+3.
Sécurité IBAN
HTTPS, CAPTCHA, order_id pré-rempli auth. Jamais demander IBAN par email non chiffré. Mention anti-phishing macro.
Alignement #370 futur
Bot statut cite refund timeline + REF-EXP-EDU sans promettre IBAN auto.
Quels KPI ref_exp piloter ?
Sans KPI ref_exp, finance ne voit pas coût manual IBAN et repeat tickets.
Sept métriques clés
ref_exp_volume : tickets ref_exp / refunds/mois
ref_exp_resolution : clôturé sans repeat 14 j / total
ref_exp_wait_edu_rate : résolus par attente + éducation / total
ref_exp_manual_iban_rate : virements manuels / ref_exp
ref_exp_store_credit_rate : avoirs / alternatives
ref_exp_processor_fail_rate : failed refunds / total refunds
CSAT intent ref_exp : satisfaction refund invisible
Benchmark DTC
Objectif ref_exp_resolution > 85 %, ref_exp_manual_iban_rate < 15 %, processor_fail < 2 %, CSAT > 4,2/5.
Coût manual IBAN
Tracker coût ops finance par virement vs avoir instant. IBAN reserve pour failed processor et > 10 j prouvé.
Revue mensuelle
Top payment_method ref_exp. Si PayPal spike : macro REF-EXP-PAYPAL refresh. Si BNPL : sync #194 audit.
Quels cas limites et escalades prévoir ?
Sept edge cases ref exp exigent procédure spéciale.
Gift order refund
Refund toujours moyen paiement acheteur, pas destinataire. Expliquer à destinataire si contacte SAV.
Multi-refund partials
Plusieurs partial (#368) sur même order : sommer montants, un IBAN total si manual.
Chargeback parallèle
Client a ouvert chargeback + demande IBAN : stop manual, legal review. Risque double crédit.
Compte joint carte expirée
Crédit sur compte joint, pas carte individuelle. REF-EXP-EDU adapté.
International non-SEPA
IBAN manual hors zone : Wise ou PayPal Payout, délai 7-14 j, frais merchant.
Crypt ou gift card payment
Rare DTC : avoir obligatoire, pas IBAN vers crypto wallet.
Refund pending processor
Status pending < 5 j : pas alternative. REF-EXP-WAIT. Client rassuré.
Fraude IBAN tiers
IBAN nom différent billing : refus sauf procuration prouvée + supervisor.
Comment Qstomy rassure sur les remboursements invisibles ?
Qstomy lookup refund Shopify, applique REF-EXP-GATE et propose éducation ou formulaire IBAN sécurisé.
Capacités refund expiré
ref_exp_lookup : refund status + ARN + days_since
ref_exp_triage : classifier ref_exp_* payment method
ref_exp_edu_bot : macro REF-EXP-EDU personnalisée
ref_exp_credit_offer : avoir +5 % si eligible
ref_exp_iban_link : formulaire sécurisé si failed ou > 10 j
Scénario DTC chiffré
Marque accessoires, 31 tickets ref_exp/mois, 45 % escalades IBAN prématurées.
Après Qstomy REF-EXP flows : 52 % résolus bot éducation seule, ref_exp_resolution 91 %, ref_exp_manual_iban_rate 9 %, CSAT 4,5/5.
Explorez support IA, Shopify, demander une démo.
Quelle checklist pour lancer REF-EXP ?
Checklist REF-EXP (10 étapes)
Auditer tickets ref_exp 90 j
Rédiger policy REF-EXP section 4
Publier grille alternatives section 5
Créer formulaire /pages/refund-iban sécurisé
Importer 8 macros REF-EXP-* helpdesk
Configurer sidebar refund status + ARN
Workflow finance manual IBAN batch
Former agents REF-EXP-GATE 30 min
Documenter handoff BNPL #194
Dashboard ref_exp_resolution hebdo
En bref
#369 = refund moyen fermé ops, pas BNPL sync seul (#194)
Carte expirée : souvent crédit banque 5-10 j, pas blocage
REF-EXP-GATE : lookup → triage → éducation → alternative
IBAN manual : formulaire sécurisé, pas email
KPI ref_exp_resolution : cible > 85 %
FAQ
Carte expirée = remboursement impossible ?
Non dans la majorité des cas. La banque crédite le compte lié. Attendre 10 j avant alternative.
PayPal fermé ?
Refund vers compte PayPal. Client reconnecte ou contacte PayPal support.
Différence avec partial #368 ?
#368 = montant partial. #369 = routing moyen paiement fermé ou refund invisible.
Quand proposer IBAN ?
Refund processor failed immédiat, ou success > 10 j sans crédit prouvé.
BNPL Klarna actif après refund ?
Handoff #194 sync échéancier, pas IBAN parallèle.
Aller plus loin
Testez mystery shop : order test refund simulé carte expirée, vérifiez macro REF-EXP-EDU avant proposition IBAN.
Partagez ce guide #369 avec support et finance : un refund moyen fermé bien diagnostiqué transforme l'anxiété client en confiance retrouvée.
Enzo
6 août 2026
