Fraude au paiement en ligne côté commerçant : fausses captures d'écran, faux reçus et accès volés

La fraude au paiement en ligne qui vise le commerçant peut se passer de toute carte volée : une fausse preuve ou un accès volé lui suffisent. Une capture d'écran « paiement effectué », un reçu de dépôt retouché, une redirection vers votre page de succès sans paiement derrière, une demande de remboursement vers un autre compte, un accès volé au portail. La règle qui les désamorce presque toutes tient en une phrase : seul le statut lu dans le portail ou par l'API, ou un webhook signé, prouve qu'un paiement a eu lieu. Ce guide passe en revue chaque scénario, ce qui fait foi, et la checklist à appliquer avant d'expédier.

Fraude au paiement en ligne côté commerçant : ce que 3-D Secure laisse à votre charge

ChariPay est une plateforme de paiement marocaine, un PSP opéré par Chari Money, établissement de paiement agréé par Bank Al-Maghrib. Les paiements par carte passent par l'authentification 3-D Secure : le porteur confirme auprès de sa banque, ce qui protège le commerçant contre l'essentiel des impayés et des contestations. C'est une protection réelle, pas une garantie absolue, et elle porte sur un seul objet : le paiement par carte lui-même. Pour comprendre ce qui fait échouer une authentification, lisez 3-D Secure et taux de réussite.

Les fraudes décrites ici contournent la carte. Elles ne cherchent pas à payer avec la carte d'un autre ; elles cherchent à vous faire croire qu'un paiement a eu lieu, à vous faire rendre de l'argent, ou à prendre la main sur votre compte. 3-D Secure n'y peut rien, parce qu'aucun paiement par carte n'est en jeu. Voici les six scénarios de ce guide, avec ce qui fait foi ou vous protège dans chacun :

L'arnaque à la capture d'écran de paiement et le faux reçu

C'est un scénario simple, et il fonctionne parce qu'il joue sur la vitesse. Un client vous écrit qu'il a payé et joint une capture d'écran : un écran de confirmation, un message de banque, un PDF de reçu. L'image peut être retouchée, venir d'un autre paiement, ou montrer un paiement qui a échoué ensuite. Une capture d'écran n'est jamais une preuve de paiement, quelle que soit sa qualité.

Ce qui fait foi, c'est l'état du paiement chez ChariPay, que vous lisez vous-même. Un lien de paiement a un statut clair — actif, payé, annulé, expiré — et vous êtes notifié dans le portail à l'encaissement. Si vous êtes intégré par l'API, confirmez la commande sur réception du webhook signé. Pour un dépôt en espèces en agence, la règle est la même : dès que le réseau confirme le dépôt, le lien passe « Payé » et vous êtes notifié dans le portail ; côté serveur, l'état du lien se lit par GET /v1/payment-links/{reference}. Une photo de reçu de dépôt ne remplace pas ce statut.

Avant d'expédier une commande, appliquez ces étapes :

1. 1Ignorez l'image et ouvrez le portail : retrouvez le lien ou la transaction de la commande, depuis votre propre session.
2. 2Lisez le statut : « payé » pour un lien à usage unique, ou la transaction correspondante dans la liste pour un lien réutilisable.
3. 3Comparez le montant encaissé au montant de la commande, et la référence au client.
4. 4Côté serveur, si vous êtes intégré, attendez le webhook signé, ou lisez l'état par l'API.
5. 5Expédiez seulement ensuite. Si le statut n'y est pas, répondez poliment que la commande partira dès que le paiement apparaîtra de votre côté.

En vente par messagerie, la vente se conclut dans une conversation et la « preuve » arrive dans la même conversation : la règle ne change pas. Le flux complet, du message au lien de paiement, est dans vendre sur Instagram et WhatsApp.

Voyez un vrai statut changer : Commencer en mode test. Trois champs — nom, e-mail professionnel, entreprise —, un lien d'activation reçu par e-mail pour choisir votre mot de passe, puis le portail, où vous créez votre clé de test après une ré-authentification ; payez un lien avec la carte de test et regardez-le passer « payé », sans argent réel. C'est gratuit, sans limite de durée et sans validation à attendre : la vérification de votre entreprise (KYB) ne conditionne que le passage en production.

La redirection falsifiée : le webhook fait foi

Sur un site e-commerce, la même ruse prend une forme technique. Après le paiement, le checkout hébergé renvoie l'acheteur vers votre URL de succès. Rien n'empêche quelqu'un d'ouvrir directement cette URL, ou de la modifier, sans avoir payé. Si votre site valide la commande parce que l'acheteur est « revenu sur la page de succès », il expédie sans paiement.

La règle est simple : confirmez la commande sur réception du webhook, jamais sur la seule redirection : la redirection dit que l'acheteur est revenu, pas que le paiement est acquis. Et un webhook n'a de valeur que s'il est vérifié. Trois points suffisent à en faire une preuve :

