Payment portal user roles: owner, manager, cashier and accountant

Payment portal user roles at ChariPay separate viewing from acting. The portal ships with four profiles — owner, manager, cashier, accountant — and the owner can create custom permission profiles. The accountant reads everything without triggering anything, the cashier collects without seeing the balance or transfers, and the owner or an authorized manager triggers outgoing operations. This guide details who can view, collect, refund, send transfers, pay out or create an API key, offers three typical setups — a shop with cashiers, an outside accountant, a finance team with several approvers — and explains what to do when a team member joins or leaves.

Payment portal user roles, one sentence each

ChariPay is a Moroccan payment platform, a PSP operated by Chari Money, a payment institution licensed by Bank Al-Maghrib. Its merchant portal — available in French and English — brings together your collections, your payment account and your outgoing operations. Not everyone in the business needs to do everything there: portal roles separate viewing from acting.

• Owner: does everything, including managing the team and creating API keys.
• Manager: handles everything that touches money — links, subscriptions, refunds, transfers, bill payments, exports — but manages neither the team nor developer mode (API keys, webhooks).
• Cashier: creates payment links and sees only their own links and their own transactions: no balance, no transfer, no refund, no export.
• Accountant: reads everything — transactions, links, refunds, transfers, balance — and exports, without triggering anything.

These four profiles come ready-made; when a position matches none of them, the owner can create a custom permission profile. None of the four profiles provided is a "developer" role. And adding colleagues does not change the bill: "users and roles" is part of what is included at no extra cost, as the pricing page explains.

The matrix: view, collect, refund, transfer, pay out, create a key

The table crosses the four profiles provided with the actions that matter. An on-demand payout to your bank is a transfer: it follows the "Send transfers" row. A custom profile, for its part, carries the rights the owner has given it.

Two patterns stand out. The cashier column is built for collecting: the cashier creates payment links and sees only their own links and transactions, with no balance, transfer, refund or export. The accountant column is built for viewing and exporting: the accountant triggers no operation. Outgoing operations — refunds, transfers, payouts — stay in the hands of the owner or an authorized manager.

The simplest way to prepare this setup is to open your own portal: Start in test mode. Three fields — name, work email, company — then an activation link received by email to choose your password, then the portal, where you create your own test key after re-authenticating; the full key is shown only once. One payment with the test card 4918 9141 0719 5005 (CVV 123, any future expiry date, 3-D Secure code 555) is enough to see a collection in the portal and in the export, with no real money. Your business verification (KYB) runs in parallel and only gates the move to production. Meanwhile, write down on paper who on your team will get which role.

A shop with cashiers: collecting without exposing the balance

Take a home-decor shop in Marrakech with two salespeople at the counter and online sales. The salespeople collect payments all day long; they have no reason to know the account balance or to see supplier transfers go out.

The cashier role is made for them: they collect without seeing the balance or transfers. Each of them creates their own payment links and sees only their own links and their own transactions. The owner or an authorized manager keeps control of everything that moves money out: refunds, transfers, payouts to the bank.

The practical procedure that follows:

1. 1A customer asks for a refund at the counter: the salesperson writes down the request — date, amount, customer name, reason — and passes it on.
2. 2The owner or the authorized manager issues the refund from the portal, in full or partially. Refunds are free; the amount is deducted from your available balance.
3. 3The salesperson lets the customer know that a refund is not instantaneous on the bank side.

This split also protects your staff: none of them can be suspected of a movement they had no power to trigger.

Giving your accountant access without handing over outgoing payments

It is a question that comes up often: how do you give your accountant access without opening the door to the account? The accountant role answers it exactly: it reads everything, without triggering anything. Whether your accountant is an employee or works for an outside firm, they see your transactions, links, refunds, transfers and balance, and export what they need themselves; they cannot launch any operation.

What this changes for them:

• They work from the original data, rather than from screenshots or statements sent over a messaging app.
• They find every movement by its reference: every account movement carries the reference of the sale, refund or payout that explains it, and the portal separates amount paid, fees and net.
• They export what they need themselves at every closing, without asking you to resend everything.

And what it changes for you: no operation can go out under their name by mistake. On the confidentiality side, the export of personal data is strictly controlled. To set up the entries, references and accounts with them before the first payment, rely on the accounting checklist for collections.

A finance team with several people: managers and approvers

In a more structured business — a distributor with a CFO, a treasurer and an accounting assistant — the question is no longer only "who sees what" but "who releases what."

Three mechanisms combine with the roles:

• The one-time code on transfers. Every transfer sent from the portal is validated by a six-digit one-time code, emailed to each validation address designated in Settings → Security — up to five addresses, each belonging to a team member authorized to make transfers; you set the number of approvers required. Until an address is configured, no transfer can be sent.
• Dual approval of sensitive actions. Sensitive actions — payouts, adjustments, account freezes — require a distinct requester and approver.
• The chained audit log. The audit log is cryptographically chained: history cannot be rewritten.

A typical setup: the CFO is the owner; the treasurer is a manager and prepares transfers; the validation addresses belong to the CFO and the treasurer, and two approvers are required; the accounting assistant has the accountant role. A transfer prepared by the treasurer therefore no longer rests on the treasurer alone. The full flow of a transfer — beneficiary, fee quote, codes, statuses — is described in the guide to transfers from your payment account.

