Intégration CMI : paiement en dirham sur votre site e-commerce

Le Centre Monétique Interbancaire a été fondé en 2001 et est opérationnel depuis 2004. Il fédère aujourd'hui plus de 35 banques et établissements de paiement au Maroc — Attijariwafa Bank, CIH, BMCE Bank of Africa, BCP, Société Générale Maroc, Crédit Agricole du Maroc, BMCI et d'autres — qui émettent toutes des cartes Visa et Mastercard sous l'interbancarité CMI.

Un site e-commerce qui n'accepte que PayPal ou une carte internationale exclut de fait l'immense majorité des acheteurs marocains : leurs cartes bancaires passent par le réseau CMI, et un paiement en devises étrangères génère des frais de change à leur charge. L'objection courante — « PayPal suffit » — ignore que l'adhésion à PayPal reste faible chez les particuliers marocains, et que les frais de change sur chaque achat constituent un frein réel à l'acte d'achat. CMI traite des transactions en dirham marocain (MAD), directement depuis le compte bancaire de l'acheteur, sans conversion et sans friction.

L'affiliation CMI ne s'obtient pas directement auprès du CMI : elle passe par l'une des banques partenaires du réseau. Le marchand ouvre un compte professionnel dans une banque membre, puis dépose un dossier d'adhésion e-commerçant auprès de cette banque, qui le transmet au CMI.

Deux profils sont acceptés : les personnes morales (sociétés constituées) et les personnes physiques exerçant une activité commerciale. Les pièces à fournir varient selon le statut, mais le principe reste le même dans les deux cas : démontrer l'existence légale de l'activité et la capacité du signataire.

Une condition préalable est souvent sous-estimée : le site doit être en ligne et pleinement fonctionnel au moment de la demande. La banque ou le CMI effectue une visite technique du site avant de valider l'affiliation. Un site en construction ou servi en HTTP simple sera refusé.

L'intégration de la passerelle CMI impose des contraintes côté serveur que l'hébergement doit satisfaire avant même l'écriture d'une ligne de code de paiement. Ces prérequis ne sont pas des recommandations : un site qui ne les respecte pas sera refusé à l'affiliation ou verra ses transactions échouer en production.

HTTPS obligatoire sur l'ensemble du site. Le CMI exige un certificat SSL valide et actif sur le domaine du marchand. Les pages de paiement mais aussi les pages de notification (callback) doivent être servies exclusivement en HTTPS. Un certificat auto-signé ou expiré entraîne l'échec immédiat de la validation d'affiliation.

URL de notification (callback) joignable depuis l'extérieur. Le serveur CMI envoie une notification HTTP POST vers l'URL de callback configurée dans l'espace marchand pour confirmer chaque transaction. Cette URL doit être joignable depuis les serveurs CMI à tout moment, sans filtrage d'IP côté pare-feu, et répondre dans un délai raisonnable. Un hébergement derrière un réseau privé sans règle de NAT entrant, ou un serveur dont le port 443 est filtré, bloque ces notifications et laisse les commandes en état « en attente » côté marchand.

Résolution DNS stable. Le nom de domaine du site et de l'URL de callback doit se résoudre correctement et de façon stable. Une propagation DNS incomplète lors du lancement ou un changement d'hébergeur sans délai de transition peut provoquer des échecs de notification.

Support de 3D Secure. Le protocole 3D Secure (Verified by Visa / Mastercard SecureCode) est activé par défaut sur le réseau CMI. L'acheteur est redirigé vers la page d'authentification de sa banque, puis renvoyé vers l'URL de retour du marchand. L'hébergement doit autoriser ces redirections et ne pas bloquer les agents utilisateurs ou les IP des serveurs CMI dans les règles de sécurité applicative.

Le CMI propose deux protocoles d'intégration principaux pour les sites e-commerce.

CMI Direct Pay est la méthode d'intégration standard. Le marchand redirige l'acheteur vers la page de paiement hébergée par le CMI (hébergement CMI de la page de saisie des données de carte), ce qui exonère le site marchand de la gestion directe des données de carte et simplifie la conformité PCI-DSS. Les paramètres de la transaction (montant, devise, référence commande, URL de retour, URL de callback) sont transmis dans un formulaire HTML signé par une clé partagée. Le serveur CMI valide la signature, affiche la page de paiement, puis notifie le marchand en POST sur son URL de callback.

3D Secure est activé par défaut sur les transactions CMI. Au cours du paiement, l'acheteur est redirigé vers la page ACS (Access Control Server) de sa banque, qui lui envoie un code de validation. Ce mécanisme transfère la responsabilité de la fraude vers la banque émettrice dès lors que l'authentification aboutit — un avantage opérationnel direct pour le marchand en cas de litige.

Dans les deux cas, l'URL de callback doit être absolue, en HTTPS, et joignable depuis l'internet public. Le CMI ne supporte pas les URLs en IP nue ni les ports non standard sur les connexions entrantes vers le site marchand.

La facturation en dirham est un point souvent négligé dans les cahiers des charges e-commerce. Lorsqu'un acheteur marocain paie sur un site facturant en euros ou en dollars, sa banque applique un taux de change et peut ajouter une commission de conversion. Ce surcoût — souvent entre 2 % et 4 % selon la banque et le type de carte — est visible sur le relevé bancaire de l'acheteur et constitue un frein psychologique à l'achat, en particulier pour des paniers de faible valeur.

