Conformité des paiements PrestaShop : PCI DSS et ce que la boutique doit prouver

Au 14 octobre 2026, la conformité PCI DSS d’une boutique PrestaShop se règle d’abord sur l’origine de chaque élément de la page de paiement. Une redirection vers le site du prestataire relève du questionnaire d’auto-évaluation (SAQ) A. Une iframe aussi, cadre du prestataire affiché dans la page de la boutique, avec depuis le 1er avril 2025 une confirmation que le site résiste aux attaques par script. Un formulaire construit par la boutique et envoyé au prestataire relève du A-EP, questionnaire des pages dont des éléments viennent de la boutique. Le reste, le D.

• L’acquéreur ou le réseau de paiement valide la conformité PCI DSS d’une boutique PrestaShop selon la norme du PCI SSC
• Le questionnaire d’une boutique PrestaShop dépend de l’origine de chaque élément de la page de paiement
• Les exigences 6.4.3 et 11.6.1 visent les scripts et les en-têtes de la page de paiement
• Depuis le 1er avril 2025, une boutique en iframe confirme que son site résiste aux attaques par script
• Ce que la boutique doit prouver tient en trois pièces
• Attendre ou ne rien faire dépend du questionnaire : redirection et iframe, pas A-EP ni D
• La documentation de PrestaShop décrit les types d’intégration, pas le questionnaire qui en découle
• Sources consultées
• Foire aux questions

L’acquéreur ou le réseau de paiement valide la conformité PCI DSS d’une boutique PrestaShop selon la norme du PCI SSC

Le PCI Security Standards Council, ou PCI SSC, publie la norme PCI DSS. Il ne contrôle pas son application : son billet du 10 mars 2025 invite les entités à travailler avec leurs acquéreurs ou les réseaux de paiement pour la validation et le compte rendu. L’acquéreur est la banque du marchand.

La version en vigueur est la 4.0.1, publiée le 11 juin 2024. Le Council indiquait qu’elle ne contient aucune exigence ajoutée ni retirée par rapport à la 4.0. La 4.0 a été retirée le 31 décembre 2024, et la date d’effet des exigences nouvelles restait le 31 mars 2025. Ces dates sont passées : tout ce que la 4.0.1 demande vaut déjà.

Le questionnaire d’une boutique PrestaShop dépend de l’origine de chaque élément de la page de paiement

Le questionnaire A exige que tous les éléments de la page de paiement viennent d’un prestataire conforme PCI DSS, aucun de la boutique. Le A-EP admet des éléments de la boutique ou du prestataire conforme, et rien d’autre. Le Council le formule dans ses FAQ 1291 (août 2015) et 1293 (juin 2014). Le D recueille les marchands qu’aucun autre questionnaire ne couvre, d’après son supplément d’avril 2015.

La documentation développeur de PrestaShop 9 décrit quatre types d’option de paiement. Le tableau les rapproche des cas du supplément d’information du Council d’avril 2015, qui énumère les intégrations de chaque questionnaire. Ce rapprochement est une déduction : ni PrestaShop ni le Council ne le publient, et le type d’un module ne fixe pas le questionnaire.

Le classement ne suffit pas à lui seul. La FAQ 1293 précise que tous les critères d’un questionnaire doivent être remplis : respecter la condition sur la page de paiement ne rend pas éligible si un autre critère manque. Les FAQ de 2014 et 2015 donnent le principe ; les critères en vigueur pour la 4.0.1 se lisent dans les questionnaires à jour du Council.

Les exigences 6.4.3 et 11.6.1 visent les scripts et les en-têtes de la page de paiement

Selon le billet du Council du 10 mars 2025, ces deux exigences de PCI DSS 4.x visent à ce que les scripts d’une page de paiement soient autorisés, vérifiés dans leur intégrité et surveillés contre toute altération. Ensemble, elles couvrent aussi la gestion des en-têtes HTTP qui touchent à la sécurité. Le billet ne répartit pas ces sujets entre les deux ; leur libellé exact ne se lit que dans la norme.

Le Council a publié en mars 2025 un supplément d’information, « Payment Page Security and Preventing E-Skimming », qui guide l’application de ces deux exigences.

Un scénario PrestaShop : la page de paiement charge un script de mesure d’audience, un widget d’avis et le script du module de paiement. Pour savoir où se situe la boutique, ouvrez cette page avec les outils de développement du navigateur, onglet Réseau, et notez chaque script avec son origine. Cette liste dit quoi justifier, autoriser ou retirer.

Décrire mon besoin →

Depuis le 1er avril 2025, une boutique en iframe confirme que son site résiste aux attaques par script

Depuis sa révision applicable au 1er avril 2025, le questionnaire A pose une condition : le marchand confirme que son site n’est pas exposé aux attaques par script qui pourraient toucher son système de vente. Selon la FAQ 1588, elle ne vaut que pour les marchands dont la page intègre la page ou le formulaire de paiement d’un prestataire, une iframe par exemple.

La FAQ 1588 ouvre deux voies. La première applique des techniques comme celles des exigences 6.4.3 et 11.6.1, par le marchand ou par un tiers. La seconde obtient du prestataire de paiement, conforme PCI DSS, la confirmation que sa solution, mise en œuvre selon ses instructions, protège contre les attaques par script. La seconde voie transfère la preuve au prestataire : demandez-la par écrit.

La même FAQ écarte un cas : un fournisseur dont le seul service est de fournir des scripts sans rapport avec le paiement n’est pas un prestataire de services tiers pour le questionnaire A. Elle y met une condition : ces scripts ne peuvent pas affecter la sécurité des données de carte.

