Law 09-08 and ecommerce: your customers' personal data in online payments
Law 09-08 and ecommerce: the personal data in an online payment, what you never receive, safe metadata, access control and the role of the CNDP.
Law 09-08 and ecommerce: your customers' data — name, email, phone, purchase history — is personal data under law 09-08, for which the CNDP is the supervisory authority. An online payment moves some of it: what you send to create a session or a link, what a subscription requires. There is one piece you never receive, the card number. This guide takes stock, field by field, of what passes through a payment, then lays out the right habits (metadata with no sensitive data, neutral labels, role-based access) and the questions to put to your advisor.
Law 09-08 and ecommerce: which data are we talking about?
Your customers' data — name, email, phone, purchase history — is personal data under law 09-08, for which the CNDP is the supervisory authority. The CNDP (Commission nationale de contrôle de la protection des données à caractère personnel) presents the law and the procedures it governs on its website; that is the official source to consult, and we do not detail here the obligations or formalities that follow from it.
For an online store, this data is not abstract: it sits in the customer record, the order history, the WhatsApp conversations, the exports you send to your accountant. Payment is only one part of it, but a sensitive part, because it ties an identity to a purchase and an amount.
ChariPay is a Moroccan payment platform, a PSP operated by Chari Money, a payment institution licensed by Bank Al-Maghrib; personal data is processed under law 09-08. What the platform does to protect it is described on our security and compliance page. This guide covers the other half: what you, the merchant, send, receive and keep.
What passes through a payment, product by product
Each way of collecting payments sends a different set of customer data. The table below lists them as the API defines them:
| Product | Customer data sent | Who enters it |
|---|---|---|
| Checkout session (hosted checkout) | config.customer: email, firstName, lastName, phone (required) | You, server-side, when creating the session; the card itself is entered by the customer |
| Payment link | customerName, customerEmail, customerPhone (optional) | You, if you choose to fill them in; the card is entered by the customer |
| Subscription | The client (POST /v1/clients): name required, email (needed, because that is where each due date's payment link is sent), phone optional | You create the client; on every due date, they enter their card themselves on the hosted page, with 3-D Secure |
Three practical takeaways. For a session, the four customer fields are required: plan for them in your checkout flow, and put in only what the customer gave you. For a link, the customer fields are optional: if you do not need them, leave them out; less data sent means less data to protect. For a subscription, the email is essential, because that is where each due date's payment link and the reminders are sent; the card itself is entered by the customer on the hosted page, at each payment, with 3-D Secure.
To know exactly what you send, 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; create a session or a link with dummy data and pay 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.
What you never receive: card numbers
There is one piece of data that table does not contain. 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.
For you, the consequence is concrete: your customer database, your exports and your messages have no reason to contain a card number. If one shows up (a customer sending it over WhatsApp, for example), it is an accident to fix, not data to keep. Card data falls under its own framework, the PCI DSS standard, covered in PCI DSS for merchants.
metadata: an identifier, never sensitive data
The metadata field lets you attach your own information to a session, a link, a product or a subscription. It is a flat object (strings, numbers, booleans, no nested object or array) of 4 KB at most, echoed verbatim on reads and in the payment webhook. That is exactly why it needs care: whatever you put in it travels back to your servers, your technical logs and your webhook endpoints.
Good practice is to put an identifier in it, and nothing but an identifier:
{
"metadata": { "cartId": "c_987", "source": "web" }
}A cart ID is enough to find everything else in your own system, where you control access. Never put a name, an address, a national ID number, health information or a personal reason in it: that information has no business in a field that travels with every event. How to find an order from its identifiers is covered in matching a payment to its order.
Neutral labels
The same care applies to free text. A payment link is an amount and a description; a session carries your orderId, your business reference. Neither is the place for a diagnosis, a personal reason or an ID number: the description travels with the link, shared over WhatsApp or by email, and the reference is there to reconcile, not to describe.
A few examples drawn from Moroccan businesses:
| Business | Avoid in the description or reference | Prefer |
|---|---|---|
| Dental practice | "Root canal, molar — Amine Bennani" | "Appointment on October 14" |
| Tutoring center | "Catch-up classes — struggling in math" | "Tutoring — October" |
| Real estate agency | "Rent — tenant's national ID number" | "October rent — unit B3" |
| Online store | "Amine's order, size 44, delivery to Maarif" | "Order #1042" |
The principle is simple: the label says what it is about without saying who it is, and the details stay in your own file, behind your own access controls. The payment flow of three of these businesses is covered in online payments for clinics, school fees online and collecting rent online.
Who sees what: roles and exports
In the portal, not everyone sees everything. Portal roles separate viewing from acting: the accountant reads everything without triggering anything, the cashier collects without seeing the balance or transfers. How to assign them is covered in portal roles and access.
On the platform side, two protections complement these roles: sensitive data is masked in logs, and the export of personal data is tightly controlled. On your side, the rule is least access:
- 1Give each person the narrowest role that does the job: a cashier does not need the accountant role.
- 2Keep the accountant role for those who must read the full history, including an outside firm if you have one.
- 3Treat your CSV exports like customer files: where are they stored, who receives them, when do you delete them?
- 4Remove access for people who leave the business, on the same day.
Telling your customers
Your customers have an interest in knowing who processes their payment. Say it plainly on your site, for example in your terms of sale or on the checkout page, using the facts as they are:
Card payments are processed by ChariPay, a Moroccan payment platform, a PSP operated by Chari Money, a payment institution licensed by Bank Al-Maghrib. You enter your card on a hosted payment page: we never see your card number.
The identity of the entity that operates ChariPay is in our legal notice. Your own privacy policy, however, is not written from a blog post: it depends on your processing, your service providers and your practices, and your advisor is the one who can help you write it.
Questions about your customer data to ask your advisor
We do not detail any obligation under law 09-08: the CNDP is the supervisory authority, and your situation is your own. Here are the questions to prepare, without a ready-made answer:
- 1What formalities do I need to complete with the CNDP for my customer files?
- 2How should I inform my customers, and where on my site or in my checkout flow?
- 3How long should I keep my own files: orders, exports, conversations?
- 4What data can I share with my service providers (payments, delivery, hosting, messaging), and under what framework?
- 5How should I answer a customer who asks what data I hold about them?
For each of these questions, only your advisor can give an opinion: this article is not legal advice.
Frequently asked questions
Does law 09-08 apply to an online store's data?
Your customers' data — name, email, phone, purchase history — is personal data under law 09-08, for which the CNDP is the supervisory authority. An online store collects it with every order. To know exactly what that means for your business, only your advisor can give an opinion.
Who oversees the application of law 09-08?
The CNDP (Commission nationale de contrôle de la protection des données à caractère personnel): it is the supervisory authority for law 09-08. Its website, cndp.ma, presents the law and the procedures it governs; that is the official source to consult. We do not detail the obligations that follow from it: for your business, only your advisor can give an opinion.
Which customer data is required to create a checkout session?
Four fields, required in config.customer: email, firstName, lastName and phone, in international format (for example +212600000000). You send them server-side when creating the session. The card itself is entered by the customer on the hosted checkout: you never see a card number. Do not add other personal data elsewhere in the request.
Can I put my customer's name or address in metadata?
Avoid it. metadata is echoed verbatim on reads and in the payment webhook: whatever you put in it travels back to your servers and logs with every event. Put an identifier in it, such as a cart number, and keep the name, the address or any sensitive information in your own system, behind your own access controls.
What data does a subscription keep?
The client record (their name, which is required; their email, which is needed because that is where each due date's payment link and the reminders are sent; their phone if you fill it in), then, for the subscription itself, the amount, the description, the frequency, your metadata and the list of generated installments, each with its link and its state. On every due date, the customer enters their card on the hosted page, with 3-D Secure: you never see its number.
Can my accountant see my customers' data?
Yes. The accountant role reads everything (transactions, links, refunds, transfers, balance) and exports, without triggering anything. Keep it for the people who need it, including an outside firm, give everyone else the narrowest role that does the job, and treat its CSV exports like customer files.
What should I tell my customers about how their payment is processed?
Say who processes the payment and where the card is entered: card payments are processed by ChariPay, a Moroccan payment platform, a PSP operated by Chari Money, a payment institution licensed by Bank Al-Maghrib, and the card is entered on a hosted page, without you ever seeing its number. Your privacy policy, however, is written with your advisor.
Next step
Check for yourself what each product sends: Start in test mode, create a session and a link with dummy data, and trim your metadata down to identifiers only. Then put your questions to your advisor. For the card data framework, read PCI DSS for merchants.
Sources
- CNDP — Commission nationale de contrôle de la protection des données à caractère personnel — read on October 2, 2026
Written by ChariPay team.