Les transactions CMI sont libellées en dirham marocain (MAD). L'acheteur voit le montant exact de sa commande en dirham, sans surprise de conversion. Le marchand est réglé en dirham sur son compte professionnel marocain. Aucune des deux parties ne supporte de frais de change.

Pour les agences qui gèrent des clients dont l'audience est majoritairement marocaine, c'est un argument commercial direct : une intégration CMI dans le tunnel d'achat améliore le taux de conversion sur cette audience, sans modification du contenu du site.

Les trois prérequis techniques du CMI — HTTPS actif, URL de callback joignable publiquement, résolution DNS stable — sont directement conditionnés par le choix de l'hébergeur.

Un hébergement qui inclut le certificat SSL dans son plan (émission et renouvellement automatiques via Let's Encrypt ou une autorité équivalente) évite la principale cause d'échec à l'affiliation : un certificat expiré ou une chaîne incomplète. L'activation HTTPS dès la mise en ligne du site, avant même le dépôt du dossier marchand, est la séquence qui évite les allers-retours avec la banque.

La facturation en dirhams côté hébergement est un avantage complémentaire pour les agences qui gèrent plusieurs clients marocains : payer l'infrastructure en MAD, recevoir des factures en MAD avec TVA marocaine, et intégrer une passerelle CMI dans les sites livrés forment un ensemble cohérent côté comptabilité client. Une agence qui héberge ses clients e-commerce sur un plan incluant SSL, HTTPS et facturation en dirhams réunit sur un seul prestataire les trois conditions que CMI exige à l'affiliation.

Cinq problèmes reviennent systématiquement lors de la mise en production d'une intégration CMI. Les voici avec leur message ou symptôme exact et leur résolution.

Erreur 1 — Callback non reçu / commande bloquée en « en attente ».
Symptôme : la page de paiement CMI s'affiche, l'acheteur valide son paiement, mais la commande reste en attente côté marchand. Cause : l'URL de callback n'est pas joignable depuis les serveurs CMI — pare-feu, règle iptables bloquant les connexions entrantes sur le port 443, ou hébergement derrière un réseau privé. Résolution : vérifier que le port 443 est ouvert en entrée et que l'URL de callback répond à un curl depuis une IP externe.

Erreur 2 — « Signature incorrecte » ou « Invalid hash ».
Symptôme : la page CMI retourne une erreur de signature. Cause : la clé partagée (store key) saisie dans le formulaire d'intégration ne correspond pas à celle configurée dans l'espace marchand, ou les paramètres sont encodés différemment (encodage URL, casse des champs). Résolution : re-vérifier la clé dans client.cmi.co.ma, s'assurer que l'ordre des champs dans la chaîne à signer correspond exactement à la documentation CMI.

Erreur 3 — Certificat SSL refusé à l'affiliation.
Symptôme : le dossier d'affiliation est retourné avec la mention « site non sécurisé » ou « certificat invalide ». Cause : certificat auto-signé, chaîne d'autorité incomplète, ou domaine servi partiellement en HTTP. Résolution : tester avec SSL Labs avant de soumettre, s'assurer que toutes les pages (y compris la callback) répondent en HTTPS avec un certificat signé par une autorité reconnue.

Erreur 4 — Redirection 3D Secure échoue ou boucle.
Symptôme : l'acheteur est redirigé vers la page de sa banque, mais le retour vers le site marchand aboutit à une erreur 404 ou une page blanche. Cause : l'URL de retour (okUrl / failUrl) pointe sur un chemin inexistant après déploiement, ou le serveur bloque les redirections POST. Résolution : vérifier les URLs de retour dans la configuration CMI et s'assurer qu'elles sont actives sur l'hébergement de production.

Erreur 5 — Montant en double sur le relevé marchand.
Symptôme : une même commande apparaît deux fois dans le relevé CMI. Cause : le callback a été appelé deux fois (timeout côté serveur → retry CMI) et la logique applicative n'a pas d'idempotence sur la référence commande. Résolution : vérifier la référence commande (oid) à la réception du callback et ne valider la commande que si elle n'est pas déjà marquée comme payée.

L'intégration CMI n'est qu'un des aspects de la conformité d'un site e-commerce marocain. La TVA marocaine (20 % sur les services numériques) s'applique dès lors que le prestataire est domicilié au Maroc et que le service est rendu à un client marocain — un point développé dans l'article TVA marocaine et hébergement web. Les données personnelles collectées lors du processus de paiement sont soumises à la loi 09-08 et aux recommandations de la CNDP, en particulier si elles sont hébergées hors du Maroc — voir Conformité CNDP et hébergement hors Maroc.

Pour les agences qui enregistrent des noms de domaine .ma pour leurs clients, l'accréditation ANRT du registrar est une condition préalable : un domaine .ma déposé via un registrar non accrédité n'est pas valide. L'article Megalogi, registrar accrédité ANRT détaille ce point.

L'ensemble de ces contraintes — CMI, TVA, CNDP, ANRT — forment le cadre réglementaire d'un projet e-commerce marocain. Les gérer sur un seul prestataire d'hébergement qui facture en dirhams, inclut le SSL, et est lui-même ancré dans le tissu légal marocain simplifie la gestion de projet pour l'agence comme pour son client.