• La signature : X-CHARI-SIGNATURE est un HMAC-SHA256 calculé sur l'horodatage et le corps brut de la requête avec le secret de votre endpoint ; recalculez-le sur les octets bruts, avant tout parsing, et comparez en temps constant.
• L'horodatage : rejetez toute requête dont X-CHARI-TIMESTAMP est décalé de plus de ±5 minutes, pour qu'un ancien message intercepté ne puisse pas être rejoué.
• Le dédoublonnage : dédupliquez sur Chari-Event-Id, stable pour un même événement sur toutes les tentatives, pour qu'une livraison répétée ne valide pas deux fois la même commande.

L'implémentation, avec le récepteur complet, est détaillée dans réussir son intégration des webhooks.

La demande de remboursement vers un autre moyen de paiement

Le scénario du « trop-perçu » est plus subtil. Un client affirme avoir payé deux fois, ou trop, et vous demande de lui renvoyer la différence par virement, sur un RIB qu'il vous communique par message. Parfois le paiement d'origine n'existe même pas : seule une fausse preuve l'accompagne. Parfois il existe, mais le RIB est celui d'un tiers.

La parade tient en deux règles. D'abord, vérifiez dans le portail ce qui a réellement été encaissé, comme pour une capture d'écran. Ensuite, si un remboursement est dû, remboursez l'opération d'origine, et elle seule, en totalité ou partiellement, depuis le portail ou par l'API. Le remboursement se rattache au paiement que vous remboursez ; il ne part pas vers un compte qu'on vous indique. Un remboursement n'est pas instantané côté banque : un client pressé qui exige « tout de suite, sur un autre compte » doit vous alerter.

Ne remboursez jamais par virement vers un RIB reçu par message. Depuis le portail, un virement exécuté ne peut pas être annulé : si le RIB était celui d'un fraudeur, l'argent est parti.

La prise de contrôle du portail

Le portail est l'endroit d'où l'argent sort : virements, paiements de factures. Un accès volé — mot de passe réutilisé, ordinateur partagé, session laissée ouverte — peut donc coûter cher. Première protection, la double authentification (TOTP) s'active depuis les paramètres de votre compte. Une fois activée, elle est demandée à la connexion ; le portail peut aussi l'exiger des utilisateurs habilités aux opérations sensibles — remboursements, virements, gestion des bénéficiaires. S'y ajoutent la ré-authentification avant chaque action sensible et des sessions sécurisées : avec la double authentification activée, un mot de passe volé ne suffit pas à lui seul.

Les rôles réduisent ce qu'un accès compromis peut faire. Les rôles du portail séparent la consultation de l'action : le comptable lit tout sans rien déclencher, le caissier encaisse sans voir le solde ni les virements, le propriétaire ou un gestionnaire habilité déclenche les opérations sortantes. Un compte de caissier compromis ne permet donc pas de virer votre solde.

Pour les virements, deux protections supplémentaires jouent. Chaque virement émis depuis le portail est validé par un code à usage unique à six chiffres, envoyé par e-mail à chaque adresse de validation désignée dans Paramètres → Sécurité ; vous fixez le nombre d'approbateurs requis. Et un délai de sécurité s'applique après l'ajout d'un nouveau bénéficiaire : un intrus ne peut pas ajouter un bénéficiaire inconnu et lui virer votre solde dans la foulée. Le détail de chaque couche est dans sécuriser l'accès au portail.

La clé d'API exposée

Une clé d'API donne accès à votre compte depuis un programme. Une clé est un secret : jamais dans le navigateur, une application mobile, un dépôt git ou une capture d'écran. Les fuites ont des causes banales : une clé collée dans le code d'une page web, un dépôt rendu public, une capture partagée avec un prestataire.

Si une clé a pu être vue, remplacez-la sans attendre : deux clés peuvent coexister le temps d'une rotation, sans coupure, ce qui vous permet de basculer avant de retirer l'ancienne. La conduite à tenir, pas à pas, est dans protéger ses clés d'API.

La fraude interne

Personne n'aime l'envisager, mais une règle de contrôle interne protège aussi vos équipes : quand une seule personne peut faire sortir de l'argent, c'est elle que l'on soupçonne au premier écart. La séparation des tâches évite ce soupçon.

ChariPay l'applique à plusieurs niveaux. Les actions sensibles — reversements, ajustements, gels de compte — exigent un demandeur et un approbateur distincts. Pour les virements, le code de validation part à chaque adresse de validation que vous avez désignée, et vous fixez le nombre d'approbateurs requis. Les rôles séparent la consultation de l'action : le caissier encaisse sans voir le solde ni les virements. Enfin, le journal d'audit est chaîné cryptographiquement : l'historique ne peut pas être réécrit.

En pratique : confiez la préparation et l'approbation des virements à deux personnes différentes, et donnez à chacun le rôle le plus restreint qui lui suffit.

La checklist anti-fraude du commerçant