Ce que la boutique doit prouver tient en trois pièces

Trois pièces : le questionnaire, que le Council encourage à confirmer auprès de l’acquéreur ou du réseau concerné ; la preuve de conformité PCI DSS du prestataire ; une pièce propre au mode d’intégration.

La preuve de conformité du prestataire : les FAQ 1291 et 1293 conditionnent le questionnaire A à des éléments venant d’un prestataire conforme.

La pièce propre au mode d’intégration. En iframe : la confirmation du prestataire ou les contrôles de scripts du marchand. En A-EP : la sécurité du site de la boutique, raison d’être de ce questionnaire d’après le supplément de 2015. La mission durcissement du serveur décrit les contrôles du serveur de la boutique.

Le code de vérification de la carte, le cryptogramme visuel, ne se conserve pas après l’autorisation, même chiffré. Le billet du Council du 2 novembre 2017 le dit au titre de l’exigence 3.2 de la norme de l’époque, et ne réserve la conservation qu’aux émetteurs. La numérotation de la 4.0.1 est à confirmer dans la norme.

Attendre ou ne rien faire dépend du questionnaire : redirection et iframe, pas A-EP ni D

Une boutique en redirection n’a aucune surveillance de scripts à installer : le critère de script ne la concerne pas, d’après la FAQ 1588. Elle remplit le questionnaire A quand son acquéreur le demande.

En iframe, la boutique attend la confirmation écrite de son prestataire avant d’acheter un outil de surveillance : selon la FAQ 1588, elle peut suffire.

Changer de type d’intégration pour alléger le questionnaire se décide avec l’impact sur le parcours de commande : une redirection fait quitter le site, et la mission tunnel de commande traite ce parcours.

En A-EP ou en D, la confirmation du prestataire prévue par la FAQ 1588 ne vaut que pour le questionnaire A. Cette page ne tranche pas l’application de 6.4.3 et 11.6.1 à ces deux cas : elle se confirme dans la norme et auprès de l’acquéreur. Inventoriez les scripts sans attendre.

Décrire mon besoin →

La documentation de PrestaShop décrit les types d’intégration, pas le questionnaire qui en découle

La page des modules de paiement de la documentation développeur de PrestaShop 9 décrit les types hors ligne, externe, intégré et iframe, ainsi que l’appel de serveur à serveur du prestataire vers la boutique. Elle ne dit pas quel questionnaire PCI DSS en découle : le rapprochement du tableau ci-dessus vient des documents du Council.

Des éditeurs de modules de paiement indiquent le questionnaire que leur mode d’intégration permet, mais leur fiche ne remplace pas la documentation du prestataire. Une même fonction de module peut produire un cas A ou A-EP selon sa mise en œuvre : posez la question à l’éditeur par écrit.

Sources consultées

• PCI Security Standards Council, FAQ 1291, « Why is SAQ A-EP used for Direct Post while SAQ A is used for iFrame or URL redirect ? », août 2015, consulté le 14 octobre 2026.
• PCI Security Standards Council, FAQ 1293, « If a merchant’s e-commerce implementation meets the criteria that all elements of payment pages originate from a PCI DSS compliant service provider… », juin 2014, consulté le 14 octobre 2026.
• PCI Security Standards Council, FAQ 1588, « How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts ? », février 2025, consulté le 14 octobre 2026.
• PCI Security Standards Council, billet « FAQ clarifies new SAQ A eligibility criteria for e-commerce merchants », 28 février 2025, consulté le 14 octobre 2026.
• PCI Security Standards Council, billet « New Information Supplement : Payment Page Security and Preventing E-Skimming », 10 mars 2025, consulté le 14 octobre 2026.
• PCI Security Standards Council, billet « Just Published : PCI DSS v4.0.1 », 11 juin 2024, consulté le 14 octobre 2026.
• PCI Security Standards Council, supplément d’information « Understanding SAQs for PCI DSS Version 3 », avril 2015, consulté le 14 octobre 2026.
• PCI Security Standards Council, billet « FAQ : Can CVC be stored for card-on-file or recurring transactions ? », 2 novembre 2017, consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de la version 9, « Payment modules », consulté le 14 octobre 2026.

Foire aux questions

Une boutique qui redirige vers la page du prestataire doit-elle remplir un questionnaire ?

Oui, le questionnaire A : la redirection est l’un des cas qu’il couvre. Vérifiez auprès de votre acquéreur que le A est bien le questionnaire demandé : le Council le recommande à tous les marchands.

Le certificat HTTPS suffit-il à prouver la conformité ?

Non. HTTPS chiffre l’échange entre le visiteur et le serveur. Le questionnaire dépend de l’origine des éléments de la page de paiement, d’après les FAQ 1291 et 1293.

Un prestataire de paiement conforme dispense-t-il la boutique de PCI DSS ?

Pas automatiquement. Selon la FAQ 1293, la conformité du prestataire ne suffit pas : le questionnaire a d’autres critères d’éligibilité à remplir. La boutique répond de ce qui vient de son site.

Peut-on conserver le code au dos de la carte pour les paiements suivants ?

Non. Le Council écrit qu’un marchand ne conserve pas le code de vérification après l’autorisation, même pour un paiement récurrent ou une carte enregistrée, et que le chiffrement ne rend pas la conservation conforme.

Que faire quand on change de module de paiement ?

Refaites le classement du tableau : le nouveau module peut modifier l’origine des éléments de la page de paiement, et par suite le questionnaire. Demandez au prestataire la confirmation sur les scripts si le module passe en iframe.