Stripe au Maroc en 2026 : pas disponible — et comment encaisser quand même

Vous avez tapé « Stripe Maroc » parce que votre produit est prêt et qu'il ne manque que l'encaissement. La réponse courte tient en une phrase : le Maroc ne figure pas dans la liste des pays où Stripe est disponible, et une entreprise établie au Maroc ne peut donc pas y ouvrir de compte pour encaisser ses clients. La réponse utile est plus longue — elle explique pourquoi, ce que valent les contournements qui circulent, et comment brancher en quelques appels une passerelle marocaine dont vous connaissez déjà le vocabulaire : session de paiement, webhook signé, clé d'idempotence, clés de test et de production.

La réponse en 50 mots

Non, Stripe n'est pas disponible au Maroc en 2026. La liste officielle des pays pris en charge, publiée sur stripe.com/fr/global, ne comprend pas le Maroc, et aucun calendrier d'ouverture n'a été annoncé publiquement. Une entreprise marocaine ne peut donc pas y créer de compte pour encaisser ses clients.

Le reste de cet article part de ce fait, et de rien d'autre. Nous n'y comparons ni grilles tarifaires ni fonctionnalités : nous expliquons pourquoi la situation est ce qu'elle est, ce qui se passe quand on essaie de la contourner, et comment encaisser en dirhams dès aujourd'hui avec une intégration qui ressemble à celles que vous avez déjà faites.

Pourquoi un service de paiement étranger ne s'improvise pas au Maroc

Il est tentant de lire cette absence comme un simple retard de déploiement. C'est plutôt la conséquence d'un cadre : au Maroc, encaisser pour le compte d'un tiers est une activité régulée, et trois contraintes expliquent à elles seules pourquoi un service conçu ailleurs ne s'y installe pas du jour au lendemain. Aucune des trois ne se règle par une ligne de code.

L'agrément de Bank Al-Maghrib

Recevoir l'argent d'un acheteur, le conserver le temps du traitement, puis le reverser à un marchand : c'est l'activité d'un établissement de paiement, et elle est soumise à l'agrément de Bank Al-Maghrib. L'agrément n'est pas une formalité que l'on demande en ligne. Il engage une entité de droit marocain, avec ses fonds propres, sa gouvernance, ses obligations de contrôle interne et de conformité, et il place les fonds des marchands sous la supervision de la banque centrale.

Pour un marchand, cela se traduit par une question simple à poser à n'importe quel prestataire : quelle entité est agréée, et mes fonds passent-ils par elle ? Un service étranger qui n'a pas d'entité marocaine agréée ne peut pas y répondre — et c'est la raison de fond pour laquelle il n'ouvre pas de comptes aux entreprises marocaines. Ouvrir le Maroc, pour un tel service, ce n'est pas ajouter un pays dans un menu déroulant ; c'est créer une entité locale, la doter, la faire agréer et l'exploiter sous supervision.

Le règlement en dirhams, sur un compte marocain

Une entreprise marocaine facture en dirhams, tient sa comptabilité en dirhams et paie ses fournisseurs, ses salaires et ses impôts en dirhams. L'encaissement doit donc arriver en dirhams, sur un compte tenu au Maroc, avec un RIB qui permet à l'expert-comptable de rapprocher chaque vente de chaque mouvement.

Un service qui règle ses marchands dans une devise étrangère, sur un compte tenu hors du Maroc, n'entre pas dans ce circuit. Le rapatriement des fonds relève de la réglementation des changes ; chaque conversion introduit un écart entre ce que le client a payé et ce que l'entreprise enregistre ; et l'argent doit être rapatrié avant d'être utilisable au Maroc. Ce n'est pas un détail d'intégration : c'est la raison pour laquelle le règlement local, en dirhams, sur un compte au nom de l'entreprise, est le premier critère d'un prestataire de paiement au Maroc — avant la commission, avant la documentation.

La TVA et la facture

Quand vos clients sont au Maroc, vos ventes y sont en principe soumises à la TVA marocaine, et vos factures doivent le refléter. Le prestataire qui encaisse doit vous permettre d'établir cette chaîne — la vente, le paiement, le versement — sans conversion à expliquer ni intermédiaire étranger à réconcilier au moment de la déclaration.

