Dual approval payouts and two-factor login: securing access to your payment account
Dual approval payouts, two-factor login, re-authentication, transfer codes and a chained audit log: how to secure access to your ChariPay payment account.
Dual approval payouts and two-factor login work together to secure your payment account. At ChariPay, two-factor authentication, once enabled, protects the way into the portal, and the outgoing operations you trigger go through further checks: re-authentication before every sensitive action, a one-time code that validates every transfer, the number of approvers you set, a security delay after adding a new beneficiary, two codes to pay a bill, and a distinct requester and approver for payouts. The audit log is chained: history cannot be rewritten. This guide describes each layer, what it protects, and what you need to set up on your side, all the way to a team member's departure.
Why portal access is protected in layers
ChariPay is a Moroccan payment platform, a PSP operated by Chari Money, a payment institution licensed by Bank Al-Maghrib. ChariPay is not a bank: your payment account is held by Chari Money. It complements your bank; it does not replace it. But money leaves from its portal: you send transfers to any Moroccan RIB there, you pay bills with the listed billers, and, if you run a network of sub-merchants, payouts are subject to dual approval there. Poorly protected access does not just cost data: it can cost money.
No single protection is enough: a password can leak, a session can stay open, a team member can make a mistake or abuse their rights. Hence successive layers, each designed for a specific risk:
| Layer | What it protects | When it applies |
|---|---|---|
| Two-factor authentication (TOTP) | The way into the portal | At sign-in, once enabled |
| Re-authentication | Sensitive actions, including creating an API key | Before every sensitive action |
| One-time code by email, approvers | Sending a transfer | On every transfer sent from the portal |
| Security delay | Transfers to a new beneficiary | After a beneficiary is added |
| Two codes | Paying a bill | On every bill payment |
| Distinct requester and approver | Payouts, adjustments, account freezes | On every action of that kind |
| Chained audit log | The history, which cannot be rewritten | At all times |
Roles form a separate layer, which decides what each person sees and can do: portal roles separate viewing from acting (owner, manager, cashier, accountant). How to assign them is covered in portal roles and access; this guide covers the protections that come on top of them.
Two-factor login to your payment account
Two-factor authentication (TOTP) is turned on from your account settings: an authenticator app, a six-digit code, backup codes to keep safe. Once enabled, it is requested at sign-in; the portal can also require it from users authorized for sensitive operations — refunds, transfers, beneficiary management. Sessions, for their part, are secured.
TOTP (time-based one-time password) is a temporary code, computed from a secret and the current time by the authenticator app on a device you keep with you: once two-factor authentication is enabled, a stolen password is not enough on its own to get in.
This protection only works if it stays personal. Three habits make it effective:
- One person, one sign-in, two-factor authentication enabled. Share a login among colleagues, and nobody knows who did what anymore.
- The device that generates the codes stays with its owner, never on a shared desk, and the backup codes are stored separately, out of others' reach.
- Sessions get closed. On a shared computer (a counter, a front desk), sign out after use.
Re-authentication before every sensitive action
Being signed in is not enough for everything. Before every sensitive action, the portal asks you to authenticate again. A session opened in the morning and left unattended therefore cannot, on its own, trigger a sensitive operation in the afternoon.
The clearest example is the API key. You create it yourself from the portal, after re-authenticating; the full key is shown only once and is never sent by email. Re-authentication confirms that it really is you, at that very moment, creating the key; showing it only once keeps it from staying readable in the portal afterward. Copy it straight into your secrets vault.
You can try these protections right away, at no risk: Start in test mode. In test mode, the test key is already created after re-authentication and shown only once. Three fields (name, work email, company), an activation link received by email to choose your password, then the portal, where you create your test key and make a first payment with the test card, with no real money involved. It is free, with no time limit and no approval to wait for: your business verification (KYB) only gates the move to production.
Dual approval for a transfer: one-time code and approvers
A transfer calls for particular care, for a simple reason: an executed transfer cannot be canceled. The check must therefore happen before sending, never after.
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. That is the heart of dual approval: a transfer leaves only once it has been validated by the number of approvers you set. For a finance team, this setting organizes the separation of duties: designate as validation addresses those of the people in charge of approving (the owner, the finance lead) and set the number of approvers required according to your internal rules.
A second protection targets a high-risk case, the unknown RIB: a security delay applies after adding a new beneficiary. An intruder who gained access cannot add a beneficiary and transfer your balance to it right away. So that this delay never gets in the way of a due date, register your regular suppliers ahead of time.
In the sandbox, any six-digit code is accepted: your team can get used to validation before production. The step-by-step guide (beneficiaries, fee quote, statuses) is in transfers from your payment account.
Two codes to pay a bill
Paying bills with the listed billers follows the same logic of explicit confirmation. You choose the biller, enter the reference, select the unpaid bills found, then confirm with two codes; the amount is debited from your available balance. That double confirmation keeps a single click from being enough to commit your balance. The receipt is then sent by SMS. The full guide is in paying bills from your payment account.
Payouts, adjustments, account freezes: one requester, one approver
Some operations never rest on a single person. Sensitive actions (payouts, adjustments, account freezes) require a distinct requester and approver. In the portal, the owner or an authorized manager triggers outgoing operations: the accountant reads everything without triggering anything, and the cashier collects without seeing the balance or transfers.
On your side, apply the same separation to what your team triggers: decide who prepares and who approves, make sure the same person does not end up doing both in practice, and plan a backup for vacations, so that nobody is tempted to "help out" by getting around the rule. If you run a network of sub-merchants, the same dual approval applies to their payouts; how it works is described in network collection and payouts.
The chained audit log
The audit log is cryptographically chained: history cannot be rewritten. A chained log links each entry to the one before it, so changing a past entry would break the chain. An awkward entry therefore cannot be erased after the fact.
This log is part of a broader set of controls run by the platform: continuous monitoring with alerts, sensitive data masked in logs, tightly controlled export of personal data. The internal console, on Chari's side, is not accessible to merchants. Double-entry accounting (an internal ledger that is balanced at all times and reconciled daily) is covered in how payment account funds are safeguarded.
Your own trail is in the portal: every account movement carries the reference of the sale, refund or payout that explains it, and the CSV export keeps those references. That is what you will reread to check what left the account.
Team member departures and periodic access reviews
A team member's departure is when forgotten access becomes a risk. On the same day, without waiting:
- 1Remove their portal access, whatever their role.
- 2Rotate any API key they may have seen: two keys can coexist during a rotation, without downtime, which lets you replace the key without interrupting your collections. The method is in protecting your API keys.
- 3If they were a developer, rotate your webhook secret too: during the rotation, each delivery carries two signatures, the old one and the new one, while you switch over.
- 4Review the transfer validation addresses, if they had one, and appoint a replacement: with no address configured, no transfer can be sent.
- 5Reread recently added beneficiaries: an addition nobody can explain must be checked before any transfer.
Beyond departures, plan an access review at regular intervals (at each accounting close, for example): who has portal access, with which role, who approves transfers, which API keys exist, which beneficiaries are registered. The attack scenarios these controls block are described in online payment fraud, and the platform's full set of protections on the security and compliance page. These recommendations are about internal control: they are not legal advice.
Frequently asked questions
Is portal sign-in protected by two-factor authentication?
Yes, once it is enabled. Two-factor authentication (TOTP) is turned on from your account settings: an authenticator app, a six-digit code, backup codes to keep safe. Once enabled, it is requested at sign-in; the portal can also require it from users authorized for sensitive operations — refunds, transfers, beneficiary management. Each person needs their own sign-in.
Why does the portal ask me to authenticate again before some operations?
Because being signed in is not enough for a sensitive action: the portal requires re-authentication before each one. A session left open therefore cannot, on its own, trigger a sensitive operation. One example is creating an API key, whose full value is then shown only once.
Is the transfer validation code mandatory?
Yes. Every transfer sent from the portal is validated by a six-digit one-time code, emailed to each validation address designated in Settings → Security, and you set the number of approvers required. Until an address is configured, no transfer can be sent. The check comes before sending, because an executed transfer cannot be canceled. In the sandbox, any six-digit code is accepted.
Can I require several approvers for a transfer?
Yes: you set the number of approvers required. The one-time code is emailed to each validation address designated in Settings → Security — up to five addresses, each belonging to a team member authorized to make transfers. Designate those of the people in charge of approving: that is the classic split between whoever prepares and whoever validates. A security delay also applies after adding a new beneficiary.
Which operations require a distinct requester and approver?
Sensitive actions (payouts, adjustments, account freezes) require a distinct requester and approver. For transfers, each one is validated by a one-time code, and you set the number of approvers required. In the portal, the owner or an authorized manager triggers outgoing operations; the accountant reads everything without triggering anything.
Can the audit log be changed?
No. The audit log is cryptographically chained: history cannot be rewritten. Each entry is linked to the previous one: changing or erasing a past entry would break the chain. It adds to the platform's other controls, such as double-entry accounting reconciled daily and continuous monitoring with alerts.
Which keys and access should I review when a team member leaves?
Remove their portal access the same day, rotate any API key they may have seen (two keys coexist during a rotation, without downtime), rotate your webhook secret if they were a developer, review the transfer validation addresses and reread recently added beneficiaries. Record the review in your own log.
Next step
Try these protections at no risk: Start in test mode, create your test key after re-authenticating and turn on two-factor authentication from your account settings. Then decide with your team who requests and who approves, and designate your transfer validation addresses before you go live. How to assign roles is covered in portal roles and access.
Written by ChariPay team.