Marketplace payments in Morocco: collecting for your sellers, each with their own wallet

To collect marketplace payments in Morocco without mixing up your sellers' money, declare each seller as a sub-merchant: it is verified like any merchant, gets its own wallet, and every order paid on your platform becomes a checkout session that names the wallet to credit. Each seller's money is identified the moment it is collected, instead of being untangled afterwards from a shared account. This guide walks through the model end to end — seller verification, sessions, identifying funds, collection, payouts, refunds — then applies it to service platforms and lists what to prepare with the integration team.

Marketplace payments in Morocco: why a common pot makes everything harder

The reflex when you launch a marketplace is to collect every sale into one account — the platform's — and then pay each seller what they are owed. At launch, with few sellers, a spreadsheet does the job. As the catalog grows, the common pot turns into a backlog of work:

• matching every incoming payment to the order and the seller it belongs to;
• working out what each seller is owed, period by period, net of cancellations;
• deciding whose money covers a refund when a customer sends an item back;
• explaining to a seller why their payout does not match what they think they sold.

Every correction happens after the fact, by hand, and every mistake costs you trust with the very sellers who keep your catalog alive. The ChariPay distribution model turns the problem around: nothing is pooled into a common pot. Each seller has its own wallet, and the checkout session of each order names the one to credit.

Collecting other merchants' money also raises a legal question, which we cover separately: the article on collecting on behalf of others quotes what law 103-12 says, and only your advisor can give an opinion on your own setup. And if you first looked at foreign marketplace tools such as Stripe Connect, our article on Stripe in Morocco covers their availability; this guide starts from a solution operated in Morocco.

The model: each seller is a verified sub-merchant with its own wallet

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. A marketplace maps onto it simply: your platform is the partner, and each seller becomes a sub-merchant in your distribution space.

What the model gives you, in practice:

• Sellers created one by one or in bulk, each with its own wallet.
• Built-in KYC: a sub-merchant is verified like any merchant — documents and trade register — before collecting in production.
• Balance caps, set wallet by wallet, with an alert when a sub-merchant approaches its own.
• Collections that follow the allocation defined when the partnership is set up; nothing is pooled into a common pot.

Seller verification is therefore not a formality you have to invent: it is the same path as for any merchant, built into the tool. A seller who is not yet verified can appear in your catalog, but it does not collect in production until its verification is approved. Plan for that in-between status in your platform rather than discovering it the day a customer tries to pay. The full offer is described on the distribution and sub-merchants page.

Before any setup work, you can see what your buyers will see: 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 after re-authenticating. From there you can create checkout sessions and pay them with the test card on the hosted checkout, 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.

One order, one session, one wallet to credit

On a marketplace, the checkout session is the unit of work. An order becomes a session: you create the session server-side, redirect the buyer to the hosted checkout — card with 3-D Secure — and receive the result through a signed webhook. What sets this session apart from a regular merchant's lies in one parameter: config.settlement, which names the sub-merchant wallet to credit.

The life of an order, step by step:

1. 1The buyer confirms their cart with one of your platform's sellers.
2. 2Your server creates the session with the amount, your orderId, the buyer's details and, in config.settlement, the seller's identifier: walletId (the ID of its wallet) or subMerchantReference (its sub-merchant reference).
3. 3The buyer is redirected to the hosted page and pays by card: the cardholder confirms with their bank.
4. 4The successful payment is attached to the named seller: its wallet is the one the session credits.
5. 5Your server receives the signed webhook; that is when you confirm the order.

Confirm the order when the webhook arrives, never on the redirect alone: the redirect says the buyer came back, not that the payment is secured. Each session has a limited lifetime — 72 hours by default, expiresAt to shorten it — and is consumed only once.

Two limits to keep in mind from the design stage. First, a session collects cards only; cash at an agency goes through a single-use payment link, and how such a link attaches to a seller's wallet is not publicly documented: only a session names that wallet, through config.settlement. Second, we publish no mechanism for dividing one payment among several sellers: a cart that mixes sellers is a question to raise at setup time, with the integration team. The calls themselves, with a sample request, the errors and the events to listen for, are covered in sub-merchants through the API.

Each seller's money identified the moment it is collected

With a common pot, identifying money is a month-end job. Here it happens at the transaction: each sub-merchant's collections are identified from that moment, each one attached to its seller, and follow the allocation defined when the partnership is set up.

On the systems side, two markers let you tie each payment back to your own database:

• your metadata, a flat object you attach to the session — for example { "sellerId": "v_204", "orderNumber": "1042" } — which comes back verbatim in the payment event;
• your orderId, which a session's event also carries.

So find your order through these two values: a session's externalId, for its part, does not come back in the event. Keep technical identifiers in your metadata — seller, order, cart — rather than the buyer's personal data.

