Fraudes et atteintes aux personnes
Particuliers et entreprisesFraude à la carte bancaire en ligne
Card-not-present fraud
Les données d’une carte sont utilisées pour des achats non autorisés.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
Une situation concrète
Une opération inconnue apparaît sur votre relevé alors que votre carte est toujours dans votre portefeuille. Les données ont pu être saisies sur une fausse boutique, volées dans un formulaire compromis ou récupérées ailleurs. La présence physique de la carte ne suffit pas à empêcher son utilisation à distance.
Comment cela fonctionne
La fraude à la carte en ligne utilise des données ou des autorisations de paiement sans votre intention réelle. Elle peut suivre un hameçonnage, un faux conseiller ou la compromission d’un commerçant. Il faut distinguer une opération inconnue d’un abonnement oublié ou d’un libellé commercial inhabituel, puis agir rapidement avec la banque si la fraude est suspectée.
- Les données sont exposées
Carte, compte ou validation détournés.
- Une opération est tentée
La carte physique n’est pas nécessaire.
- Le compte peut être débité
Le titulaire découvre une opération qu’il n’a pas demandée.
Les signes qui doivent attirer l’attention
- Un achat ou une demande de validation ne correspond à aucune action de votre part.
- Un site collecte des informations inhabituelles pour un paiement.
- Un appel vous dicte la validation d’une opération que vous n’avez pas initiée.
Ces signes invitent à vérifier la situation. Pris isolément, ils ne prouvent pas tous qu’une attaque a réussi.
Ce que vous pouvez faire
Vos premiers réflexes
Lisez le montant et le bénéficiaire avant chaque validation. Pour une opération inconnue, contactez rapidement la banque par son canal officiel et relevez sa référence.
Si vous êtes responsable du service ou de l’organisation
Définissez des plafonds et des alertes pour les cartes professionnelles. Rapprochez les relevés des achats autorisés et prévoyez qui contacte la banque en cas d’anomalie.
Une carte non perdue peut être utilisée frauduleusement à distance ; l’origine ne se déduit pas du seul relevé.
À vous de décider
Votre carte est dans votre poche. Un achat frauduleux en ligne reste-t-il possible ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Oui. Des données de carte ou un accès de paiement volés peuvent suffire pour certains achats à distance. La carte physique n’a pas besoin d’avoir disparu.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Une authentification bancaire réussie n’explique pas toute la transaction
Pour O17, le parcours 3-D Secure aboutit, puis une autorisation et une capture de 89 € sont enregistrées. L’adresse de livraison change ensuite. Il faut examiner cette modification avec la transaction : une authentification initiale ne valide pas automatiquement tous les changements ultérieurs du dossier marchand.
Le second cas est différent : l’authentification aboutit, mais l’autorisation est refusée et aucune capture n’est enregistrée. Confondre authentification, autorisation et capture conduirait à compter un paiement qui n’a pas eu lieu. Les journaux du marchand et du prestataire doivent être rapprochés avec les identifiants de transaction, pas seulement le montant et l’heure.
Une authentification réussie n’établit pas à elle seule l’intention du titulaire. Il peut avoir été trompé sur l’objet de la validation ou avoir subi un détournement de compte. L’enquête technique doit conserver les éléments du parcours, les changements de commande et l’état des fonds. Les règles de responsabilité ou de contestation ne se déduisent pas du seul résultat 3-D Secure.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Commande O17
Acheteur / client vers Marchand
Trace version et montant
- Action
Authentification 3DS
Marchand vers 3DS / émetteur
Trace D8
- Réponse
Résultat Y
3DS / émetteur vers Marchand
Trace ne vaut pas capture
- Action
Demande d’autorisation
Marchand vers PSP / banque
Trace A8
- Réponse
Autorisation puis capture
PSP / banque vers Marchand
Trace C8
- Action sur place
Rapprochement livraison
Marchand
Trace adresse modifiée
Comment repérer cette attaque
Indices à rechercher
Repérer les paiements non reconnus, les changements d’adresse ou de bénéficiaire après validation et les incohérences d’appareil entre commande et paiement.
Éléments à croiser
Suivre une même commande de l’authentification à l’autorisation puis à la capture. Confirmer le résultat chez le prestataire ; une page de succès ou une notification non vérifiée ne prouve pas un encaissement.
Limites de l’interprétation
Une authentification 3-D Secure réussie n’implique ni autorisation bancaire, ni capture, ni absence de fraude. Le lecteur non marchand devra demander ces éléments à sa banque ; il n’a pas accès aux logs du commerçant.
Comment réagir
Préserver les références, bloquer les accès ou moyens exposés avec les acteurs concernés et rapprocher captures/remboursements. Examiner l’origine de l’exposition : compte client, terminal, formulaire ou simple réutilisation de données volées ailleurs.
Vérifier la correction
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- Vérifier qu’une authentification réussie avec autorisation refusée ne compte pas comme encaissement.
- Tester reprises idempotentes et captures partielles sans double comptage.
- Contrôler l’absence de données sensibles de carte dans les logs et rapports.
À vous de raisonner
3-D Secure réussit, mais l’autorisation est refusée et aucune capture n’est enregistrée. Peut-on comptabiliser ce cas comme un paiement encaissé ?
Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Non. Il faut rapprocher les statuts du marchand et du prestataire avec l’identifiant de transaction. La réussite de l’authentification ne prouve ni l’encaissement ni l’intention du titulaire. Conservez les résultats de chaque étape pour qualifier ce qui s’est réellement produit.
Consulter les détails techniques
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.
status=Y- Résultat d’authentification 3-D Secure illustré, pas statut universel d’un objet Stripe et pas preuve de débit.
capture- Étape distincte de l’autorisation : c’est son résultat et son montant qu’il faut vérifier dans le rapprochement marchand.
Chaîne de transaction
JournalDonnées fictives ; conserver uniquement des tokens ou références, jamais le PAN complet ni le cryptogramme.
order=O17 three_ds_id=D8 authentication_status=Y flow=challenge
order=O17 authorization_ref=A8 result=approved amount=89.00
order=O17 capture_ref=C8 result=success amount=89.00
order=O17 delivery_address_changed=true device_first_seen=true
order=O18 authentication_status=Y authorization=declined capture=nonePréparer une collecte dans votre environnement
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.
Stripe — paiement et journaux de requêtes API
- Où les trouver
- Dans le Dashboard, ouvrir le paiement concerné ; dans Workbench → Logs, retrouver les requêtes API correspondantes et leur identifiant de requête.
- Quoi relever
- Retrouver identifiants de paiement, commande et requête, résultat 3-D Secure, autorisation, capture et éventuel remboursement. Comparer montants et heures ; le vocabulaire dépend du prestataire.
- Accès et prérequis
- Accès habilité au compte marchand. Un autre prestataire utilise ses propres statuts et identifiants. Ne jamais exporter le numéro complet de carte ou le cryptogramme pour cette analyse.
Service concerné — audit et historique à vérifier
- Où les trouver
- Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
- Quoi relever
- Dans la boutique, rechercher création de commande, changement d’adresse et traitement des notifications du prestataire. Conserver les identifiants d’événements pour reconnaître les doublons et les notifications reçues en retard.
- Accès et prérequis
- Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- RéseauMagecart
MyPillow : un script espion au milieu du paiement
En octobre 2018, un script injecté dans la boutique MyPillow collecte les informations de paiement. Après le retrait d’un premier script, les attaquants conservent un accès et en ajoutent un autre, dissimulé derrière un nom de domaine ressemblant à celui d’un service légitime.
Ce qu’établit la source. Microsoft documente ce cas dans sa présentation des investigations sur Magecart. Cette appellation recouvre plusieurs groupes de cybercriminels ; elle ne permet pas d’attribuer tous les vols de carte sur le Web à la même équipe.
Consulter le rapport Gather threat intelligence and perform infrastructure chaining — cas MyPillowMicrosoft Learn · Mis à jour le
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à aucun de ces groupes.
Si vous pensez être concerné
- Contactez immédiatement la banque par son canal officiel pour les mesures adaptées.
- Relevez les opérations concernées et conservez les éléments de la commande éventuelle.
- Sécurisez les comptes associés si un mot de passe ou une session a aussi été exposé.
Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- Cybermalveillance — fraude à la carte bancaire — cybermalveillance.gouv.fr
- PCI Security Standards Council — sécurité des paiements — pcisecuritystandards.org
- EMVCo — EMV 3-D Secure — www.emvco.com
- PCI SSC — bibliothèque documentaire — www.pcisecuritystandards.org
