Intégration de passerelle de paiement au Maroc pour votre logiciel métier

Ce que veut dire « intégrer une passerelle de paiement »

Une passerelle de paiement est le service qui transporte une transaction par carte entre votre client, sa banque et la vôtre. Elle affiche le formulaire de carte, déclenche la vérification 3-D Secure, reçoit la réponse de la banque et vous dit, en une ou deux secondes, si le paiement est accepté ou refusé.

L’intégrer, c’est relier ce service au logiciel dans lequel votre activité est déjà enregistrée. L’objectif n’est pas d’avoir une page de paiement quelque part : c’est qu’une facture émise par votre logiciel passe d’elle-même au statut « payée » quand le client a réglé, sans que personne ne recopie un montant d’un écran vers un autre.

C’est là que se trouve le vrai gain. Les entreprises dans ce cas ont souvent déjà une solution d’encaissement quelque part, mais elle vit à côté de leur gestion. Quelqu’un exporte un fichier, quelqu’un d’autre pointe les virements, et le mois se termine avec des écarts que personne ne sait expliquer. Une intégration propre supprime cette zone grise.

ERP, CRM, logiciel de caisse : connecter le paiement par API

Nous ne remplaçons pas votre outil. Vos équipes l’utilisent chaque jour, elles le connaissent, et une migration coûterait bien plus cher que le problème à résoudre. Nous nous branchons dessus par son API, c’est-à-dire par la porte que le logiciel prévoit pour communiquer avec l’extérieur.

Selon votre métier, cela prend des formes différentes. Un ERP émet une facture et veut y attacher un paiement : nous lui ajoutons la possibilité d’envoyer une demande de règlement et de recevoir la confirmation. Un CRM veut encaisser un acompte dès que l’affaire est gagnée. Un logiciel de caisse veut encaisser à distance une commande prise par téléphone. Une plateforme métier veut facturer ses utilisateurs à l’usage.

Nous travaillons aussi bien avec un logiciel du marché qu’avec un outil développé sur mesure pour vous. Si l’éditeur publie une documentation, nous partons de là. S’il s’agit d’un développement interne, nous parlons directement à votre développeur ou à votre prestataire. Et si le paiement doit aussi vivre dans votre application mobile Android et iOS, il s’appuie sur la même intégration côté serveur : le travail n’est pas fait deux fois.

Comment se déroule l’intégration

Le premier échange sert à comprendre votre logiciel et vos flux d’argent. Qui paie, quand, quel montant, et ce que votre équipe doit voir après. Nous demandons la documentation de votre API et un accès de test, et nous vous disons ce qui est faisable avant que vous engagiez un budget.

Vient ensuite le travail de connexion, en trois morceaux. L’appel de paiement, que votre logiciel émet avec sa clé API. La page où votre client saisit sa carte : par défaut, nous la laissons chez le prestataire de paiement, sur sa page sécurisée, de sorte que les numéros de carte ne passent jamais par vos serveurs. C’est en général la première question d’un directeur technique, parce que c’est elle qui détermine l’étendue de son périmètre PCI DSS.

Le troisième morceau est le retour d’information : le webhook, cette notification que le prestataire envoie à votre serveur pour lui dire que l’argent est arrivé. C’est la partie que beaucoup d’intégrations bâclent, et elle se vérifie : signature du message, rejeu en cas de panne, traitement d’une notification reçue deux fois. Sans elle, vous avez encaissé, mais votre système ne le sait pas.

Nous traitons les cas désagréables en même temps que les cas simples : un client qui ferme son navigateur avant la fin, une carte refusée, un double clic sur le bouton de paiement, un remboursement à passer. Ce sont ces situations qui produisent les litiges et les écarts de caisse lorsqu’elles n’ont pas été prévues au départ.

Nous ne promettons pas un délai avant d’avoir lu votre documentation. Un logiciel bien documenté se connecte vite ; un outil ancien sans API demande un détour. Vous recevez une estimation précise après cette lecture, et nous vous prévenons immédiatement si quelque chose découvert en route la remet en cause.

Environnement de test avant la mise en ligne

Aucun parcours de paiement ne part en production sans avoir été joué en environnement de test. Nous rejouons vos cas réels avec des cartes de test : un paiement accepté, un paiement refusé, une vérification 3-D Secure abandonnée, un remboursement partiel, une commande à zéro dirham. Nous vérifions à chaque fois que votre logiciel a bien reçu le bon statut.

Cet environnement de test porte un nom que votre développeur connaît : le sandbox. Il fonctionne avec ses propres clés API, séparées de celles de la production, ce qui garantit qu’aucun essai ne touche à vos vrais encaissements.

Vos équipes participent à cette phase, sur les scénarios qu’elles connaissent mieux que nous. Une comptable qui valide ses exports avant la mise en ligne évite des semaines de corrections après. Le passage en production se fait ensuite sur une période courte et surveillée, avec un premier paiement réel que nous suivons ensemble.

Réconciliation et suivi des encaissements

Chaque transaction est enregistrée avec son montant, sa date, son statut, son canal et la référence de votre côté : numéro de facture, de commande ou de dossier. C’est cette référence qui rend le rapprochement possible. Sans elle, un virement groupé sur votre relevé reste une somme qu’il faut redécouper à la main.

Vous suivez vos encaissements depuis votre espace Encaissez et vous exportez ce dont votre comptabilité a besoin. Les fonds, eux, sont conservés et virés par un établissement de paiement agréé vers votre compte bancaire. Encaissez construit et maintient la connexion, sans jamais détenir votre argent.

Si votre plateforme fait encaisser plusieurs vendeurs ou prestataires, la répartition devient un sujet à part entière. Nous le traitons sur la page consacrée à la création d’une marketplace au Maroc avec paiement en ligne.

Le compte commerçant et le TPE virtuel

Pour accepter la carte, il ne suffit pas d’un bout de code. Il vous faut un compte commerçant en ligne, ouvert auprès d’un établissement de paiement agréé. C’est ce compte qui autorise votre activité à encaisser par carte et qui définit vers quel RIB les fonds partent.

Le TPE virtuel en est le prolongement : l’équivalent, sur internet, du terminal posé sur le comptoir d’un magasin. Il porte vos identifiants de commerçant, et c’est lui que nous relions à votre logiciel. Une même entreprise peut en utiliser plusieurs, par exemple un par enseigne ou par filiale, pour garder des encaissements séparés.

Les pièces demandées et les conditions varient selon votre statut, votre activité et le prestataire retenu. Nous ne vous donnons pas une liste approximative : nous vous transmettons celle qui s’applique à votre dossier et nous le montons avec vous, parce que c’est presque toujours cette étape, et non le développement, qui décide de la date de votre premier encaissement.