A business comparing payment providers in Morocco has two decisions to make: how customers will pay, and which organisation will take responsibility for the commercial service. A familiar terminal, wallet or payment page answers only part of that question.
For a shop selling at the counter and collecting invoices remotely, Maroc Pay acceptance and Fatourati bill payments may both be relevant. The useful comparison connects each customer journey to the contract, transaction evidence, refunds and money reaching the business account.
Identify the acquiring relationship first
CMI's December 2025 explanation describes its role as a technical processor serving multiple acquirers, while continuing to operate and commercialise Fatourati. In its account of the card-acquiring transition, the technical equipment and payment experience can continue while the commercial relationship and management of funds move to the acquirer. CMI's explanation of its changing role.
This makes the current agreement more useful than an old integration guide when selecting a provider. Ask who signs the merchant contract, who sets the fees, who handles settlement queries and who resolves technical incidents. Confirm these responsibilities for your proposed service; the transition announcement does not establish that an individual merchant's transfer has completed.
A comparison sheet should name the contracting entity and operational contacts alongside the supported channel. Shared processing infrastructure does not establish identical prices, acceptance policies or support arrangements.
Separate a payment at the counter from paying a bill
For Maroc Pay at a physical checkout, CMI describes terminals displaying a QR code that identifies the merchant and transaction. The customer scans it with an m-wallet application. Ask the proposed provider which wallet acceptance and terminal configuration it will enable for your business. CMI: Maroc Pay on terminals.
Fatourati QR serves a different starting point: an invoice or receivable. CMI's April 2026 announcement describes scanning a code on paper, a PDF, an email or a web page to retrieve bill information. It identifies the Fatourati reference, biller and amount, and retains reference entry as an alternative to scanning. CMI: Fatourati QR.
The procurement question is therefore more precise than “Do you support QR?” A counter sale needs the cashier to recognise the result for that purchase. Invoice collection needs the accounting system to close the correct receivable, even when the customer pays through another channel.
| Business need | Evidence to request from a provider |
|---|---|
| Maroc Pay counter payment | Merchant and transaction identifiers, final outcome and till report |
| Fatourati invoice collection | Invoice-to-reference mapping, payment status and collection report |
| Refund or correction | Supported operation, original-payment linkage and approval process |
| Settlement to the business | Gross collections, deductions, settlement reference and receiving account |
These are qualification questions, not a claim that every product returns the same fields.
Choose how collections enter your working system
CMI describes three ways businesses can access Fatourati: direct API integration, the Fatourati Collect web application, and integration through software providers using Fatourati Agrégateur. Its February 2026 announcement distinguishes invoice generation and payment tracking from managing the funds. CMI: Fatourati Agrégateur.
Compare these approaches against the work your team actually performs. A portal may suit a small collections desk; an accounting integration may reduce repeated data entry when invoice volumes grow. Request a demonstration using your invoice structure, exports and correction process before budgeting for development. Product descriptions do not establish your eligibility or implementation scope.
Test one invoice across two collection channels
Consider a hypothetical Moroccan equipment supplier issuing a MAD 1,200 invoice. It wants customers to pay remotely or at its counter. Suppose a customer settles remotely and then, before staff recognise the result, also pays at the counter. Two successful MAD 1,200 payments would mean MAD 2,400 collected against one MAD 1,200 debt: an excess of MAD 1,200 before any fees.
This is a proposed test case, not a reported incident or a claim about a platform defect. Ask the provider to demonstrate what happens if both channels are available: how staff see an already-paid invoice, whether another attempt is prevented, how delayed updates are handled, and how an excess payment is investigated and returned.
Do not assume that cancelling a bill reference reverses money already collected. Record the actual supported correction or refund process, its evidence and the responsible party. This test gives finance and support teams a clearer purchasing criterion than a long list of accepted methods.
Qualify MAD payouts separately
Receiving invoice payments and paying a supplier or customer are separate requirements. For MAD business payouts, specify the beneficiary type, destination account or wallet, payment purpose and funding source. Request written confirmation of eligibility, limits, fees, funding requirements, rejection handling and reconciliation records.
Also distinguish merchant settlement from an outgoing payment initiated by the business. Domestic acceptance does not establish cross-border settlement or approval for a foreign company. Those questions need confirmation for the actual company, contract and transaction purpose.
What PayStar's Morocco sample contributes
The 14 September 2026 snapshot contains 13 unique recorded payment offers associated exclusively with Morocco: seven marked Deposit and six Withdrawal. All 13 have a MAD currency association.
These are offer records, not thirteen independent providers or live connections. Country, currency and method associations do not prove every possible combination. The sample helps structure questions; current availability, supported operations and business eligibility still require provider confirmation.
PayStar Discovery helps turn that research into a focused PSP shortlist. Share your business activity, country of registration, collection channels, payout needs and expected volumes. You choose the PSP and contract directly with it; the PSP handles approval, processing and settlement under its agreement.
Want information about these payment options for free? Just write to us. Contact Anastasia through PayStar Discovery. Free information concerns the payment options; integration, processing and other services have their own terms. No approval or availability is guaranteed.
PayStar’s role
PayStar provides information and technical services. PayStar is not a bank or PSP, does not arrange payment acceptance or settlement in its own name, does not receive or hold customer or merchant funds, and does not settle those funds. Payment services are provided by the selected provider under a direct agreement with the merchant. PayStar’s API, routing and monitoring operate within the agreed technical role.
