PCI DSS au Maroc : agrément ou certification, et ce que le standard change pour un commerçant

PCI DSS au Maroc n'est pas un agrément : c'est le standard de sécurité des données de cartes publié par le PCI Security Standards Council, et une plateforme de paiement peut être certifiée conforme à ce standard. Pour un commerçant, la vraie question est celle du périmètre. Si votre client saisit sa carte sur une page de paiement hébergée, dans un périmètre certifié, vous ne voyez jamais de numéro de carte. Si vous construisez votre propre formulaire, vous entrez dans le périmètre de conformité des données de carte. Ce guide explique la différence, ce que la certification d'une plateforme ne fait pas à votre place, et les questions à poser à votre conseil.

Qu'est-ce que PCI DSS ?

PCI DSS est le standard de sécurité des données de cartes publié par le PCI Security Standards Council, conçu, tel que le Conseil le décrit, pour renforcer la sécurité des données des comptes de cartes de paiement et favoriser une large adoption de mesures de sécurité des données cohérentes dans le monde entier. Le niveau 1 est le plus exigeant.

Retenez deux choses de cette définition. D'abord, ce n'est pas un texte de loi marocain : il ne figure pas dans la loi 103-12, et ce n'est pas Bank Al-Maghrib qui le publie. Ensuite, il porte sur un objet précis, les données des cartes de paiement : les autres données de vos clients relèvent d'un autre cadre.

Agrément PCI DSS ou certification : deux notions différentes

L'expression « agrément PCI DSS » mélange deux notions qui n'ont ni la même source ni le même objet. Au Maroc, l'agrément, au sens légal, est celui que Bank Al-Maghrib délivre à un établissement pour qu'il exerce. PCI DSS, lui, est un standard, et une plateforme peut être certifiée conforme à ce standard.

Prenons notre cas pour fixer les idées. ChariPay est une plateforme de paiement marocaine, un PSP opéré par Chari Money, établissement de paiement agréé par Bank Al-Maghrib. Les deux notions s'y retrouvent, portées par deux sujets différents :

Ni l'un ni l'autre ne se transmet à votre entreprise : ce qui vous concerne directement, c'est votre propre périmètre de données de carte.

Avec la page hébergée, votre client saisit sa carte dans un périmètre certifié

De votre côté, le parcours reste simple. Une commande devient une session : vous créez la session côté serveur, vous redirigez l'acheteur vers le checkout hébergé — carte avec 3-D Secure —, et vous recevez le résultat par webhook signé. Un lien de paiement suit la même logique : le client paie sur une page hébergée par ChariPay.

Votre client saisit sa carte sur le checkout hébergé, dans un périmètre certifié PCI DSS niveau 1 : vous ne voyez jamais de numéro de carte, et votre questionnaire d'auto-évaluation s'en trouve réduit — à confirmer avec votre conseil ou votre acquéreur. Côté plateforme, les numéros de carte ne sont jamais écrits en base de données.

Concrètement, ce que vous lisez après un paiement, c'est un statut et un montant — par GET /v1/payment-sessions/{sessionId} pour une session — et votre metadata, renvoyé tel quel dans l'événement : jamais un numéro de carte. Votre serveur, votre base de données, vos e-mails de confirmation et votre outil de support n'ont donc aucune raison d'en contenir un.

Constatez-le vous-même : 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 et payez avec la carte de test fournie, 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.

Avec votre propre formulaire de carte, le périmètre change