The API key: who creates it, and how

Technical integration often raises the question of a "developer" role. None of the four profiles provided is one: the API key is created from the portal by the owner, or by a user whose custom permission profile grants that right, and it is the key — not a user account — that opens the API.

The key rules are precise. One key per company and per environment, with per-module permissions (scopes); you create it yourself from the portal, after re-authenticating; the full key is shown only once and is never sent by email; two keys can coexist during a rotation, without downtime. A key is a secret: never in the browser, a mobile app, a git repository or a screenshot.

In practice, the owner creates the key and places it directly where the server will read it — a secrets manager, environment variables — without passing it through email or a messaging app. The developer works with the test key until the integration is ready, then with the production key once it is enabled. Storage and rotation best practices are covered in the guide to protecting your API keys.

When a team member joins or leaves

Roles only work if they follow the life of the team. Two moments matter.

When someone joins:

1. 1Assign the minimum useful role: cashier to collect, accountant to view and export, manager only if the person needs to trigger outgoing operations — or a custom profile, created by the owner, if none of the four fits.
2. 2Add their address to the validation addresses for transfers, in Settings → Security, if they need to approve transfers, and only in that case.
3. 3Restate the access rules: a personal login, never shared, and two-factor authentication (TOTP), which is turned on from their account settings.

When someone leaves:

1. 1Remove access the same day, without waiting for the end of the notice period if the person triggered outgoing payments.
2. 2Remove their address from the validation addresses for transfers, in Settings → Security.
3. 3Rotate the API key if they ever had access to it: two keys can coexist during a rotation, without downtime.

For the full list of access controls — two-factor authentication, re-authentication, regular reviews — see the guide to securing portal access.

What roles do not replace

Roles say who does what; they do not say how access is protected. Portal access is protected by two-factor authentication (TOTP), re-authentication before every sensitive action and secured sessions. Two-factor authentication is turned on from your account settings; once enabled, it is requested at sign-in, and the portal can also require it from users authorized for sensitive operations — refunds, transfers, beneficiary management. A well-chosen role on a poorly protected login is worth nothing: that is the subject of the guide to securing portal access.

Roles do not replace your internal organization either: a written delegation, an access review whenever the team changes, a clear rule on who can promise a customer a refund. The portal applies what you decide; it does not decide for you. For the account itself — what it is, who holds it, what it allows — read the guide to the payment account in Morocco.

Frequently asked questions

How many roles are there in the ChariPay portal?

The portal ships with four profiles — owner, manager, cashier and accountant — and the owner can create custom permission profiles. The profiles separate viewing from acting: the accountant reads everything without triggering anything, the cashier collects without seeing the balance or transfers, and the owner or an authorized manager triggers outgoing operations. None of the profiles provided is a "developer" role.

How do I give my accountant access without letting them send transfers?

Give them the accountant role. They read everything — transactions, links, refunds, transfers, balance — and export, without being able to trigger anything: no transfer, refund or payout can go out under their name. Whether your accountant is an employee or works for an outside firm, they then work from the original data rather than from screenshots.

Can a cashier see the account balance?

No. The cashier collects without seeing the balance or transfers: they create payment links and see only their own links and their own transactions. This role is designed for the people who take customer payments day to day — at the counter, in the shop, over the phone — and who have no need to know the company's cash position.

Can a cashier refund a customer?

No. The cashier only collects: no balance, no transfers, no refunds. Refunds stay with the owner or an authorized manager from the portal, or with your integration through the API, in full or partially. The simple procedure: the cashier writes down the request — date, amount, customer, reason — passes it on, and tells the customer that a refund is not instantaneous on the bank side.

Who can send money out of the payment account?

The owner or an authorized manager: they are the ones who trigger outgoing operations, including transfers and on-demand payouts. Every transfer sent from the portal is also validated by a one-time code emailed to the validation addresses designated in Settings → Security, and you set the number of approvers required. The cashier and the accountant cannot move any money out of the account.

Are additional users billed?

No: "users and roles" is part of what is included at no extra cost, just like the payment account with its RIB and certificate, the full merchant portal or signed webhooks. So you can give everyone the role that fits them rather than sharing a single login. The Pricing page lists everything that is included.

Is there a developer role for the integration?

No: none of the four profiles provided is a "developer" role. Integration goes through an API key, created from the portal by the owner, or by a user whose custom profile grants that right, after re-authenticating. The full key is shown only once and is never sent by email: whoever creates it places it in the server's secrets. The developer starts in test mode, which is free and has no time limit.

Who can create an API key?

The owner, from the portal, after re-authenticating, or a user whose custom permission profile grants that right; the manager, cashier and accountant profiles do not create keys. There is one key per company and per environment, with per-module permissions, and the full key is shown only once. Two keys can coexist during a rotation, without downtime.

Next step

Start in test mode to get your own portal, free and with no time limit. Then write down the list of your team members with, for each, the target role and, where relevant, their approver status. Finally, read the guide to securing portal access before opening access in production.