PCI DSS in Morocco: a standard, not a license, and what it means for merchants
PCI DSS in Morocco for merchants: standard or license, what ChariPay's Level 1 certification covers and how your integration choice shapes your scope.
PCI DSS in Morocco is not a license: it is the card data security standard published by the PCI Security Standards Council, and a payment platform can be certified against it. For a merchant, the real question is scope. If your customer enters their card on a hosted payment page, within a certified scope, you never see a card number. If you build your own card form, you step inside the card-data compliance scope. This guide explains the difference, what a platform's certification does not do for you, and the questions to put to your advisor.
What is PCI DSS?
PCI DSS is the card data security standard published by the PCI Security Standards Council, designed, as the Council describes it, to strengthen the security of payment card account data and to encourage the wide adoption of consistent data security measures worldwide. Level 1 is the most demanding.
Two things follow from that definition. First, it is not a piece of Moroccan legislation: it does not appear in law 103-12, and it is not Bank Al-Maghrib that publishes it. Second, it covers one specific thing, payment card data: the rest of your customers' data falls under a different framework.
PCI DSS license or certification: two different things
The phrase "PCI DSS license" mixes two notions that have neither the same source nor the same purpose. In Morocco, a license in the legal sense is what Bank Al-Maghrib grants an institution so that it may operate. PCI DSS, on the other hand, is a standard, and a platform can be certified against it.
Take our own case to make it concrete. ChariPay is a Moroccan payment platform, a PSP operated by Chari Money, a payment institution licensed by Bank Al-Maghrib. Both notions show up, held by two different parties:
| License | PCI DSS certification | |
|---|---|---|
| Nature | Legal permission to operate | Compliance with a card data security standard |
| Who grants or publishes it | Bank Al-Maghrib, under law 103-12 | The standard is published by the PCI Security Standards Council |
| What it covers | The institution and its right to operate | Card data security on the platform |
| Who holds it at ChariPay | Chari Money, the payment institution that operates ChariPay | The platform, PCI DSS Level 1 certified, a certification renewed every year |
Neither one carries over to your business: what concerns you directly is your own card-data scope.
With the hosted page, your customer enters their card within a certified scope
On your side, the flow stays simple. 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. A payment link follows the same logic: the customer pays on a page hosted by ChariPay.
Your customer enters their card on the hosted checkout, within a PCI DSS Level 1 certified scope: you never see a card number, and your self-assessment questionnaire is reduced accordingly — to be confirmed with your advisor or your acquirer. On the platform side, card numbers are never written to the database.
In practice, what you read after a payment is a status and an amount (with GET /v1/payment-sessions/{sessionId} for a session) and your metadata, echoed verbatim in the event: never a card number. Your server, your database, your confirmation emails and your support tool have no reason to hold one.
See it for yourself: 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 test key after re-authenticating and pay with the test card provided, 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.
With your own card form, the scope changes
Some businesses want to keep card entry inside their own interface. Direct checkout lets you build your own card form: session verification, card submission, 3-D Secure return, payment status. These calls are not authenticated by your API key but by the session and its single-use verify key (vk) — never send your API key there — and they put you inside the card-data compliance scope. In direct checkout, the /checkout/* calls are made by your server, server-to-server; on the hosted checkout, ChariPay's payment page makes them itself.
That choice only makes sense if you have a specific reason not to use the hosted page. The table sums up what changes:
| Hosted page | Your own card form | |
|---|---|---|
| Where the card is entered | On the payment page hosted by ChariPay | In your form, on your website or app |
| Card number | You never see it | Your form collects the card data, and your server sends it |
| How calls are authenticated | Your API key, server-side, to create the session | Your API key to create the session, then, for the /checkout/* calls, the session and its single-use verify key (vk), never your API key |
Who makes the /checkout/* calls | ChariPay's payment page | Your server, server-to-server |
| 3-D Secure | On the hosted page | A 3-D Secure return to handle in your flow |
| Scope | Reduced self-assessment questionnaire, to be confirmed with your advisor or your acquirer | You step inside the card-data compliance scope |
The technical implementation, call by call, is covered in our article on direct checkout. Before you go there, have your advisor review the change in scope: they are the one who can tell you what your own form implies for your business.
What ChariPay's certification does not do for you
The PCI DSS Level 1 certification applies to the platform. It does not carry over to your business and does not cover what happens on your side. The certified scope is where your customer enters their card; it does not extend to your website, your computers or your customer service inbox.
That leaves on your side:
- your website: the pages that lead to payment, your return and notification URLs;
- your access: who signs in to the merchant portal, and with which role;
- your API keys: where they are stored, and who can read them;
- what your team receives by message: a customer in a hurry may send their card as a photo or in plain text, and that is how card data can accidentally enter a business that never needed it.
What the platform does on its side (double-entry accounting, dual approval, an audit log, strong authentication) is detailed on our security and compliance page.
PCI DSS best practices for merchants
A few simple rules keep card data out of your business:
- 1Never ask for a card number by email, phone or message, and never accept one. Send a payment link instead: the customer pays on the hosted page, and you receive the status.
- 2If a customer sends their card unprompted, do not copy it anywhere and do not enter it yourself: reply with a payment link, and explain that the card is entered only on the payment page.
- 3Treat your API keys as secrets: a key is a secret, never in the browser, a mobile app, a git repository or a screenshot. The details are in protecting your API keys.
- 4Protect portal access: two-factor authentication (TOTP) is turned on from your account settings and, once enabled, is requested at sign-in; re-authentication is required before every sensitive action; give each person the narrowest role that does the job.
- 5Declare `https://` URLs for your returns and notifications: the API rejects any other URL.
Two neighboring topics deserve their own read: the scams that target merchants, from the fake screenshot to the fake refund, in online payment fraud, and your customers' personal data, which falls under a different framework from PCI DSS, in personal data and law 09-08.
The questions to ask your advisor or your acquirer
We cannot tell you which questionnaire applies to your business: it depends on your integration, your activity and who is asking. Here are the questions to put to them, without a ready-made answer:
- 1Which self-assessment questionnaire applies to my current integration (hosted page, payment links)?
- 2What changes if I build my own card form?
- 3What evidence should I keep, and how often should I update it?
- 4Could my third-party tools (messaging, support desk, CRM) receive card data, and what should I do if that happens?
- 5Who in my company is responsible for these questions?
Your questionnaire is reduced with the hosted page — to be confirmed with your advisor or your acquirer. For anything about your own obligations, only your advisor can give an opinion: this article is not legal advice.
Frequently asked questions
Do I need a PCI DSS license to sell online in Morocco?
PCI DSS is not a license: it is a card data security standard published by the PCI Security Standards Council. In Morocco, the legal license is the one Bank Al-Maghrib grants an institution; at ChariPay, it is held by Chari Money. What concerns you is your scope: with the hosted page, it is reduced — to be confirmed with your advisor or your acquirer.
Does my ecommerce website need to be PCI DSS compliant?
It depends on where the card is entered. With the hosted checkout, your customer enters their card within a PCI DSS Level 1 certified scope, you never see a card number, and your self-assessment questionnaire is reduced accordingly — to be confirmed with your advisor or your acquirer. Your website, your access and your keys remain your responsibility.
What does PCI DSS Level 1 mean?
PCI DSS is the card data security standard published by the PCI Security Standards Council, and Level 1 is the most demanding. The ChariPay platform is PCI DSS Level 1 certified, a certification renewed every year. That certification applies to the platform: it does not carry over to your business and does not replace good practices on your side.
Do I see my customers' card numbers?
No, if you use the hosted page or a payment link: the customer enters their card on the payment page, and you read the payment's status and amount. On the platform side, card numbers are never written to the database. It is a different story if you build your own card form: you then step inside the card-data compliance scope.
Does building my own card form change my obligations?
Yes, the scope changes. Direct checkout lets you build your own form; its /checkout/* calls are made by your server, server-to-server, and authenticated by the session and its single-use verify key (vk), never by your API key; they put you inside the card-data compliance scope. That choice only makes sense if you have a specific reason not to use the hosted page.
Can I take a card number by email or WhatsApp and charge it myself?
Do not. A card number received by message enters your business with no protection at all, and it is the cardholder who confirms the payment with their bank through 3-D Secure, not you. Send a payment link instead, by email or WhatsApp: the customer enters their card on the hosted page, with 3-D Secure, and you only see the payment status.
Who can confirm which PCI DSS questionnaire applies to my business?
Your advisor or your acquirer, because the answer depends on your integration and your activity. Prepare a description of your payment flow (hosted page, links, your own form) and the list of tools that receive customer messages; also note who, on your side, has access to the portal and to the API keys. Only your advisor can give an opinion.
Next step
See for yourself what your server receives after a payment, a status and never a card number: Start in test mode, then pay with the test card on the hosted page. Then have your scope confirmed by your advisor or your acquirer. For the platform side, the security and compliance page sums up what ChariPay does on its end.
Sources
- PCI Security Standards Council — PCI DSS — read on October 2, 2026
- Bank Al-Maghrib — Law No. 103-12 on credit institutions and similar bodies, consolidated version as of March 31, 2022 (PDF, in French) — read on October 2, 2026
Written by ChariPay team.