Franchise payments in Morocco: every store collects, the network head oversees

To organize franchise payments in Morocco, declare each store as a sub-merchant: it is verified like any merchant, gets its own wallet, and the network head sees the whole network. Automatic collection feeds the network head's collection account, daily or weekly, and a monthly statement is produced for every store. This guide shows how stores collect at the counter and remotely, who sees what, what balance caps are for, how collection works, how to reconcile the network's flows, and what to prepare for a multi-brand group.

One network, stores that each collect their own payments

ChariPay is a Moroccan payment platform, a PSP operated by Chari Money, a payment institution licensed by Bank Al-Maghrib. Its distribution space is for aggregators, franchises and agent networks. For a store network, the logic is straightforward: the network head is the partner, and each store becomes a sub-merchant in its distribution space.

In practice:

• stores are created one by one or in bulk, each with its own wallet;
• each one 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.

That last point changes daily life for a franchise. When every sale across the network lands in a single account, someone then has to rebuild, store by store, what was sold and what each one is owed. Here, each store has its own wallet: the franchisee in Marrakech and the one in Tangier each have theirs. The full offer is described on the distribution and sub-merchants page.

If your network also sells online, on a site that brings several sellers together, the model is similar but organized differently: see marketplace payments.

Collecting across a store network: counter QR codes and links

In a store, card payment without a terminal goes through the payment link. A payment link is an amount and a description; the customer pays on a page hosted by ChariPay. It is shared as a link, a QR code, a printable PDF poster, by email or WhatsApp. It is single-use or reusable, with an expiry of your choice and a clear status: active, paid, canceled, expired. From the portal, every payment link you create is single-use. The reusable link — one amount paid by several customers — is created through the API, with singleUse: false; once created, it shows up in the portal like the others.

Depending on the customer's situation, the tool is not the same:

Keep in mind the rule that prevents most misunderstandings: a reusable link — and therefore the permanent poster or counter QR code that carries it — collects by card only. Cash always goes through a single-use link: on that link's page, your customer chooses cash, receives a reference, pays it at an agency of the Chari network, and you are notified as soon as the network confirms the deposit — one reference per deposit. How the QR code and the poster work is covered in QR code payments.

One point remains to settle at setup: how a store's link or poster is attached to that store's wallet is not publicly documented. The only published mechanism is a checkout session created through the API, whose config.settlement parameter names the sub-merchant wallet to credit. For your counter tools, the question is handled with the integration team.

You can already see what your customers will see in store: Start in test mode. Three fields — name, work email, company — an activation link received by email to choose your password, then the portal. There you create a single-use link, show its QR code from the list of links, open its PDF poster from the link's page and pay it 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. The distribution space itself is prepared with the integration team.

The network head oversees, each store stays accountable for its own flows

The partner sees its whole network: volumes, statuses, incidents. For each sub-merchant, in turn, a monthly statement is produced, covering only its own activity.

On the network head's side, portal roles separate viewing from acting: owner, manager, cashier, accountant. The accountant reads everything without triggering anything, the cashier collects without seeing the balance or transfers, the owner or an authorized manager triggers outgoing operations. For a network's management, this is how you give the finance controller access without handing over control of the money. The profiles are detailed in portal roles and access.

Balance caps per store

The distribution space includes balance caps, set wallet by wallet. In a network, the benefit is concrete. Between two collections, money builds up in each store's wallet; each store's cap serves as a marker, and the alert that comes with it saves you from finding out afterwards that one very busy store is carrying a balance out of line with the others.

A cap is not designed on its own: it goes hand in hand with the collection frequency. A store that sells a lot between two collections will approach its cap faster than a quieter one. We publish neither cap amounts, nor the rule that triggers the alert, nor what happens once a cap is reached; the cap is discussed at setup. When a sub-merchant approaches its cap, the submerchant.near_cap event alerts you through a signed webhook: your system can warn the store manager or the finance team without waiting for month-end.

Collection to the network head's account

Automatic collection goes to your collection account, daily or weekly. For a network head, this is what turns a patchwork of tills into central cash management, with no daily task. The choice between the two frequencies depends on how you operate: daily collection keeps wallets light and your cash position current; weekly collection leaves funds at store level for longer.

Payouts, for their part, require dual approval: the requester and the approver are always distinct. Your system is notified by signed webhook of each payout's outcome — executed or failed. Network governance is thus built into the tool, not into a shared spreadsheet.

Running these flows in detail — frequency, caps, alerts, payouts, bulk refunds — is covered in network collection and payouts.