Un encaissement réalisé par une entité étrangère complique cette chaîne au lieu de la simplifier : l'argent est parti dans une devise, revient dans une autre, à une date qui n'est plus celle de la vente. Nous y revenons dans la section suivante, avec la réserve d'usage : votre expert-comptable ou votre conseil reste le seul à pouvoir se prononcer sur votre situation précise.

Les contournements qui circulent, et ce qu'ils coûtent vraiment

Sur les forums de développeurs et dans les groupes d'entrepreneurs, deux idées reviennent dès que la question est posée. Elles ne sont pas absurdes — elles répondent à un besoin réel — mais elles ont des conséquences que l'on découvre rarement avant de les avoir subies. Nous les énonçons prudemment : il n'y a pas de chiffre universel, et chaque situation mérite d'être validée avec votre conseil avant la moindre démarche.

Créer une société à l'étranger

Le premier contournement consiste à incorporer une société hors du Maroc — une LLC américaine par un programme d'incorporation en ligne, une société britannique ou française — et à ouvrir le compte chez le prestataire étranger au nom de cette société. Techniquement, cela fonctionne : le compte s'ouvre, les paiements passent, la page de checkout s'affiche.

Ce qui change, c'est tout le reste :

• Les fonds sont encaissés hors du Maroc, sur une entité étrangère. Votre chiffre d'affaires n'arrive plus dans votre société marocaine ; il arrive dans une société que vous devez faire vivre, avec sa comptabilité, ses déclarations et ses frais de tenue.
• Les obligations fiscales du pays d'incorporation s'ajoutent aux vôtres. Une société américaine, britannique ou française a ses propres déclarations à déposer, même quand toute son activité réelle se passe au Maroc.
• Les obligations marocaines ne disparaissent pas. Si vos clients sont marocains et que vous opérez depuis le Maroc, la question de la TVA sur ces ventes et celle de la réglementation des changes — la position de l'Office des Changes sur des revenus encaissés à l'étranger par un résident — se posent entièrement. C'est le point à valider en priorité avec votre conseil, avant d'ouvrir quoi que ce soit.
• Le risque de clôture. Un compte ouvert par une société dont l'activité, les dirigeants et les clients sont dans un pays non pris en charge peut être réexaminé, suspendu ou fermé — avec des fonds bloqués le temps de l'examen. Vous ne choisissez ni le moment ni la durée.
• Vos clients marocains, eux, restent au Maroc. Les cartes marocaines ne sont pas toujours acceptées par un compte étranger, et l'acheteur qui voit un montant dans une devise qu'il ne connaît pas, ou une autorisation refusée par sa banque, abandonne son panier. Vous avez résolu votre problème d'encaissement en en créant un chez chacun de vos clients.

Passer par le compte d'un tiers

Le second contournement consiste à utiliser le compte d'un ami, d'un associé ou d'un prestataire établi dans un pays pris en charge, qui vous reverse ensuite les fonds. Les conditions d'utilisation des services de paiement excluent en règle générale ce montage — un compte est ouvert au nom d'une entité pour l'activité de cette entité, pas pour celle d'un tiers — et il expose les deux parties : le titulaire du compte, qui encaisse une activité qui n'est pas la sienne et en porte les litiges, et vous, qui dépendez d'un reversement sans cadre contractuel, sans RIB à votre nom et sans recours si le compte est fermé.

Ajoutez-y les questions que la section précédente a déjà posées — où sont les fonds, qui les déclare, comment reviennent-ils au Maroc — et le contournement coûte plus cher que le problème qu'il prétend résoudre.

Ce qu'il faut retenir

Ces montages répondent à une question de disponibilité par une question de structure. Si votre entreprise, vos clients et votre activité sont au Maroc, la réponse proportionnée est d'encaisser au Maroc, en dirhams, sur un compte à votre nom, avec un prestataire agréé — et de garder l'énergie de l'incorporation à l'étranger pour le jour où vous aurez réellement des clients à l'étranger.

Encaisser au Maroc avec ChariPay : le vocabulaire que vous connaissez déjà

ChariPay est la passerelle de paiement de Chari, opérée par Chari Money, établissement de paiement agréé par Bank Al-Maghrib. Si vous avez déjà intégré une passerelle moderne, vous ne repartez pas de zéro : les concepts sont les mêmes, l'API est REST, les montants sont en dirhams et le résultat arrive par webhook signé. Voici la correspondance, concept par concept.

Les trois briques qui suivent — la session, le webhook, l'idempotence — suffisent à un premier encaissement en production. Le reste se branche ensuite, au rythme de votre produit.