1. 1N'expédiez jamais sur une capture d'écran ou une photo de reçu : lisez le statut dans le portail.
2. 2Confirmez les commandes en ligne sur le webhook signé, jamais sur la redirection.
3. 3Vérifiez chaque webhook : signature sur le corps brut, horodatage à ±5 minutes, dédoublonnage sur Chari-Event-Id.
4. 4Remboursez uniquement l'opération d'origine, depuis le portail ou par l'API, jamais par virement vers un RIB reçu par message.
5. 5Ne partagez jamais un accès : chaque utilisateur a sa propre connexion au portail et active la double authentification (TOTP) depuis les paramètres de son compte.
6. 6Attribuez des rôles : caissiers pour encaisser, comptable pour lire, un nombre réduit de personnes habilitées pour les opérations sortantes.
7. 7Désignez vos adresses de validation des virements dans Paramètres → Sécurité et fixez le nombre d'approbateurs requis.
8. 8Traitez chaque nouveau bénéficiaire comme un signal : un ajout que vous n'avez pas fait doit déclencher une vérification immédiate.
9. 9Gardez vos clés d'API côté serveur et faites-les tourner au moindre doute.
10. 10Revoyez les accès à chaque départ d'un collaborateur.

Ce que la plateforme fait de son côté — comptabilité en partie double rapprochée chaque jour, supervision continue, données sensibles masquées dans les journaux — est sur notre page sécurité et conformité.

Questions fréquentes

Comment savoir si une capture d'écran de paiement est authentique ?

Vous ne pouvez pas le savoir à partir de l'image, et vous n'en avez pas besoin. Ouvrez le portail depuis votre propre session et lisez le statut du lien ou de la transaction : « payé », avec le bon montant. Si vous êtes intégré par l'API, attendez le webhook signé. Tant que ce statut n'apparaît pas de votre côté, la commande n'est pas payée, quelle que soit la capture reçue.

Un client m'envoie la photo de son reçu de dépôt en espèces : est-ce suffisant ?

Non. Pour un paiement en espèces sur un lien de paiement, dès que le réseau confirme le dépôt, le lien passe « Payé » et vous êtes notifié dans le portail ; côté serveur, l'état du lien se lit par GET /v1/payment-links/{reference}. Pour une commande de votre boutique hébergée, lisez son statut dans le portail. Attendez ce statut avant de livrer : la photo d'un reçu ne le remplace pas.

La page de confirmation suffit-elle à prouver qu'un client a payé ?

Non. Confirmez la commande sur réception du webhook, jamais sur la seule redirection : la redirection dit que l'acheteur est revenu, pas que le paiement est acquis. N'importe qui peut ouvrir votre URL de succès sans avoir payé. Le webhook, lui, est signé avec le secret de votre endpoint et horodaté : vérifiez la signature et rejetez tout décalage de plus de ±5 minutes.

Est-ce que 3-D Secure protège le commerçant contre toutes les fraudes ?

Non. 3-D Secure protège le commerçant contre l'essentiel des impayés et des contestations sur les paiements par carte, parce que le porteur confirme auprès de sa banque. Il ne peut rien contre les fraudes où aucun paiement par carte n'a lieu : fausse capture d'écran, faux reçu, redirection falsifiée, demande de remboursement vers un autre compte, accès volé au portail.

Un client demande à être remboursé sur un autre compte : que faire ?

Refusez poliment. Vérifiez d'abord dans le portail ce qui a réellement été encaissé. Si un remboursement est dû, remboursez l'opération d'origine, en totalité ou partiellement, depuis le portail ou par l'API : il se rattache au paiement d'origine. Ne virez jamais d'argent vers un RIB reçu par message : un virement exécuté ne peut pas être annulé.

Comment empêcher un collaborateur de déclencher seul un virement ?

Combinez deux réglages. Les rôles d'abord : le caissier encaisse sans voir le solde ni les virements, le comptable lit tout sans rien déclencher. La validation par code ensuite : chaque virement émis depuis le portail exige un code à usage unique envoyé par e-mail aux adresses de validation que vous désignez, et vous fixez le nombre d'approbateurs requis. Enfin, le journal d'audit est chaîné cryptographiquement : l'historique ne peut pas être réécrit.

Que vérifier avant d'expédier une commande payée en ligne ?

Trois choses, lues de votre côté et non dans un message du client : le statut du paiement — dans le portail, par l'API ou dans le webhook signé —, le montant encaissé comparé à celui de la commande, et la référence qui relie le paiement au bon client. Pour un dépôt en espèces, attendez que le lien passe « Payé ».

Prochaine étape

Rejouez la checklist en conditions réalistes, sans argent réel : Commencer en mode test, puis payez un lien avec la carte de test, regardez le statut changer, vérifiez un webhook signé et remboursez l'opération. Une fois ces réflexes en place, renforcez les accès avec sécuriser l'accès au portail.