Payment aggregator in Morocco: collecting on behalf of others, pooled accounts and law 103-12
Payment aggregator in Morocco: the pooled-account trap, what articles 16, 17 and 18 of law 103-12 say, and a structure to review with your advisor.
Acting as a payment aggregator in Morocco — receiving money that customers pay to other merchants, then passing it on to them — is not just an organizational question: law 103-12 lists among payment services the execution of remote payment operations where the operator acts solely as an intermediary between the payer and the supplier, and its article 18 prohibits anyone not licensed as a credit institution or payment institution from carrying out these operations as a regular business, subject to the exceptions it lists. This guide quotes the text without interpreting it and does not constitute legal advice: only your advisor can give an opinion on your case.
Collecting on behalf of others through a pooled account: the problem
A platform, an aggregator or a network head that collects for others often starts with what looks like the simplest option: every payment lands in its own account, and it then pays each merchant what they are owed. Even before the legal question, this setup creates three practical difficulties.
- Several merchants' money is mixed together. On the statement, everything shows as received by the platform: you have to untangle afterwards what belongs to whom, order by order.
- Your revenue and other people's money blur. In your books, separating what is yours from what you must pass on becomes a permanent reconciliation job.
- Every payout and every refund is a manual operation. One calculation error, one refund charged to the wrong merchant, and you carry the gap.
The ChariPay distribution model starts from the opposite principle: nothing is pooled into a common pot, and each merchant's money is identified the moment it is collected. For how a platform selling on behalf of sellers is organized commercially, see marketplace payments; here, we stay with the framework.
You can already watch a payment land in a payment account, with no real money involved: Start in test mode. Three fields — name, work email, company — an activation link received by email to choose your password, then the portal, where you create your own test key. It is free, with no time limit and no approval to wait for: your business verification (KYB) only gates the move to production.
What law 103-12 lists as payment services
Article 16 of law 103-12 on credit institutions and similar bodies lists payment services. We quote the text without interpreting it or drawing any promise from it; the quotations below are our translation of the French text. Under its point 1, the following are considered payment services:
- "fund transfer operations";
- "cash deposits and withdrawals on a payment account";
- "the execution of payment operations by any means of remote communication, provided that the operator acts solely as an intermediary between the payer and the supplier of goods and services";
- "the execution of standing or one-off direct debits, of card payment operations and the execution of transfers, when these involve funds placed in a payment account".
The same article defines a payment account as "any account held in the name of a payment services user and used exclusively for payment operations."
For a platform that collects for others, the third line is the one that deserves attention: it covers the intermediary that executes, remotely, payments between a payer and a supplier. Whether your business falls under that line, and to what extent, is not something this guide can decide. The general definition of a payment institution, its license and what it does not do are covered in payment institution in Morocco.
Article 18: services reserved for licensed institutions
Article 18 of law 103-12 sets out the prohibition: "any person not licensed as a credit institution or as a payment institution is prohibited from carrying out, as a regular business, the operations referred to in articles 1 and 16 above" (our translation). The article 16 operations are those in the list above.
The same article then provides for exceptions, in the form of a list of operations that anyone may carry out. We do not go through them: whether one of them applies to your business is for your advisor to say, and only your advisor can give an opinion.
What you can do without an advisor, on the other hand, is check your payment provider's license. The PSP in Morocco page explains how: a serious provider tells you who holds the license, and the official publication prevails. Do not settle for a "licensed" mention on a website: look for the institution that holds it.
Article 17: identified, segregated funds
Article 17 of law 103-12 deals with funds recorded in payment accounts. They must be "deposited in a global, separate and individualized account with a credit institution authorized to receive sight deposits," and "distinctly identified and ring-fenced in the accounts of payment institutions" (our translation). The balance of that global account cannot be subject to any garnishment by the payment institution's creditors.
We quote these provisions without drawing any conclusion about your situation or any promise from them. How they read for the money in a payment account is covered in how payment account funds are safeguarded.
An alternative structure: a licensed institution, one wallet per sub-merchant
ChariPay is a Moroccan payment platform, a PSP operated by Chari Money, a payment institution licensed by Bank Al-Maghrib. The license is held by Chari Money, the payment institution that operates ChariPay, licensed by Bank Al-Maghrib under law 103-12. ChariPay is not a bank: your payment account is held by Chari Money. It complements your bank; it does not replace it.
Its distribution space is for aggregators, franchises and agent networks. Each merchant you collect for is declared there as a sub-merchant, with its own wallet; a sub-merchant is verified like any merchant — documents and trade register — before collecting in production; collections follow the allocation defined when the partnership is set up, and nothing is pooled into a common pot.
| Criterion | Platform's pooled account | One wallet per sub-merchant |
|---|---|---|
| Where the money lands | In the platform's account, for every merchant | In each sub-merchant's own wallet |
| Identification | After the fact, by reconciliation | From the transaction onward |
| Merchant verification | Under your own procedures | Like any merchant, documents and trade register, before collecting in production |
| Allocation | Calculated by you, period by period | Defined when the partnership is set up |
| Pooling | All the money in one pot | Nothing is pooled into a common pot |
| Payouts | Operations you issue by hand | Under dual approval: requester and approver always distinct |
This table compares two ways of organizing; it does not say that one is compliant and the other is not. That is a question to put to your advisor, with the details of your business. The offer is described on the distribution and sub-merchants page.
Questions about your setup to ask your advisor
Before you choose a setup, have your project reviewed. Here are the questions we suggest you put to your advisor, without answering them in their place:
- 1Does my business consist of executing payment operations within the meaning of article 16 of law 103-12, in particular as an intermediary between a payer and a supplier?
- 2Does one of the operations that article 18 allows anyone to carry out apply to my business?
- 3In my current setup, who holds the funds paid by my merchants' customers between collection and payout?
- 4What changes for my platform if each merchant has its own wallet, on a platform operated by a licensed payment institution?
- 5What contracts are needed between my platform, my merchants and the payment provider?
- 6Which records should I keep to establish who was paid, for what and when?
Only your advisor can give an opinion. Bring them the texts quoted here — articles 16, 17 and 18 of law 103-12 — and a diagram of your flows: who pays, into which account, who passes the money on, and to whom.
Putting it in place
If you choose the one-wallet-per-sub-merchant structure, the setup is prepared with the integration team. Each merchant is declared as a sub-merchant, one by one or in bulk, and verified before collecting in production; we publish no timeline for this verification. The allocation of collections, the balance caps, the frequency of automatic collection — daily or weekly — and the payout approvers are set at that stage.
On the technical side, the published mechanism is the checkout session created by your server, whose config.settlement parameter names the sub-merchant wallet to credit; your system then follows each sub-merchant's lifecycle through signed webhooks. The details are in sub-merchants through the API.
Frequently asked questions
Does a payment aggregator need a license in Morocco?
We do not answer in your advisor's place. What the text says: article 18 of law 103-12 prohibits anyone not licensed as a credit institution or payment institution from carrying out, as a regular business, the operations in article 16, which include executing remote payments where the operator acts solely as an intermediary between the payer and the supplier. The same article provides for exceptions. Have your business assessed.
Can a platform collect into its own account and then pay its sellers?
That is precisely the question to ask your advisor, in light of articles 16 and 18 of law 103-12: we do not assess any particular setup. In practical terms, a pooled account forces you to untangle afterwards what belongs to whom. The alternative described here: each seller declared as a sub-merchant, with its own wallet, and nothing pooled into a common pot.
What does article 16 of law 103-12 say about remote payments?
It lists among payment services "the execution of payment operations by any means of remote communication, provided that the operator acts solely as an intermediary between the payer and the supplier of goods and services" (our translation). The same list includes, among others, fund transfers and card payments involving funds placed in a payment account. We quote the text without interpreting it.
How can each merchant's money be kept separate from the moment it is collected?
By declaring each merchant as a sub-merchant with its own wallet: each checkout session names, through the config.settlement parameter, the wallet to credit. Collections are identified from the transaction onward and follow the allocation defined when the partnership is set up; nothing is pooled into a common pot. A monthly statement is also produced for each sub-merchant, limited to its own activity.
Is ChariPay licensed to collect on behalf of others?
The license is held by Chari Money, the payment institution that operates ChariPay, licensed by Bank Al-Maghrib under law 103-12. ChariPay is the platform, a PSP operated by Chari Money. To check any provider's license, the official publication prevails; and on your own setup, only your advisor can give an opinion.
Does this apply to an agent network or a franchise?
We do not assess any particular model: the answer depends on what the network actually does, and only your advisor can give an opinion. The text to put to them: articles 16 and 18 of law 103-12. On the operational side, the distribution space is for aggregators, franchises and agent networks, with one wallet per sub-merchant and nothing pooled.
Next step
First, put the questions above to your advisor, with the texts in hand. To see right away what a collection into a payment account looks like, with no real money involved: Start in test mode. Then prepare the setup with the integration team, starting from the distribution and sub-merchants page.
Sources
Written by ChariPay team.