What this changes day to day: when a seller asks how their sales are doing, the answer no longer depends on a manual reconciliation; when a customer complains about an order, you know at once which seller it belongs to; when your accountant closes the month, every movement already carries the reference that explains it.

Collection, payouts and refunds

Once the money is identified, it still has to move. The distribution space provides four building blocks:

Payouts follow the four-eyes rule: whoever requests never approves, and your system is told the outcome through a signed webhook — payout.completed when the payout is executed, payout.failed when it fails. So decide from day one who on your team prepares payouts and who approves them.

Running these flows — choosing the collection frequency, caps and alerts, payouts, reconciliation — is covered in detail in network collection and payouts.

Service platforms: the same model for independent providers

A service platform does not sell goods: it connects customers with independent providers — home repairs, lessons, coaching, translation, cleaning. The model is the same: each provider is declared as a sub-merchant, and everyone's money is identified the moment it is collected, instead of being untangled afterwards from a shared account.

Take a platform that connects households in Casablanca and Rabat with home-repair companies. The customer books a job and pays on the hosted checkout; the session names the wallet of the company chosen; the metadata carries the job ID. The day a company asks for the detail of its collections, its monthly statement covers only its own activity.

Three points specific to services:

• Provider eligibility: each one is verified like any merchant — documents and trade register — before collecting in production. Check at recruitment that they can provide these documents.
• When payment happens: a session lives 72 hours by default. Charge at booking rather than after the job, and shorten expiresAt if the slot needs to be released sooner.
• Mass cancellations: if a whole day of jobs is canceled, bulk refund campaigns save you from handling each customer by hand.

Setting it up with the integration team

A marketplace setup is prepared with the integration team: that is where the allocation, the caps, the collection frequency and the approvers are defined. To arrive with a workable file, gather:

• the list of your sellers and, for each one, its documents and trade register;
• the point in your order flow where your server will create the session;
• the seller and order identifiers you will put in the metadata;
• the public HTTPS URL of your webhook endpoint;
• the people who will request payouts and those who will approve them — never the same ones;
• the collection frequency you are aiming for, daily or weekly.

The move to production 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. In your code, you change only the key and the webhook secret: URLs, payloads and error codes are identical to those in test mode. To open the conversation about your marketplace, contact the team.

Frequently asked questions

How do I collect payments for several sellers on a marketplace in Morocco?

By declaring each seller as a sub-merchant, verified like any merchant and given its own wallet. Each order becomes a checkout session created by your server, whose config.settlement parameter names the seller wallet to credit. The buyer pays by card on the hosted checkout, and each seller's money is identified the moment it is collected, with no common pot to redistribute.

Does each seller have to be verified before selling?

Yes: a sub-merchant is verified like any merchant — documents and trade register — before collecting in production. KYC is built into the distribution space, and we publish no timeline. The wallet.activated event tells you a wallet has been activated, wallet.rejected that it was turned down: add a "pending verification" status to your platform and wire it to these two events.

Can sellers be added in bulk?

Yes: sub-merchants are created one by one or in bulk, each with its own wallet. Bulk creation is for launch, when you bring over an existing seller base; one-by-one creation is for afterwards, as new sellers sign up. Either way, every seller goes through the same verification before collecting in production.

How does the buyer pay for an order?

By card, on the checkout hosted by ChariPay, with 3-D Secure: the cardholder confirms with their bank. By default, Visa, Mastercard and Maroc Pay are accepted. Your server creates the session, redirects the buyer, then confirms the order when the signed webhook arrives. A session collects cards only; cash at an agency goes through a different tool, the single-use payment link.

What record does each seller receive?

Its record is the monthly statement produced for each sub-merchant, which covers only its own activity. On the platform side, each seller's money is identified the moment it is collected, with no common pot to untangle at month-end. For your own reconciliation, your metadata — seller ID, order number — comes back verbatim in the payment event.

Do I need a developer to connect a marketplace?

Yes, for the payment side: the session that names the seller's wallet is created server-side, through the API, and results arrive by signed webhook at an endpoint you declare. The overall setup — sellers, allocation, approvers — is prepared with the integration team, and test mode lets you build your sessions without real money.

Can a service platform apply the same model to its providers?

Yes: a platform that connects customers and providers declares each provider as a sub-merchant, and everyone's money is identified the moment it is collected, instead of being untangled afterwards from a shared account. Each provider is verified like any merchant — documents and trade register — before collecting in production, so make sure upfront that your providers can supply these documents.

Next step

Start with your buyers' experience: Start in test mode, create a session and pay it with the test card. Then prepare your marketplace setup — sellers, caps, collection frequency, approvers — using the distribution and sub-merchants page as your guide. To move on to the setup itself, contact the team.