La session de paiement : un appel, une URL

Vous créez une session côté serveur avec le montant en dirhams — il n'y a pas de champ devise, tout est en MAD, en unités majeures avec deux décimales — votre référence de commande, l'acheteur et les URL de retour. La réponse contient l'URL de la page de checkout hébergée, où l'acheteur paie par carte avec 3-D Secure ou choisit de régler en espèces en agence. La clé d'API voyage dans l'en-tête X-CHARI-PAY-API-KEY, et jamais dans du code exécuté chez l'acheteur.

curl -X POST 'https://api-psp.charipay.ma/v1/payment-sessions' \
  -H 'X-CHARI-PAY-API-KEY: chari_sk_test_...' \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: commande-2026-0421-paiement' \
  -d '{
    "amount": 250.00,
    "orderId": "ORD-2026-0421",
    "externalId": "commande-2026-0421",
    "config": {
      "customer": {
        "email": "amine.bennani@example.com",
        "firstName": "Amine",
        "lastName": "Bennani",
        "phone": "+212600000000"
      },
      "urls": {
        "accept": "https://votre-boutique.ma/paiement/succes",
        "decline": "https://votre-boutique.ma/paiement/echec",
        "notification": "https://votre-boutique.ma/webhooks/charipay"
      }
    },
    "metadata": { "cartId": "c_987", "source": "web" }
  }'

La réponse, en 201, contient entre autres le sessionId et le checkoutUrl :

{
  "sessionId": "ps_5Kd0Rn",
  "checkoutUrl": "https://pay.chari.ma/checkout/ps_5Kd0Rn",
  "expiresAt": "2026-09-11T10:15:00Z"
}

Redirigez l'acheteur vers checkoutUrl, et c'est tout pour la partie visible. La session est à usage unique par défaut et expire 72 heures après sa création si vous ne fournissez pas d'expiresAt. Les URL accept et decline servent au retour de l'acheteur sur votre site ; elles ne font pas foi — un acheteur qui ferme son onglet après le paiement ne verra jamais votre page de succès, alors que l'argent, lui, est bien arrivé. C'est le webhook qui fait foi, et c'est la brique suivante.

Deux champs méritent une attention particulière. orderId est votre référence métier, affichée et renvoyée, sans contrainte d'unicité. externalId est différent : unique par marchand et par environnement, il rend la création rejouable — nous y revenons plus bas. Les URL de config.urls sont toutes optionnelles : une valeur absente retombe sur celle configurée pour votre compte, puis sur la valeur par défaut de la plateforme.

Le webhook signé : la vérification en Node

Un paiement n'aboutit pas au moment où vous l'appelez : l'acheteur passe par sa banque, valide 3-D Secure, revient — ou ne revient pas. Le résultat vous parvient par webhook, et cette notification est la seule source de vérité. Chaque livraison porte deux en-têtes : X-CHARI-SIGNATURE, un HMAC-SHA256 en hexadécimal minuscule calculé sur la chaîne horodatage + "." + corps brut, et X-CHARI-TIMESTAMP, l'horodatage en millisecondes depuis epoch. L'API tolère un écart de ±5 minutes entre cet horodatage et l'heure de réception.

const crypto = require('crypto');

function verify(rawBody, signature, timestamp, secret) {
  // Fenêtre anti-rejeu de ±5 minutes — l'horodatage est en millisecondes.
  if (Math.abs(Date.now() - Number(timestamp)) > 5 * 60 * 1000) return false;

  const expected = crypto
    .createHmac('sha256', secret)
    .update(`${timestamp}.${rawBody}`)
    .digest('hex');

  // Une signature malformée doit répondre false — jamais jeter (500 → retentatives).
  if (!/^[0-9a-f]{64}$/i.test(signature)) return false;

  // Comparaison en temps constant — jamais `===`.
  return crypto.timingSafeEqual(Buffer.from(expected, 'hex'), Buffer.from(signature, 'hex'));
}

Et la route qui l'utilise, avec le corps conservé brut — c'est l'erreur la plus fréquente : un framework qui parse le JSON avant la vérification, puis un objet re-sérialisé dont les octets ne sont plus ceux qui ont été signés.

