Rôles utilisateurs du portail de paiement : propriétaire, gestionnaire, caissier, comptable

Les rôles utilisateurs du portail de paiement ChariPay séparent la consultation de l'action. Le portail fournit quatre profils — propriétaire, gestionnaire, caissier, comptable — et le propriétaire peut créer des profils de permissions personnalisés. 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. Ce guide détaille qui peut voir, encaisser, rembourser, virer, verser ou créer une clé d'API, propose trois organisations types — boutique avec caissiers, comptable externe, finance à plusieurs —, et dit quoi faire quand un collaborateur arrive ou s'en va.

Les rôles utilisateurs du portail de paiement, en une phrase chacun

ChariPay est une plateforme de paiement marocaine, un PSP opéré par Chari Money, établissement de paiement agréé par Bank Al-Maghrib. Son portail marchand — disponible en français et en anglais — réunit vos encaissements, votre compte de paiement et vos opérations sortantes. Tout le monde dans l'entreprise n'a pas à tout y faire : les rôles du portail séparent la consultation de l'action.

• Propriétaire : il fait tout, y compris gérer l'équipe et créer les clés d'API.
• Gestionnaire : il fait tout ce qui touche à l'argent — liens, abonnements, remboursements, virements, paiement de factures, exports —, mais ne gère ni l'équipe ni le mode développeur (clés d'API, webhooks).
• Caissier : il crée des liens de paiement et ne voit que ses propres liens et ses propres transactions : ni solde, ni virement, ni remboursement, ni export.
• Comptable : il lit tout — transactions, liens, remboursements, virements, solde — et exporte, sans rien déclencher.

Ces quatre profils sont fournis par le portail ; quand un poste ne correspond à aucun d'eux, le propriétaire peut créer un profil de permissions personnalisé. Aucun des quatre profils fournis n'est un rôle « développeur ». Et ajouter des collègues ne change pas la facture : « utilisateurs et rôles » figure dans ce qui est inclus sans supplément, comme le détaille la page tarification.

La matrice : voir, encaisser, rembourser, virer, verser, créer une clé

Le tableau croise les quatre profils fournis et les gestes qui comptent. Le versement à la demande vers votre banque est un virement : il suit la ligne « Virer ». Un profil personnalisé, lui, porte les droits que le propriétaire lui a attribués.

Deux lignes de force se lisent dans ce tableau. La colonne du caissier est faite pour encaisser : il crée ses liens de paiement et ne voit que les siens et ses propres transactions, sans solde, ni virement, ni remboursement, ni export. La colonne du comptable est faite pour voir et exporter : il ne déclenche aucune opération. Les opérations sortantes — rembourser, virer, verser — restent entre les mains du propriétaire ou d'un gestionnaire habilité.

Pour préparer cette organisation, le plus simple est d'ouvrir votre propre portail : 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 vous-même votre clé de test après une ré-authentification ; la clé complète ne s'affiche qu'une seule fois. Un paiement avec la carte de test 4918 9141 0719 5005 (CVV 123, n'importe quelle date d'expiration future, code 3-D Secure 555) suffit pour voir un encaissement dans le portail et dans l'export, sans argent réel. La vérification de votre entreprise (KYB) se fait en parallèle et ne conditionne que le passage en production. Pendant ce temps, écrivez sur papier qui, dans votre équipe, aura quel rôle.

Boutique avec caissiers : encaisser sans exposer le solde

Prenez une boutique de décoration à Marrakech, avec deux vendeurs au comptoir et des ventes en ligne. Les vendeurs encaissent tout au long de la journée ; ils n'ont aucune raison de connaître le solde du compte ni de voir partir les virements fournisseurs.

Le rôle de caissier est fait pour eux : ils encaissent sans voir le solde ni les virements. Chacun crée ses liens de paiement et ne voit que ses propres liens et ses propres transactions. Le propriétaire ou un gestionnaire habilité garde la main sur ce qui fait sortir de l'argent : remboursements, virements, versements vers la banque.

La procédure pratique qui en découle :

1. 1Un client demande un remboursement au comptoir : le vendeur note la demande — date, montant, nom du client, motif — et la transmet.
2. 2Le propriétaire ou le gestionnaire habilité rembourse depuis le portail, en totalité ou partiellement. Le remboursement est gratuit ; son montant est déduit de votre solde disponible.
3. 3Le vendeur informe le client qu'un remboursement n'est pas instantané côté banque.

Ce découpage protège aussi vos vendeurs : aucun d'eux ne peut être soupçonné d'un mouvement qu'il n'avait pas le pouvoir de déclencher.

Donner accès à son comptable sans lui confier les sorties

C'est une question qui revient souvent : comment donner accès à son comptable sans lui ouvrir la porte du compte ? Le rôle de comptable y répond exactement : il lit tout, sans rien déclencher. Qu'il soit salarié de l'entreprise ou membre d'un cabinet externe, il consulte vos transactions, vos liens, vos remboursements, vos virements et votre solde, et il exporte lui-même ; il ne peut lancer aucune opération.

Ce que cela change pour lui :

• Il travaille sur les données d'origine, plutôt que sur des captures d'écran ou des relevés transmis par messagerie.
• Il retrouve chaque mouvement par sa référence : chaque mouvement du compte porte la référence de la vente, du remboursement ou du versement qui l'explique, et le portail distingue montant payé, frais et net.
• Il exporte lui-même ce dont il a besoin à chaque clôture, sans vous demander de tout lui renvoyer.

Et ce que cela change pour vous : aucune opération ne part sous son nom par erreur. Sur le plan de la confidentialité, l'export de données personnelles est strictement contrôlé. Pour organiser avec lui les écritures, les références et les comptes avant le premier paiement, appuyez-vous sur la checklist comptable de l'encaissement.

Finance à plusieurs : gestionnaires et approbateurs

Dans une entreprise plus structurée — un distributeur avec un directeur financier, un trésorier et une assistante comptable —, la question n'est plus seulement « qui voit quoi » mais « qui libère quoi ».

Trois mécanismes se combinent avec les rôles :

• Le code à usage unique sur les virements. 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é — jusqu'à cinq adresses, chacune celle d'un membre de l'équipe habilité aux virements — ; vous fixez le nombre d'approbateurs requis. Tant qu'aucune adresse n'est configurée, aucun virement ne peut partir.
• La double validation des actions sensibles. Les actions sensibles — reversements, ajustements, gels de compte — exigent un demandeur et un approbateur distincts.
• Le journal d'audit chaîné. Le journal d'audit est chaîné cryptographiquement : l'historique ne peut pas être réécrit.

Une organisation type : le directeur financier est propriétaire ; le trésorier est gestionnaire et prépare les virements ; les adresses de validation sont celles du directeur financier et du trésorier, et deux approbateurs sont requis ; l'assistante comptable a le rôle de comptable. Le virement préparé par le trésorier ne repose ainsi plus sur lui seul. Le parcours complet d'un virement — bénéficiaire, devis des frais, codes, statuts — est décrit dans le guide du virement depuis son compte de paiement.

La clé d'API : qui la crée, et comment

L'intégration technique pose souvent la question d'un rôle « développeur ». Aucun des quatre profils fournis n'en est un : la clé d'API se crée depuis le portail par le propriétaire, ou par un utilisateur dont le profil de permissions personnalisé en donne le droit, et c'est elle — pas un compte utilisateur — qui ouvre l'API.

Les règles de la clé sont précises. Une clé par entreprise et par environnement, avec des permissions (scopes) par module ; vous la créez vous-même depuis le portail, après une ré-authentification ; la clé complète ne s'affiche qu'une seule fois et n'est jamais envoyée par e-mail ; deux clés peuvent coexister le temps d'une rotation, sans coupure. Une clé est un secret : jamais dans le navigateur, une application mobile, un dépôt git ou une capture d'écran.

En pratique, le propriétaire crée la clé et la dépose directement là où le serveur la lira — gestionnaire de secrets, variables d'environnement —, sans la faire transiter par un e-mail ou une messagerie. Le développeur travaille avec la clé de test tant que l'intégration n'est pas prête, puis avec la clé de production une fois celle-ci activée. Les bonnes pratiques de conservation et de rotation sont dans le guide pour protéger ses clés d'API.

Arrivée et départ d'un collaborateur

Les rôles ne valent que s'ils suivent la vie de l'équipe. Deux moments comptent.

À l'arrivée :

1. 1Attribuez le rôle minimal utile : caissier pour encaisser, comptable pour consulter et exporter, gestionnaire seulement si la personne doit déclencher des opérations sortantes — ou un profil personnalisé, créé par le propriétaire, si aucun des quatre ne convient.
2. 2Ajoutez son adresse aux adresses de validation des virements, dans Paramètres → Sécurité, si elle doit valider des virements, et seulement dans ce cas.
3. 3Rappelez les règles d'accès : un accès personnel, jamais partagé, et la double authentification (TOTP), qui s'active depuis les paramètres de son compte.

Au départ :

1. 1Retirez l'accès le jour même, sans attendre la fin du préavis si la personne déclenchait des sorties.
2. 2Retirez son adresse des adresses de validation des virements, dans Paramètres → Sécurité.
3. 3Faites tourner la clé d'API si elle y avait eu accès : deux clés peuvent coexister le temps d'une rotation, sans coupure.

Pour la liste complète des contrôles d'accès — double authentification, ré-authentification, revue régulière —, voyez le guide pour sécuriser l'accès au portail.

Ce que les rôles ne remplacent pas

Les rôles disent qui fait quoi ; ils ne disent pas comment l'accès est protégé. L'accès au portail est protégé par la double authentification (TOTP), la ré-authentification avant chaque action sensible et des sessions sécurisées. La double authentification s'active depuis les paramètres de votre compte ; une fois activée, elle est demandée à la connexion, et le portail peut aussi l'exiger des utilisateurs habilités aux opérations sensibles — remboursements, virements, gestion des bénéficiaires. Un rôle bien choisi sur un compte mal protégé ne sert à rien : c'est l'objet du guide pour sécuriser l'accès au portail.

Les rôles ne remplacent pas non plus votre organisation interne : une délégation écrite, une revue des accès quand l'équipe change, une règle claire sur qui peut promettre un remboursement à un client. Le portail applique ce que vous décidez ; il ne décide pas à votre place. Pour le compte lui-même — ce qu'il est, qui le tient, ce qu'il permet —, lisez le guide du compte de paiement au Maroc.

Questions fréquentes

Combien de rôles existe-t-il dans le portail ChariPay ?

Le portail fournit quatre profils — propriétaire, gestionnaire, caissier et comptable —, et le propriétaire peut créer des profils de permissions personnalisés. Les profils 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. Aucun profil fourni n'est un rôle « développeur ».

Comment donner accès à son comptable sans qu'il puisse faire de virement ?

Attribuez-lui le rôle de comptable. Il lit tout — transactions, liens, remboursements, virements, solde — et exporte, sans pouvoir rien déclencher : aucun virement, aucun remboursement, aucun versement ne peut partir sous son nom. Que le comptable soit salarié ou membre d'un cabinet externe, il travaille ainsi sur les données d'origine plutôt que sur des captures d'écran.

Un caissier peut-il voir le solde du compte ?

Non. Le caissier encaisse sans voir le solde ni les virements : il crée des liens de paiement et ne voit que ses propres liens et ses propres transactions. Ce rôle est conçu pour les personnes qui reçoivent les paiements des clients au quotidien — au comptoir, en boutique, au téléphone — et qui n'ont pas besoin de connaître la trésorerie de l'entreprise.

Un caissier peut-il rembourser un client ?

Non. Le caissier encaisse uniquement : ni solde, ni virement, ni remboursement. Le remboursement reste au propriétaire ou à un gestionnaire habilité depuis le portail, ou à votre intégration par l'API, en totalité ou partiellement. La procédure simple : le caissier note la demande — date, montant, client, motif —, la transmet, et informe le client qu'un remboursement n'est pas instantané côté banque.

Qui peut envoyer de l'argent depuis le compte de paiement ?

Le propriétaire ou un gestionnaire habilité : ce sont eux qui déclenchent les opérations sortantes, virements et versements à la demande compris. Chaque virement émis depuis le portail est en outre validé par un code à usage unique envoyé par e-mail aux adresses de validation désignées dans Paramètres → Sécurité, et vous fixez le nombre d'approbateurs requis. Le caissier et le comptable ne peuvent faire sortir aucun argent du compte.

Les utilisateurs supplémentaires sont-ils facturés ?

Non : « utilisateurs et rôles » fait partie de ce qui est inclus sans supplément, au même titre que le compte de paiement avec RIB et attestation, le portail marchand complet ou les webhooks signés. Vous pouvez donc donner à chacun le rôle qui lui correspond plutôt que de partager un accès unique. La page Tarification détaille l'ensemble de ce qui est inclus.

Existe-t-il un rôle développeur pour l'intégration ?

Non : aucun des quatre profils fournis n'est un rôle « développeur ». L'intégration passe par une clé d'API, créée depuis le portail par le propriétaire, ou par un utilisateur dont le profil personnalisé en donne le droit, après une ré-authentification. La clé complète ne s'affiche qu'une seule fois et n'est jamais envoyée par e-mail : celui qui la crée la dépose dans les secrets du serveur. Le développeur commence en mode test, gratuit et sans limite de durée.

Qui peut créer une clé d'API ?

Le propriétaire, depuis le portail, après une ré-authentification, ou un utilisateur dont le profil de permissions personnalisé en donne le droit ; les profils gestionnaire, caissier et comptable n'en créent pas. Il existe une clé par entreprise et par environnement, avec des permissions par module, et la clé complète ne s'affiche qu'une seule fois. Deux clés peuvent coexister le temps d'une rotation, sans coupure.

Prochaine étape

Commencer en mode test vous donne votre propre portail, gratuit et sans limite de durée. Écrivez ensuite la liste de vos collaborateurs avec, pour chacun, le rôle cible et, le cas échéant, son statut d'approbateur. Puis lisez le guide pour sécuriser l'accès au portail avant d'ouvrir les accès en production.