Tokenisation carte bancaire + conformité PCI DSS : ce qu'un site africain doit savoir (2026)

Quand votre boutique africaine accepte les cartes bancaires, vous entrez dans le périmètre PCI DSS (Payment Card Industry Data Security Standard). Mal géré, c'est un audit à 8M FCFA, des sanctions, et un risque de fuite catastrophique. Bien géré via tokenisation, c'est un workflow propre et conforme avec très peu d'overhead.

TL;DR

- PCI DSS = norme obligatoire pour tout commerçant traitant des cartes.

- 4 niveaux de conformité selon volume — la plupart des PME africaines = niveau 4 (SAQ A ou A-EP).

- Tokenisation déléguée (Stripe, PayDunya, Adyen) ramène votre périmètre PCI à quasi-zéro.

- Coût audit niveau 4 SAQ A : ~500K-1M FCFA + travail interne.

Comprendre les 4 niveaux PCI DSS

Pour la plupart des PME africaines (boutiques 100-2000 commandes/mois), c'est niveau 4. SAQ = Self-Assessment Questionnaire.

Choisir le bon SAQ

SAQ A = ~22 questions, à compléter en 2-3h. SAQ D = ~330 questions, plusieurs semaines de travail.

La règle d'or : faire en sorte d'être SAQ A. Cela revient à utiliser la tokenisation déléguée.

Tokenisation : qu'est-ce que c'est

Au lieu de stocker le numéro de carte client (PAN — Primary Account Number), vous stockez un token :

• Émis par votre passerelle (Stripe, PayDunya)
• Lien avec la vraie carte chez la passerelle
• Utilisable pour des charges futures (abonnements, repeat purchases)
• Sans valeur si fuité (vous ne pouvez rien faire avec hors votre compte Stripe)

`ts

// Avec Stripe

const customer = await stripe.customers.create({ email: 'client@example.com' });

// Token créé via Stripe Elements côté frontend

// Backend reçoit un payment_method_id, pas le PAN

// Attacher le PaymentMethod au customer

await stripe.paymentMethods.attach(paymentMethodId, { customer: customer.id });

// Pour une charge future

const intent = await stripe.paymentIntents.create({

amount: 12000,

currency: 'eur',

customer: customer.id,

payment_method: paymentMethodId,

off_session: true,

confirm: true,

});

`

Vous stockez : customer.id + paymentMethodId dans votre base. Aucun numéro de carte chez vous = SAQ A applicable.

Architecture conforme SAQ A

`

[Browser client]

↓

[Page checkout — iframe Stripe Elements]

↓

[Stripe.js POST direct → Stripe API] // PAN ne touche JAMAIS votre serveur

↓

[Stripe → token]

↓

[Token envoyé à votre backend]

↓

[Backend stocke token + customer_id en DB]

↓

[Charges futures via token]

`

Les flèches qui passent par votre serveur ne contiennent JAMAIS le PAN. C'est la condition SAQ A.

Que mettre dans votre base sans risque

Erreurs PCI fréquentes

• Logger les requêtes complètes sans filtrage → PAN potentiellement loggé. Toujours masquer dans logger middleware.
• Sauvegarder les emails clients avec PAN dans le ticket support → fuite. Process : redact à l'arrivée.
• Utiliser un input pour la carte sur votre site directement (pas iframe) → SAQ A-EP au mieux, plus de risques.
• Form contact qui demande "votre carte" en clair → catastrophe. Bannir.

Procédure SAQ A annuelle

• Compléter le PCI DSS SAQ A v4.0 (gratuit, sur pcisecuritystandards.org)
• Faire un scan ASV (Approved Scanning Vendor) sur votre site → ~150-300 USD/an (TrustWave, Qualys)
• Signer une AOC (Attestation of Compliance)
• Soumettre à votre acquéreur (Stripe, PayDunya, ou banque acquéreuse)

Total annuel : ~500K-1M FCFA + 1-2 jours de travail.

Délégation maximale = niveau 4 SAQ A facile

Pile recommandée pour PME africaine :

• Stripe Elements ou PayDunya hosted page pour saisie carte
• Aucun PAN sur votre serveur
• Token + customer_id stockés dans Postgres
• Logger middleware qui redact tout ce qui ressemble à un PAN

Avec cette pile, votre périmètre PCI est ~5 pages dans le SAQ A, audit auto-évalué annuel = 2-3h.

Cas réel — boutique mode → fuite évitée

Une boutique mode Dakar a subi en 2024 un breach de sa base via SQL injection. Leak : 12 000 emails + numéros téléphone + tokens Stripe. Conséquences :

• 0 carte exposée (tokens sans valeur isolés)
• Stripe a invalidé les tokens proactivement
• 0 amende PCI (pas de PAN dans la base)
• Notification CDP Sénégal sous 48h
• Coût total incident : 4M FCFA (audit + comm) vs ~50M+ si PAN fuités

C'est exactement la valeur de la tokenisation déléguée.

FAQ

Q : Stripe Connect / Marketplace = même règle ?

R : Oui. Les marketplaces utilisent Connect avec destination charges. Le PAN ne touche jamais votre serveur. SAQ A applicable.

Q : Si je veux faire des recurring payments sans Stripe ?

R : Utiliser un autre prestataire qui tokenise (Adyen, PayDunya recurring, Mollie). PAN sur votre serveur = SAQ D = enfer.

Q : Apple Pay / Google Pay réduisent les obligations ?

R : Oui, ce sont des wrappers tokenisés. Le PAN n'est jamais transmis. Couplé à Stripe, vous restez SAQ A.

Conclusion

PCI DSS fait peur mais c'est gérable avec la bonne architecture. La règle qui simplifie tout : ne JAMAIS toucher au PAN. Déléguer 100 % de la saisie carte à Stripe ou PayDunya. Stocker uniquement des tokens. Vous restez SAQ A, audit auto-évalué, conformité quasi gratuite. C'est la stratégie de 95 % des PME e-commerce africaines bien gérées en 2026.