Certaines entreprises veulent garder la saisie de la carte dans leur propre interface. Le checkout direct vous laisse construire votre propre formulaire de carte : vérification de la session, envoi des données de carte, retour 3-D Secure, état du paiement. Ces appels ne sont pas authentifiés par votre clé d'API mais par la session et sa clé de vérification à usage unique (vk) — n'y envoyez jamais votre clé d'API — et ils vous placent dans le périmètre de conformité des données de carte. En checkout direct, c'est votre serveur qui exécute les appels /checkout/*, de serveur à serveur ; sur le checkout hébergé, c'est la page de paiement de ChariPay qui les exécute.

Ce choix n'a de sens que si vous avez une raison précise de ne pas utiliser la page hébergée. Le tableau résume ce qui change :

La mise en œuvre technique, appel par appel, est détaillée dans notre article sur le checkout direct. Avant d'y aller, faites valider le changement de périmètre par votre conseil : c'est lui qui vous dira ce que votre formulaire implique pour votre entreprise.

Ce que la certification de ChariPay ne fait pas à votre place

La certification PCI DSS niveau 1 porte sur la plateforme. Elle ne se transmet pas à votre entreprise et ne couvre pas ce qui se passe chez vous. Le périmètre certifié est celui où votre client saisit sa carte ; il ne s'étend ni à votre site, ni à vos ordinateurs, ni à la boîte de réception de votre service client.

Restent donc de votre côté :

• votre site : les pages qui mènent au paiement, vos URL de retour et de notification ;
• vos accès : qui se connecte au portail marchand, avec quel rôle ;
• vos clés d'API : où elles sont stockées, qui peut les lire ;
• ce que vos équipes reçoivent par message : un client pressé peut envoyer sa carte en photo ou en clair, et c'est ainsi que des données de carte peuvent entrer par accident dans une entreprise qui n'en a jamais eu besoin.

Ce que la plateforme fait de son côté — comptabilité en partie double, double validation, journal d'audit, authentification forte — est détaillé sur notre page sécurité et conformité.

Les bonnes pratiques PCI DSS du commerçant

Quelques règles simples gardent les données de carte hors de votre entreprise :

1. 1Ne demandez jamais un numéro de carte par e-mail, par téléphone ou par message, et n'en acceptez pas. Envoyez plutôt un lien de paiement : le client paie sur la page hébergée, et vous recevez le statut.
2. 2Si un client envoie sa carte spontanément, ne la recopiez nulle part et ne la saisissez pas vous-même : répondez par un lien de paiement, et expliquez que la carte se saisit uniquement sur la page de paiement.
3. 3Traitez vos clés d'API comme des secrets : une clé est un secret, jamais dans le navigateur, une application mobile, un dépôt git ou une capture d'écran. Le détail est dans protéger ses clés d'API.
4. 4Protégez l'accès au portail : la double authentification (TOTP) s'active depuis les paramètres de votre compte et, une fois activée, elle est demandée à la connexion ; une ré-authentification est exigée avant chaque action sensible ; donnez à chacun le rôle le plus restreint qui lui suffit.
5. 5Déclarez des URL en `https://` pour vos retours et vos notifications : l'API refuse toute autre URL.

Deux sujets voisins méritent leur propre lecture : les arnaques qui visent le commerçant, de la fausse capture d'écran au faux remboursement, dans fraude au paiement en ligne, et les données personnelles de vos clients, qui relèvent d'un autre cadre que PCI DSS, dans données personnelles et loi 09-08.

Les questions à poser à votre conseil ou à votre acquéreur

Nous ne pouvons pas vous dire quel questionnaire s'applique à votre entreprise : cela dépend de votre intégration, de votre activité et de l'interlocuteur qui vous le demande. Voici les questions à poser, sans réponse toute faite :

1. 1Quel questionnaire d'auto-évaluation s'applique à mon intégration actuelle — page hébergée, liens de paiement ?
2. 2Qu'est-ce qui change si je construis mon propre formulaire de carte ?
3. 3Quelles preuves dois-je conserver, et à quelle fréquence les mettre à jour ?
4. 4Mes outils tiers — messagerie, outil de support, CRM — risquent-ils de recevoir des données de carte, et que faire si cela arrive ?
5. 5Qui, dans mon entreprise, est responsable de ces questions ?

Votre questionnaire est réduit avec la page hébergée — à confirmer avec votre conseil ou votre acquéreur. Pour tout ce qui relève de vos obligations propres, votre conseil reste seul à pouvoir se prononcer : cet article ne constitue pas un avis juridique.

Questions fréquentes

Faut-il un agrément PCI DSS pour vendre en ligne au Maroc ?

PCI DSS n'est pas un agrément : c'est un standard de sécurité des données de cartes, publié par le PCI Security Standards Council. Au Maroc, l'agrément légal est celui que Bank Al-Maghrib délivre à un établissement ; chez ChariPay, il est porté par Chari Money. Ce qui vous concerne, c'est votre périmètre : avec la page hébergée, il est réduit — à confirmer avec votre conseil ou votre acquéreur.

Mon site e-commerce doit-il être conforme à PCI DSS ?

Tout dépend de l'endroit où la carte est saisie. Avec le checkout hébergé, votre client saisit sa carte dans un périmètre certifié PCI DSS niveau 1, vous ne voyez jamais de numéro de carte, et votre questionnaire d'auto-évaluation s'en trouve réduit — à confirmer avec votre conseil ou votre acquéreur. Votre site, vos accès et vos clés restent sous votre responsabilité.

Que signifie PCI DSS niveau 1 ?

PCI DSS est le standard de sécurité des données de cartes publié par le PCI Security Standards Council, et le niveau 1 est le plus exigeant. La plateforme ChariPay est certifiée PCI DSS niveau 1, une certification renouvelée chaque année. Cette certification porte sur la plateforme : elle ne se transmet pas à votre entreprise et ne dispense pas de bonnes pratiques de votre côté.

Est-ce que je vois les numéros de carte de mes clients ?

Non, si vous utilisez la page hébergée ou un lien de paiement : le client saisit sa carte sur la page de paiement, et vous lisez le statut et le montant du paiement. Côté plateforme, les numéros de carte ne sont jamais écrits en base de données. C'est différent si vous construisez votre propre formulaire de carte : vous entrez alors dans le périmètre de conformité des données de carte.

Construire mon propre formulaire de carte change-t-il mes obligations ?

Oui, le périmètre change. Le checkout direct vous laisse construire votre formulaire ; ses appels /checkout/* sont exécutés par votre serveur, de serveur à serveur, et authentifiés par la session et sa clé de vérification à usage unique (vk), jamais par votre clé d'API ; ils vous placent dans le périmètre de conformité des données de carte. Ce choix n'a de sens que si vous avez une raison précise de ne pas utiliser la page hébergée.

Puis-je recevoir un numéro de carte par e-mail ou WhatsApp pour l'encaisser moi-même ?

Ne le faites pas. Un numéro de carte reçu par message entre dans votre entreprise sans aucune protection, et c'est au porteur de confirmer le paiement auprès de sa banque avec 3-D Secure, pas à vous. Envoyez plutôt un lien de paiement, par e-mail ou WhatsApp : le client saisit sa carte sur la page hébergée, avec 3-D Secure, et vous voyez seulement le statut du paiement.

Qui peut confirmer le questionnaire PCI DSS qui s'applique à mon activité ?

Votre conseil ou votre acquéreur, parce que la réponse dépend de votre intégration et de votre activité. Préparez la description de votre parcours de paiement — page hébergée, liens, formulaire maison — et la liste des outils qui reçoivent des messages clients ; notez aussi qui, chez vous, a accès au portail et aux clés d'API. Votre conseil reste seul à pouvoir se prononcer.

Prochaine étape

Voyez par vous-même ce que reçoit votre serveur après un paiement — un statut, jamais un numéro de carte : Commencer en mode test, puis payez avec la carte de test sur la page hébergée. Faites ensuite confirmer votre périmètre par votre conseil ou votre acquéreur. Pour la partie plateforme, la page sécurité et conformité récapitule ce que ChariPay fait de son côté.

Sources

• PCI Security Standards Council — PCI DSS — lu le 2026-10-02
• Bank Al-Maghrib — Loi n° 103-12 relative aux établissements de crédit et organismes assimilés, version consolidée au 31 mars 2022 (PDF) — lu le 2026-10-02