Au moment du paiement, le design doit réduire l’incertitude. L’utilisateur veut savoir ce qu’il achète, combien il paie et ce qui arrivera ensuite.

Afficher le vrai montant avant de continuer

Le récapitulatif doit préciser l’offre, le périmètre et la devise de débit. Une conversion indicative n’est pas le taux appliqué par la banque du client. Si le paiement est débité en MAD, indiquez ce montant clairement avant le départ vers la banque et expliquez les éventuels frais de conversion bancaires.

Demander le minimum nécessaire

Des libellés visibles, l’autocomplétion et des erreurs situées près des champs facilitent la saisie. Ne forcez pas le pays de facturation sur Maroc pour un client international. Les conditions doivent être accessibles et leur acceptation explicite. Ne collectez jamais un numéro de carte dans un simple formulaire de contact.

Séparer expérience et preuve de paiement

Le navigateur peut afficher une progression, mais il ne décide ni du prix ni du succès du paiement. Le serveur crée la commande et vérifie la notification du prestataire. Les notifications répétées doivent être traitées sans créer plusieurs commandes ni déclencher plusieurs prestations.

Prévoir les situations imparfaites

Un client peut fermer son navigateur alors que le paiement aboutit. Une notification peut arriver en retard. Une confirmation doit refléter le statut vérifié : en attente, payé ou échoué. Les emails transactionnels se déclenchent après confirmation et leur envoi doit pouvoir être retenté sans modifier la commande.

Concevoir le récapitulatif comme un contrat lisible

Le récapitulatif doit répondre immédiatement à quatre questions : qu’est-ce que j’achète, combien vais-je payer, quand serai-je livré ou contacté, et que se passe-t-il après le paiement ? Sur mobile, ces informations doivent rester visibles sans obliger l’utilisateur à mémoriser le contenu d’une page précédente. Le nom de l’offre, le périmètre, le montant en MAD et les frais éventuels doivent être regroupés avant le bouton de paiement.

Si le prix affiché est en EUR ou USD alors que le débit se fera en MAD, expliquez la différence. Le taux affiché par votre site est indicatif ; la banque du client applique son propre taux. Cette clarification évite une impression de montant caché au moment de la redirection vers CMI ou une autre passerelle.

Simplifier la saisie sans supprimer les informations utiles

Un checkout n’est pas un questionnaire marketing. Demandez le nom, l’email, le téléphone et les informations de facturation indispensables. Rendez les champs optionnels visibles comme tels, utilisez les bons claviers mobiles et conservez les données saisies si une erreur se produit. Les messages d’erreur doivent être situés près du champ concerné et expliquer comment corriger, pas seulement signaler un problème.

L’autocomplétion du navigateur, la validation en temps utile et une longueur de champ raisonnable réduisent les abandons. Évitez les masques de saisie qui bloquent les numéros internationaux. Si vous acceptez des clients hors Maroc, ne forcez ni l’indicatif ni le code postal marocain.

Rassurer sans transformer la page en catalogue de logos

Les signaux de sécurité sont utiles lorsqu’ils répondent à une inquiétude précise. Expliquez que le paiement se déroule sur la page hébergée du prestataire et que votre site ne reçoit ni le numéro de carte ni le CVV. Indiquez le nom du prestataire, la devise de débit et le fait que la transaction est protégée par les contrôles bancaires applicables.

Un excès de badges peut produire l’effet inverse si les visuels semblent décoratifs ou non vérifiables. Mieux vaut une phrase claire, un lien vers les conditions et une confirmation professionnelle qu’un mur de logos. Les informations de contact visibles, la raison sociale et les conditions de remboursement participent aussi à la confiance.

Prévoir la continuation après paiement

Le client ne doit pas se demander si son paiement a fonctionné. Après la notification vérifiée, affichez la référence de commande, le service commandé, le montant et la prochaine étape. Si la notification n’est pas encore arrivée, présentez un statut d’attente plutôt qu’une promesse de succès. Si le paiement échoue, proposez de réessayer ou de contacter le support sans perdre les informations saisies.

L’email de confirmation répète les mêmes informations et sert de référence. Il ne doit pas contenir de données bancaires sensibles. Pour les prestations, précisez le délai ou la méthode de contact prévue ; pour un produit, précisez la livraison, le transporteur et les conditions de retour.

Tester le tunnel avec des scénarios réels

Testez sur un téléphone moyen de gamme, avec une connexion instable, un clavier réel et des interruptions : appel entrant, changement d’application, fermeture du navigateur, notification bancaire lente. Vérifiez également le retour depuis la page de paiement et la répétition de la notification serveur. Un bon checkout ne crée pas deux commandes lorsque le client recharge la page.

Mesurez les abandons par étape : début du formulaire, erreurs de validation, départ vers la banque, retour et confirmation. Ces données orientent les corrections. Une baisse de conversion n’est pas toujours causée par le design ; elle peut venir du prix, de la méthode de livraison ou d’un message de confiance insuffisant.

Relier UX, technique et suivi commercial

Le checkout mobile n’est pas un écran isolé. Il dépend de la qualité de la page produit, du choix de la passerelle, de l’hébergement, des emails et du service client. Une équipe doit pouvoir retrouver une commande, comprendre son statut et expliquer au client ce qui s’est passé. C’est pourquoi la conception UX et l’intégration technique doivent être pensées ensemble.

Pour approfondir la partie technique, consultez notre checklist d’intégration CMI. Pour travailler le parcours global, notre expertise UI/UX et ecommerce permet de concevoir un tunnel clair, mesurable et sécurisé.

Questions à poser avant de lancer

Testez si le montant final est visible avant le paiement, si les champs fonctionnent avec un téléphone réel, si les erreurs sont compréhensibles et si le client sait ce qui se passera après la transaction. Vérifiez les états intermédiaires : commande créée, redirection, autorisation en attente, succès confirmé et échec. Chaque état doit avoir un message adapté.

Plan d’action raisonnable

Parcourez le checkout sur plusieurs téléphones, avec une connexion limitée et des interruptions. Corrigez d’abord les prix peu visibles, les champs difficiles et les retours incohérents. Documentez ensuite le comportement attendu pour le support : comment retrouver une commande, vérifier son statut et répondre au client sans exposer de données bancaires.

Checklist de lancement

  • Prix, périmètre et devise de débit visibles avant la redirection.
  • Champs limités au nécessaire, autocomplétion et erreurs claires.
  • Explication du paiement hébergé et des informations de contact.
  • Statuts confirmé, en attente et échoué affichés correctement.
  • Emails et références de commande vérifiés après notification serveur.

Le signal que le checkout est prêt

Le parcours est prêt lorsque plusieurs utilisateurs réels peuvent terminer sans demander où cliquer ni douter du montant. Les scénarios d’échec doivent être aussi propres que le succès. Si le support ne peut pas retrouver une commande ou expliquer son statut, le problème n’est pas seulement visuel : la logique d’exploitation doit être corrigée.