The monthly statement and network reconciliation

A monthly statement is produced for each sub-merchant. For the franchisee, it is the document that covers its own activity, and only its own; for the network head, it is a shared basis for discussing each store's monthly figures.

On the network head's side, reconciliation relies on the account's traceability. Every account movement carries the reference of the sale, refund or payout that explains it; the portal separates amount paid, fees and net, and the CSV export keeps those references — from the portal or with GET /v1/transactions/export.csv (up to 10,000 rows; beyond that, break it down by period with from/to). Timestamps are in UTC; Morocco is UTC+1: your reconciliation tool must convert, or sales made just after midnight will slip onto the previous day.

A simple routine for a network:

1. 1Export the period's movements every week.
2. 2Match each sale to the order or receipt that explains it, by its reference.
3. 3Check the amount paid, fees and net for the period.
4. 4File each period's export with your accounting records.

The full method is in reconciling your collections.

Multi-brand groups

A group running several brands often brings together several companies. The principle to hold on to is simple: one company, one verification, separate books. Each company is verified like any merchant — documents and trade register — before collecting in production, and none of its collections is pooled into a common pot.

The published tools support that separation. Portal roles separate viewing from acting, so an accountant reads everything without triggering anything; a monthly statement is produced for each sub-merchant, limited to its own activity; and the CSV export carries the reference of every movement. The exact shape of the setup — which group company is the partner, how each brand and each of its stores is declared — is decided with the integration team, starting from your group's legal structure chart. Bring that chart along.

Setting up the network

Stores are created one by one or in bulk, KYC is built in, and the setup is prepared with the integration team. To arrive with a workable file, gather:

• the list of stores, with the company that runs each one;
• the documents and trade register of each operating company;
• the balance caps you want for each type of store;
• the collection frequency you are aiming for, daily or weekly;
• the people at the network head who will request payouts and those who will approve them;
• the payment tools planned in store: posters and counter QR codes, links sent remotely, the network's website.

The move to production then follows the path of any merchant: once KYB is validated — identity documents and trade register, with dual human review — your application is reviewed and you receive a priced proposal. Test mode remains the first possible step, for your store teams as well as your developers.

Frequently asked questions

Does each franchisee collect into its own wallet?

Each store has its own wallet: it is declared as a sub-merchant, and nothing is pooled into a common pot. For a payment through a checkout session, the config.settlement parameter names the store wallet to credit; for links and counter QR codes, that attachment is not published and the question is handled at setup. Automatic collection, daily or weekly, then goes to the network head's collection account.

Can a store in the network collect cash?

Yes, through a single-use payment link: on the link's page, the customer chooses cash, receives a reference, pays it at an agency of the Chari network, and you are notified as soon as the network confirms the deposit. The permanent poster and the counter QR code, on the other hand, rely on a reusable link created through the API: card only. How these links attach to the store's wallet is not published: the question is handled at setup.

Can a balance cap be set for each store?

Yes: the distribution space includes balance caps, set wallet by wallet, and therefore store by store. We publish no amount: the cap is discussed at setup with the integration team, together with the collection frequency. When a store approaches its cap, the submerchant.near_cap event alerts you through a signed webhook, so you can act before month-end.

What does each franchisee receive to track its activity?

Its tracking relies on the monthly statement produced for its store, which covers only its own activity: neither the other stores' sales nor the network's. The network head, for its part, has the overall view, the breakdown of amount paid, fees and net in the portal, and the CSV export, where every movement carries its reference. The store's statement remains the shared basis for discussing the month's figures.

How do I add a new store to the network?

By declaring it as a sub-merchant, on its own or in a batch. It is then verified like any merchant — documents and trade register — before collecting in production; we publish no timeline for this verification. The wallet.activated event tells you its wallet has been activated, and wallet.rejected that it was turned down. Until then, keep it in a "pending verification" status in your tools.

Can a group with several brands keep each brand's collections separate?

Yes, and that is the principle to hold on to: one company, one verification, separate books. Each company is verified like any merchant, and none of its collections is pooled into a common pot: each sub-merchant has its own wallet, and a monthly statement is produced for each one. The shape of the setup — which company is the partner, how each brand is declared — is decided with the integration team.

Next step

Try it from the store's side: Start in test mode, create a link, print its poster and pay with the test card. Then prepare your network setup with the integration team — stores, caps, collection frequency, approvers — using the distribution and sub-merchants page as your reference, and read network collection and payouts to run the money day to day.