app.post('/webhooks/charipay', express.raw({ type: '*/*' }), async (req, res) => {
  const raw = req.body.toString('utf8');            // le corps brut, avant tout parsing
  const ok = verify(
    raw,
    req.get('X-CHARI-SIGNATURE'),
    req.get('X-CHARI-TIMESTAMP'),
    process.env.CHARIPAY_WEBHOOK_SECRET
  );
  if (!ok) return res.status(401).end();

  const eventId = req.get('Chari-Event-Id');        // la clé de déduplication
  if (await db.events.exists(eventId)) return res.status(200).end();

  await db.events.insert({ eventId, payload: JSON.parse(raw) });
  await queue.push('handle-charipay-event', eventId);
  return res.status(200).end();                     // accusé, le reste suit
});

Quatre règles font toute la sécurité de la vérification : calculez le HMAC sur les octets bruts avant tout parsing ; rejetez les horodatages trop éloignés ; comparez en temps constant ; dédupliquez sur Chari-Event-Id, pas sur Chari-Webhook-Id, qui change à chaque tentative de livraison. La sandbox et la production signent avec des secrets distincts.

Si votre serveur ne répond pas 2xx, nous rejouons : 1 min, 5 min, 30 min, 1 h, puis toutes les 6 h, jusqu'à 16 tentatives sur environ 72 heures. Si votre serveur était en maintenance plus longtemps, le journal des livraisons du portail montre chaque livraison — nombre de tentatives, dernière réponse de votre serveur, corps exact de l'événement — et permet de la rejouer en un clic. Les événements que vous attendrez le plus : payment.succeeded, payment.failed (si vous l'avez demandé à la création de la session) et, pour les remboursements, refund.succeeded. Un article de ce blog détaille les cinq erreurs classiques et le traitement en quinze lignes : Réussir son intégration des webhooks.

L'idempotence, en deux couches

Le réseau coupe au mauvais moment, votre client HTTP réessaie, et vous ne savez pas si la première tentative est passée. Deux mécanismes se complètent pour que cette situation ne coûte jamais un double encaissement :

• `Idempotency-Key`, l'en-tête que vous envoyez sur vos créations : rejouer un appel avec la même valeur renvoie le premier résultat au lieu de créer un doublon. C'est la protection contre un timeout, une connexion coupée, une file de messages livrée deux fois.
• `externalId`, le champ du corps : unique par marchand et par environnement, il fait de la création une opération que vous pouvez relancer sans conserver le moindre état intermédiaire. Créez deux fois une session avec le même externalId et l'API renvoie la session existante avec un 200 au lieu d'un 201 — le code vous dit exactement ce qui s'est passé.

Un même externalId peut exister une fois en sandbox et une fois en production sans conflit. Dérivez ces clés de votre référence de commande — jamais d'un tirage aléatoire, qui passerait à côté de tout l'intérêt. Le détail et les bons motifs de clés sont dans L'idempotence : ne facturez jamais deux fois.

Test et production : une seule base, deux clés

Il n'y a qu'une base d'URL, https://api-psp.charipay.ma, en sandbox comme en production : c'est la clé d'API qui choisit l'environnement. Une clé chari_sk_test_… cible la sandbox, une clé chari_sk_live_… la production. Les URL, les payloads et les codes d'erreur sont identiques ; le jour du passage en production, vous changez la clé, le secret de webhook, et rien d'autre.

Tant que la production n'est pas activée sur votre compte, une clé de production reçoit un 403 explicite avec le code PRODUCTION_ACCESS_NOT_ENABLED. Ce n'est pas un bug d'intégration, c'est une étape administrative — la liste de ce qui doit être vrai avant la bascule est dans Sandbox → production : la liste avant de basculer.

En sandbox, une seule carte de test suffit : 4918914107195005, avec une date d'expiration future, 123 comme CVV et 555 comme code 3-D Secure. Elle déclenche un vrai parcours — page de checkout, authentification, webhook — sans aucun mouvement d'argent.

Le lien de paiement, pour encaisser sans code

Toutes les ventes ne passent pas par un panier. Un devis accepté sur WhatsApp, une prestation facturée à distance, une cotisation, un acompte : le lien de paiement couvre ces cas sans une ligne de code. Depuis le portail — ou par POST /v1/payment-links — vous créez un lien au montant voulu, à usage unique ou réutilisable, et vous l'envoyez par e-mail, le partagez en QR code ou l'imprimez en affiche. L'acheteur paie sur la même page hébergée, par carte ou en espèces en agence, et le webhook est le même que pour une session. Lien de paiement ou checkout ? aide à choisir entre les deux selon votre volume.

Remboursements, abonnements, produits

• Rembourser. POST /v1/refunds avec l'identifiant du paiement — operationId ou externalId — un motif, et une refundReference de votre choix ; en totalité par défaut, ou pour un montant partiel avec refundAmount. L'API répond 202 le temps du règlement, puis refund.succeeded arrive par webhook. Rejouer la même refundReference renvoie le remboursement existant sans débiter deux fois.
• Abonnements. Créez un abonnement avec ses échéances ; un prélèvement qui échoue est relancé à J+1, J+3 et J+7, et chaque étape vous parvient par webhook. En sandbox, un endpoint force la prochaine échéance, ce qui permet de dérouler une année d'abonnement en une minute et de vérifier votre facturation avant qu'un vrai client ne la subisse.
• Produits et commandes. Un catalogue simple, avec les commandes rattachées à chaque produit — utile quand votre vente se résume à quelques références fixes.

Ce que change un encaissement local

Une passerelle conçue pour le Maroc ne se contente pas de reproduire ce qui existe ailleurs. Trois points, en particulier, changent la façon d'encaisser ici : les espèces en agence, l'argent disponible à l'instant sur un compte de paiement à votre nom, et une sandbox que vous ouvrez seul.

Les espèces en agence

Une partie de vos clients n'a pas de carte, ou ne veut pas l'utiliser en ligne. ChariPay est la seule passerelle de paiement au Maroc à encaisser aussi les espèces en agence : sur la page de checkout, l'acheteur choisit les espèces, reçoit une référence, et dépose le montant dans une agence du réseau Chari. Vous recevez payment.succeeded à la confirmation du dépôt — le même webhook, la même déduplication, le même rapprochement que pour une carte. Le développeur n'écrit rien de plus ; le comptable voit la carte et les espèces sur le même relevé et dans le même export.

Pour une boutique en ligne, cela peut remplacer le paiement à la livraison et son cortège de colis refusés et d'espèces qui voyagent avec le livreur : la commande part déjà payée. Encaisser en espèces sans caisse en fait le tour, du lien de paiement à l'affiche en vitrine.

L'argent disponible à l'instant, sur un compte de paiement avec RIB

Chaque paiement réussi — carte ou espèces — est disponible à l'instant sur votre compte de paiement ChariPay, un compte tenu par Chari Money, avec un RIB au nom de votre entreprise que vous téléchargez depuis le portail ou par l'API. Ce n'est pas un solde en attente de règlement. Depuis ce compte, vous virez vers un compte bancaire marocain — avec devis des frais avant confirmation, code à usage unique si vous l'avez activé, et délai de sécurité de 24 heures pour tout nouveau bénéficiaire —, vous payez des factures, vous lancez des recharges télécom par l'API.

Le versement vers votre banque suit à votre rythme : par virement à la demande, ou automatiquement chaque nuit dès qu'un compte de règlement est configuré. Vous payez un fournisseur le matin avec les encaissements de la nuit. Rapporté à ce que décrit la section sur les contournements — des fonds dans une devise étrangère, sur une entité étrangère, à rapatrier avant d'être utilisables au Maroc —, c'est l'écart le plus concret entre encaisser ici et encaisser ailleurs. La page Wallet et versements détaille ce que vous pouvez faire depuis le compte.

La sandbox self-serve, gratuite, sans limite de durée

Vous n'attendez personne pour commencer. L'inscription se fait en ligne sur portal-psp.charipay.ma/register ; vous activez le compte par e-mail, choisissez un mot de passe, vous connectez, sélectionnez votre entreprise, demandez un jeton de confirmation, créez vous-même votre clé de test et faites votre premier appel — huit étapes, que la collection Postman déroule dans l'ordre, sans rendez-vous et sans e-mail au support. La sandbox est gratuite et sans limite de durée : elle reste votre environnement de recette bien après le passage en production.

Il y a aussi ce que l'on attend d'une passerelle sérieuse et que vous trouverez au même endroit : la certification PCI DSS niveau 1, des données traitées dans le cadre de la loi 09-08, un portail avec plusieurs utilisateurs et des rôles — propriétaire, gestionnaire, caissier, comptable — et des exports CSV pour le rapprochement.

Questions fréquentes

Stripe est-il disponible au Maroc ?

Non. La liste officielle des pays pris en charge, sur stripe.com/fr/global, ne comprend pas le Maroc. Une entreprise établie au Maroc ne peut pas y ouvrir de compte pour encaisser ses clients.

Quand Stripe sera-t-il disponible au Maroc ?

Aucun calendrier n'a été annoncé publiquement. Toute date que vous lisez ailleurs est une supposition. La seule source fiable reste la liste officielle des pays pris en charge ; en attendant, un projet qui doit encaisser aujourd'hui a besoin d'une solution disponible aujourd'hui, en dirhams, sur un compte à son nom.

Une société à l'étranger est-elle une solution pour des clients marocains ?

C'est une solution pour des clients à l'étranger. Pour des clients marocains, elle déplace le problème au lieu de le résoudre : fonds encaissés hors du Maroc, obligations fiscales dans deux pays, questions de change et de TVA marocaines qui restent entières, risque de clôture de compte, cartes marocaines pas toujours acceptées. À valider avec votre conseil avant toute démarche — et, dans la plupart des cas, à écarter au profit d'un encaissement local.

Je fais un SaaS à abonnements : comment encaisser au Maroc ?

Avec les abonnements ChariPay : vous créez l'abonnement par l'API avec ses échéances, les prélèvements suivent, un échec est relancé à J+1, J+3 et J+7, et chaque événement — paiement réussi, échec, résiliation — vous parvient par webhook signé. En sandbox, un endpoint force la prochaine échéance pour tester votre facturation sans attendre un mois. Le montant de chaque échéance arrive à l'instant sur votre compte de paiement, en dirhams. La page Abonnements décrit le cycle complet.

Mon code est prévu pour une passerelle étrangère : que faut-il changer ?

Moins que vous ne le pensez, parce que l'architecture est la même : une création côté serveur, une redirection vers une page hébergée, un webhook signé qui fait foi, une clé d'idempotence sur les créations. Ce qui change, ce sont les noms : amount en MAD sans champ devise, orderId, externalId, config.customer, config.urls ; l'en-tête d'authentification X-CHARI-PAY-API-KEY ; les en-têtes de signature X-CHARI-SIGNATURE et X-CHARI-TIMESTAMP avec leur schéma horodatage + "." + corps brut ; la déduplication sur Chari-Event-Id. Comptez une session de travail pour la session de paiement et le webhook, puis testez avec la carte de test. La documentation API donne chaque endpoint avec ses exemples en quatre langages ; une collection Postman, le contrat OpenAPI et un pack pour assistant de code sont téléchargeables au même endroit.

Combien ça coûte ?

La sandbox est gratuite. Le passage en production coûte 6 000 MAD TTC de mise en service, réglés une seule fois. La commission par transaction réussie — en pourcentage — et la caution sont définies après étude de votre dossier, selon vos produits, vos méthodes de paiement et vos volumes : la proposition arrive chiffrée avant tout engagement. Rembourser un client est gratuit. Le détail est sur la page Tarification.

Comment vérifier que mon intégration fonctionne avant la production ?

En sandbox, avec la carte de test 4918914107195005 (CVV 123, code 3-D Secure 555) : elle déroule le parcours complet — page de checkout, authentification, webhook — sans mouvement d'argent. Envoyez un événement de test sur votre endpoint de webhook, l'API le propose sur chaque endpoint déclaré, et lisez dans le journal des livraisons ce que votre serveur a répondu. Testez aussi un paiement refusé, un remboursement partiel et un webhook auquel votre serveur répond une erreur, pour voir la relance à l'œuvre.

Mes clients n'ont pas tous une carte bancaire : que faire ?

Rien de particulier côté code : la page de checkout propose la carte et les espèces en agence, l'acheteur choisit, et vous recevez le même webhook dans les deux cas. Pour un encaissement à distance, un lien de paiement envoyé par WhatsApp ou par e-mail fait le même travail, et l'affiche avec QR code le fait en boutique.

Prochaine étape

Créez votre compte sandbox sur portal-psp.charipay.ma/register : inscription en ligne, activation par e-mail, clé de test créée par vous-même, sans rendez-vous et sans engagement. Ouvrez ensuite la documentation API — douze modules, soixante-deux endpoints, des exemples en curl, JavaScript, Python et PHP — et faites votre premier POST /v1/payment-sessions avec la carte de test. Quand payment.succeeded arrive sur votre serveur avec une signature valide, vous avez fait l'essentiel : le passage en production tient ensuite dans un changement de clé.