PCI DSS: что это и нужен ли он вашему интернет-магазину

Коротко: PCI DSS - набор базовых технических и операционных требований для защиты платёжных данных; его ведёт совет PCI. По странице совета «Merchant Resources» стандарт рассчитан на все организации, участвующие в обработке платежей, включая торговые предприятия, независимо от размера и объёма операций. Нужно ли небольшому продавцу подтверждать соответствие, определяют платёжные системы; вопросы совет адресует банку-эквайеру и платёжной системе. Объём работы зависит от того, где покупатель вводит данные карты.

Слова PCI DSS попадают в договор с платёжным сервисом, в документацию для разработчика или в надпись на платёжной форме. В статье - что это за стандарт по страницам совета PCI, что совет пишет о небольших продавцах, как способ приёма оплаты связан с объёмом работы по документации CloudPayments и ЮKassa и что записать в задание разработчику.

Сведения о стандарте взяты с шести страниц сайта pcisecuritystandards.org. Страницы английские. Цитаты даны в переводе, для фраз длиннее трёх слов рядом стоит оригинал; перевод наш. О сервисах сказано по документации CloudPayments и по трём страницам ЮKassa. Состояние всех страниц - на 11.10.2026; условия сервисов и версии документов могут измениться.

Требования стандарта и условия отдельных листов самооценки в статье не пересказываются: за ними нужно идти в документы совета PCI. Российские нормы, правила платёжных систем, штрафы и ответственность при утечке данных тоже не разбираются. Цен на сертификацию, проверки и сканирование здесь нет, компании, которые их проводят, не рекомендуются.

Пример вымышленный: магазин садового инвентаря с сайтом example.ru.

Что такое PCI DSS и кто его ведёт?

Коротко: PCI DSS - Payment Card Industry Data Security Standard, стандарт безопасности данных индустрии платёжных карт. Страница совета PCI называет его базовым набором технических и операционных требований для защиты данных платёжного счёта. Стандарт ведёт PCI Security Standards Council; в библиотеке документов совета на 11.10.2026 указана версия PCI DSS v4.0.1.

Страница «PCI Data Security Standard (PCI DSS)» описывает назначение так:

«PCI DSS разработан, чтобы поощрять и укреплять безопасность данных платёжных карт и способствовать широкому внедрению единых мер защиты данных по всему миру. PCI DSS задаёт базовый набор технических и операционных требований, предназначенных для защиты данных платёжного счёта.» (перевод)

Оригинал: "PCI DSS was developed to encourage and enhance payment card account data security and facilitate the broad adoption of consistent data security measures globally. PCI DSS provides a baseline of technical and operational requirements designed to protect payment account data."

• PCI Data Security Standard (PCI DSS), pcisecuritystandards.org

Название расшифровано на странице «Merchant Resources», в вопросе «What is the Payment Card Industry Data Security Standard (PCI DSS)?» (перевод: что такое стандарт безопасности данных индустрии платёжных карт). Кто стоит за стандартом, видно из описания страницы о PCI DSS: совет назван глобальным форумом, который объединяет участников платёжной отрасли, чтобы разрабатывать стандарты безопасности данных и продвигать их внедрение. Платёжные системы American Express, Discover, JCB International, MasterCard и Visa названы на странице «Merchant Resources» учредителями совета (founding payment brand members).

На кого рассчитан стандарт, сказано на странице о PCI DSS в блоке Intended Audience:

«Сюда входят все организации, участвующие в обработке платёжных карт, - включая торговые предприятия, процессоры, эквайеров, эмитентов и сервис-провайдеров.» (перевод)

Оригинал: "This includes all entities involved in payment card processing - including merchants, processors, acquirers, issuers, and service providers."

• PCI Data Security Standard (PCI DSS), pcisecuritystandards.org

В списке стоит слово merchants: торговые предприятия, то есть магазины. Что такое эквайер и кто участвует в платеже, разобрано в статье интернет-эквайринг.

Версию называет библиотека документов. На странице «Document Library» в блоке Featured Documents среди документов стоят «PCI DSS v4.0.1» и «PCI DSS Summary of Changes v4.0 to v4.0.1» (перевод второго названия: краткое описание изменений от v4.0 к v4.0.1). Если подрядчик или сервис называют другую версию, спросите, на какую они опираются.

Касается ли PCI DSS небольшого интернет-магазина?

Коротко: совет PCI отвечает на этот вопрос в два шага. Стандарт рассчитан на все организации, участвующие в обработке платежей, независимо от размера и объёма операций. Нужно ли небольшому продавцу подтверждать соответствие, определяют платёжные системы; с вопросами совет советует идти к банку-эквайеру или в платёжную систему.

Вопрос «Нужно ли небольшим продавцам с ограниченным объёмом операций соблюдать PCI DSS?» стоит на странице «Merchant Resources» (оригинал: "Do small merchants with limited transaction volumes need to comply with PCI DSS?"). Ответ в переводе:

«PCI DSS рассчитан на все организации, участвующие в обработке платежей, включая торговые предприятия, независимо от их размера и объёма операций. У небольших продавцов, по сравнению с крупными, нередко более простая среда: ограниченный объём данных держателей карт и меньше систем, которые нужно защищать, - это может помочь сократить усилия по соблюдению PCI DSS.

Обязан ли небольшой продавец подтверждать соответствие, определяют отдельные платёжные системы. С вопросами о подтверждении соответствия и об отчётности продавцу следует обращаться к своему эквайеру (банку продавца) или к платёжной системе, с которой он работает, в зависимости от случая.» (перевод)

Оригинал: "PCI DSS is intended for all entities involved in payment processing, including merchants, regardless of their size or transaction volume. When compared with larger merchants, small merchants often have simpler environments, with limited amounts of cardholder data and fewer systems that need protecting, which can help reduce their PCI DSS compliance effort. Whether a small merchant is required to validate compliance is determined by the individual payment brands. For questions regarding compliance validation and reporting requirements, merchants should contact their acquirer (merchant bank) or payment brand they do business with, as applicable."

• Merchant Resources, pcisecuritystandards.org

Страница о PCI DSS добавляет общее правило:

«Обязана ли организация соблюдать стандарт PCI SSC или подтверждать соответствие ему, остаётся на усмотрении организаций, которые ведут программы соответствия, например платёжной системы, эквайера или иной организации.» (перевод)

Оригинал: "Whether an entity is required to comply with or validate compliance to a PCI SSC standard is at the discretion of organizations that manage compliance programs, such as a payment brand, acquirer, or other entity."

• PCI Data Security Standard (PCI DSS), pcisecuritystandards.org

В вопросе «Who has to comply with the PCI Standards?» (перевод: кто должен соблюдать стандарты PCI) на странице «Merchant Resources» сказано, что у каждой из платёжных систем-учредителей есть собственная программа соответствия, а за сведениями о ней нужно обращаться в платёжную систему напрямую. Вопросы о требованиях соответствия для данных карт других платёжных сетей и брендов совет адресует соответствующей сети или бренду.

В словах совета два вопроса: кому адресован стандарт и кто требует подтверждения. Ответ на второй, по тем же страницам, зависит от программ платёжных систем и от эквайера. Что потребует именно ваш банк-эквайер или ваша платёжная система, из страниц совета узнать нельзя, это придётся спрашивать у них самих.

Что такое лист самооценки SAQ, QSA и ASV?

Коротко: SAQ (Self-Assessment Questionnaire) - лист самооценки: инструмент, в котором продавец проводит самооценку по PCI DSS и сообщает результаты. Листов несколько, у каждого свои критерии применимости. QSA - независимая организация, которую совет обучил проводить оценки PCI DSS. ASV - организация, которую совет обучил проводить внешнее сканирование на уязвимости.

Сокращения SAQ и ASV встречаются в документации CloudPayments (раздел о Checkout), поэтому здесь они раскрыты словами совета PCI.

Оригиналы фраз из таблицы. FAQ 1215: "PCI DSS Self-Assessment Questionnaires (SAQs) are validation tools for use by SAQ-eligible merchants and service providers to perform and report the results of their PCI DSS self-assessments." FAQ 1133: "There are multiple versions of PCI DSS SAQs to meet various merchant scenarios, depending on how each merchant organization stores, processes, or transmits cardholder data (CHD) and/or sensitive authentication data (SAD)." Страница о PCI DSS: "Qualified Security Assessors (QSAs) are independent security organizations that have been qualified and trained by PCI SSC to perform PCI DSS assessments." и "Approved Scanning Vendors (ASVs) are qualified and trained by PCI SSC to conduct external vulnerability scanning services in accordance with the applicable PCI DSS requirement."

Какой лист подходит, решает не продавец в одиночку. FAQ 1215 пишет:

«Продавцам следует обратиться к организации, принимающей подтверждение соответствия, - той, которой будет передан лист SAQ (...), чтобы определить, вправе ли они подавать SAQ или обязаны, и если да, какой SAQ подходит для их среды.» (перевод)

Оригинал: "Merchants should consult with their compliance-accepting entity - the entity to which the SAQ will be submitted (...) to determine if they are eligible or required to submit an SAQ, and if so, which SAQ is appropriate for their environment."

• FAQ 1215, «What is a PCI DSS Self-Assessment Questionnaire?», апрель 2024

В пропущенной скобке названы эквайер (банк продавца) или платёжная система. Та же страница пишет, что для использования конкретного листа должны выполняться все критерии применимости этого листа (перевод; оригинал: "All the eligibility criteria for a particular SAQ must be met to use that SAQ."). Условия отдельных листов в статье не разбираются: они описаны в документах совета, а CloudPayments для Checkout называет лист SAQ-EP (раздел «Что пишет о PCI DSS CloudPayments?»).

Где искать QSA и ASV, показывает страница «Program Listings Overview». У раздела Qualified Security Assessors (QSA) стоит ссылка «Find a Qualified Security Assessor Company», у раздела Approved Scanning Vendors (ASV) - «Find an Approved Scanning Vendor Company» (перевод: найти компанию-QSA, найти компанию-ASV).

От чего зависит объём работы магазина с PCI DSS?

Коротко: по FAQ 1133 листы самооценки различаются тем, как продавец хранит, обрабатывает или передаёт данные карт. На сайте магазина это превращается в вопрос, где покупатель вводит данные карты: на странице сервиса, в форме сервиса внутри вашей страницы или в форме самого сайта. Документация CloudPayments и ЮKassa привязывает требования именно к этому выбору.

Три варианта на примере двух сервисов:

• ввод на стороне сервиса: ЮKassa называет сценарий «Оплата на странице ЮKassa», где после создания платежа магазин перенаправляет покупателя на страницу ЮKassa, и покупатель выбирает способ оплаты и подтверждает платёж там (страница «Банковская карта»);
• форма сервиса внутри вашей страницы: у CloudPayments это платёжный виджет, у ЮKassa - виджет ЮKassa (что такое виджет и что проверить до запуска - в статье виджет на сайте);
• форма на вашей стороне: у CloudPayments это скрипт Checkout, у ЮKassa - сценарий «Оплата с вводом данных на вашей стороне» и библиотека Checkout.js.

Четыре сценария ЮKassa и слова страницы «Выбор сценария интеграции» о том, кто отвечает за безопасность ввода данных, разобраны в статье как подключить оплату на сайт. Здесь они не повторяются. Про сохранённый способ оплаты, когда списание идёт без повторного ввода карты, - в статье рекуррентные платежи.

Какие данные карты охраняет стандарт, CloudPayments пишет в разделе «PCI DSS»:

«К охраняемым данным относятся полный номер карты и код CVV2/CVC2 (последние 3 цифры на обратной стороне). Имя владельца, срок действия и маскированный номер карты (первые 6 и последние 4 цифры) в защите по требованиям стандарта не нуждаются, поэтому их можно использовать в разумных пределах.»

• Документация CloudPayments, раздел «PCI DSS», подраздел «Соответствие требованиям»

Это формулировка документации CloudPayments. В том же подразделе CloudPayments описывает основное требование стандарта так: «максимально ограничить доступ к данным платежных карт». Предлагаемое решение там такое: «вообще не иметь к ним доступа, а вместо этого использовать сертифицированных провайдеров для приема платежей». Из этого сервис делает практический вывод для общения с покупателями: номера карт нельзя ни запрашивать, ни передавать. Если клиент диктует номер по телефону, его нужно прервать и объяснить, почему вы не можете получать данные карты. Если присылает номер по почте или в Скайпе, сообщение удаляют и сообщают, что передавать данные карты небезопасно.

Что пишет о PCI DSS CloudPayments?

Коротко: раздел «PCI DSS» документации CloudPayments описывает два случая. Для платёжных инструментов сервиса, кроме Checkout, он пишет: «Дополнительных мер предпринимать не нужно», и сканер для виджета и мобильного SDK не требуется. Для Checkout, где форма стоит на вашем сайте, нужны лист самооценки SAQ-EP и сканирование ASV не реже раза в квартал.

Раздел начинается со слов сервиса о стандарте: «PCI DSS - стандарт информационной безопасности, принятый в индустрии платежных карт Visa и Mastercard. Соблюдать требования стандарта обязаны все компании, которые принимают карты к оплате. Некоторым компаниям необходимо подтверждать свое соответствие.» Это слова сервиса. Кто определяет обязанность подтверждать соответствие, совет PCI пишет на своих страницах (раздел «Касается ли PCI DSS небольшого интернет-магазина?»).

Подраздел «Соответствие PCI DSS вместе с CloudPayments» говорит о сервисе:

«CloudPayments - сертифицированный сервис-провайдер с максимальным уровнем соответствия PCI DSS, предоставляющим право хранить данные платежных карт и обрабатывать более 6 миллионов платежей ежегодно. Подтверждение соответствия проходит каждый год в рамках сертификационного аудита.

Все платежные инструменты CloudPayments спроектированы таким образом, что при их использовании вы автоматически соответствуете требованиям по безопасности. Дополнительных мер предпринимать не нужно.

Исключением является прием платежей по технологии Checkout. Для использования необходимо подтверждать соответствие: заполнить лист самооценки и ежеквартально проверять сайт на уязвимости специальным сканером.»

• Документация CloudPayments, раздел «PCI DSS», подраздел «Соответствие PCI DSS вместе с CloudPayments»

Подраздел «ASV-сканирование» уточняет, для каких инструментов нужен сканер:

«Использование сканера необходимо для приема платежей по технологии Checkout, для остальных инструментов - виджет, мобильный SDK, рекарринг и рекуррент - его использование не требуется.»

• Документация CloudPayments, раздел «PCI DSS», подраздел «ASV-сканирование»

О Checkout сказано ещё в двух местах. В разделе «PCI DSS», подраздел «Технология Checkout», сказано: «Данные платежных карт шифруются в браузере покупателя, поэтому ваш сайт не принимает участие в обработке и хранении номеров, что значительно сокращает область применения требований PCI DSS. Тем не менее, сайт влияет на безопасность карточных данных и для его защиты необходимо выполнять сканирование не менее одного раза в квартал для поиска вирусов и уязвимостей. Сканирование должно проводиться аккредитованным вендором (ASV) из списка, представленного на сайте совета PCI.» А в подразделе «ASV-сканирование» добавлено: «Выбор вендора для сканирования остается на ваше усмотрение, но он должен быть из списка на сайте совета PCI.»

В разделе «Скрипт checkout», в блоке «Требования к безопасности по PCI DSS», сервис называет и лист. Слова блока: «Для соблюдения требований стандарта, необходимо заполнять лист самооценки SAQ-EP и ежеквартально проходить ASV-тестирование.» Название листа здесь дано так, как оно написано в документации CloudPayments.

Описание сканирования в подразделе «ASV-сканирование»: это «автоматизированная проверка вашего сайта на наличие уязвимостей», сканер проверяет «наличие вирусов, известных уязвимостей, таких как XSS, SQL Injections и так далее» и составляет отчёт с инструкцией по устранению найденных проблем.

Что пишет о PCI DSS ЮKassa?

Коротко: на странице «Банковская карта» ЮKassa пишет про PCI DSS в одном месте - в сценарии «Оплата с вводом данных на вашей стороне»: «вам нужно получить сертификат на соответствие требованиям PCI DSS». Страница «Checkout.js» слов PCI DSS не содержит; нужны ли при этом подтверждения, она не говорит. Спросите ЮKassa, какие документы по этому способу подключения от вас ожидаются.

На странице «Банковская карта» в списке сценариев один пункт назван с пометкой PCI-DSS: «Оплата с вводом данных на вашей стороне (PCI-DSS)». Раздел с таким же названием, без пометки, начинается словами:

«Чтобы использовать эту возможность, вам нужно получить сертификат на соответствие требованиям PCI DSS.»

• Банковская карта - Прием платежей в интернет-магазине по API ЮKassa, раздел «Оплата с вводом данных на вашей стороне»

Дальше страница описывает сценарий: «В этом сценарии вы самостоятельно реализуете выбор способа оплаты. Вы на своей стороне получаете данные банковской карты пользователя. После этого создаете платеж в ЮKassa и дожидаетесь, когда пользователь подтвердит оплату.» Что именно страница считает таким сертификатом, она не уточняет, и это придётся выяснять у ЮKassa.

Страница «Checkout.js - Прием платежей по API ЮKassa» слов PCI DSS не содержит. Библиотека, как там сказано, «позволяет собирать данные банковских карт пользователей на вашей стороне, без необходимости обрабатывать их на ваших серверах». Чтобы не обрабатывать платёжные данные в системе магазина, Checkout.js, по странице, «обменивает данные, которые ввел пользователь, на одноразовый платежный токен»; токен нужно отправить в запросе на создание платежа. Требует ли этот сценарий каких-либо подтверждений соответствия, страница не говорит. Спросите ЮKassa, какие документы по этому способу подключения от вас ожидаются.

Что значит надпись о сертификате PCI DSS на платёжной форме?

Коротко: источники статьи не объясняют надписей на формах, поэтому можно сравнить только слова документации. CloudPayments говорит о сертификате самого сервиса и отдельно, для Checkout, просит магазин заполнять лист самооценки и проходить сканирование. Надпись о сертификате не заменяет раздела документации о требованиях к сайту.

Совет PCI описывает QSA как организации, которые проводят оценки соответствия PCI DSS. CloudPayments пишет о себе: «сертифицированный сервис-провайдер с максимальным уровнем соответствия PCI DSS» (раздел «PCI DSS», подраздел «Соответствие PCI DSS вместе с CloudPayments»). Эти слова описывают сервис. Для магазина тот же раздел отдельно перечисляет, что нужно при Checkout: лист самооценки и ежеквартальное сканирование.

Если на форме или на сайте сервиса вы видите надпись про сертификат PCI DSS, полезно уточнить у сервиса пять вещей:

1. Кто подтвердил соответствие: сам сервис, независимая организация или платёжная система.
2. К какой части платежа относится подтверждение: к форме, к серверам сервиса или к чему-то ещё.
3. Для какой версии стандарта оно выдано (библиотека совета на 11.10.2026 показывает v4.0.1).
4. Что при выбранном способе подключения остаётся на стороне магазина.
5. Нужно ли магазину что-то подтверждать вашему банку-эквайеру или платёжной системе.

Ответы зависят от сервиса, договора и способа подключения.

Как выбор способа оплаты меняет задание на примере example.ru?

Коротко: у вымышленного магазина садового инвентаря на example.ru три возможных способа подключения. В документации сервисов у них разные слова о PCI DSS: у виджета CloudPayments - «Дополнительных мер предпринимать не нужно», у Checkout - лист SAQ-EP и сканирование, у ЮKassa при вводе данных на стороне магазина - сертификат.

Владелец магазина выбирает, как принимать оплату на example.ru. Он выписывает варианты и то, что каждая из документаций говорит о покупателе и данных карты.

Строки таблицы - слова документаций на 11.10.2026, выбор способа для магазина они не предрешают.

В задании для example.ru должен стоять конкретный вариант: название сервиса, название сценария по документации и ссылка на раздел с PCI DSS. Если выбран Checkout, в задание попадают лист самооценки SAQ-EP и ежеквартальное сканирование с ответственным. Если выбран ввод данных на стороне магазина у ЮKassa, в задание попадает сертификат: страница ЮKassa называет его условием использования этой возможности. Кто и когда его получает, выясняют у ЮKassa и записывают в задание. Если выбран виджет CloudPayments, в задание записывают подключение скрипта с адреса сервиса и вопрос банку-эквайеру: подавать ли лист самооценки (раздел «Что спросить у подрядчика и у платёжного сервиса?»).

Что записать в задание разработчику?

Коротко: девять пунктов собраны из страниц совета PCI и документаций CloudPayments и ЮKassa, у каждого указан источник: сервис и сценарий оплаты, вопрос банку-эквайеру, требования CloudPayments к Checkout, сертификат ЮKassa при вводе данных на стороне магазина, загрузка скриптов с адреса сервиса, правило общения с покупателями, версия стандарта и приёмка. Что такое техническое задание на сайт, написано в статье техническое задание на сайт.

1. Сервис и сценарий оплаты по названиям из документации сервиса: где покупатель вводит данные карты (страница сервиса, виджет, форма на сайте). Источник: документация выбранного сервиса.
2. Вопрос к банку-эквайеру или платёжной системе: нужно ли магазину подавать лист самооценки и какой. Ответ записывают в задание. Источник: FAQ 1215 и «Merchant Resources».
3. Для Checkout CloudPayments: лист SAQ-EP, сканирование не реже одного раза в квартал, ответственный за них и компания ASV из списка на сайте совета PCI. Источник: документация CloudPayments, разделы «PCI DSS» и «Скрипт checkout».
4. Для ЮKassa при вводе данных на стороне магазина: сертификат на соответствие требованиям PCI DSS. Страница называет его условием использования этой возможности. Что именно ЮKassa принимает за сертификат, выясняется у сервиса. Источник: страница «Банковская карта».
5. Скрипт платёжного сервиса подключается с адреса сервиса. CloudPayments пишет: «Всегда загружайте checkout.js с https://checkout.cloudpayments.ru, чтобы соответствовать требованиям. Не включайте скрипт в пакет и не размещайте его самостоятельно.» Для виджета тот же совет дан про cloudpayments.js и адрес https://widget.cloudpayments.ru. Источник: разделы «Скрипт checkout», «Установка виджета».
6. Требования CloudPayments к форме Checkout: «Должна работать по HTTPS-соединению с валидным SSL-сертификатом.»; «На полях не должно быть атрибута "name" - это предотвращает попадание карточных данных на сервер при отправке формы.»; криптограмму «нельзя хранить после оплаты и использовать повторно». Источник: раздел «Скрипт checkout», блок «Требования».
7. Правило общения с покупателями: номера карт по телефону, по почте и в Скайпе не принимаются (так названы каналы в документации). Источник: раздел CloudPayments «PCI DSS», подраздел «Соответствие требованиям».
8. Версия стандарта, которую называют сервис и подрядчик. Источник: страница «Document Library».
9. Приёмка: в браузере на странице оплаты загружаются скрипты с адресов сервиса, форма открыта по HTTPS, а подрядчик передал вам письменные ответы платёжного сервиса на вопросы (раздел «Что спросить у подрядчика и у платёжного сервиса?»). Как проверяют сайт до запуска, разобрано в статье тестирование сайта; сканирование ASV по документации CloudPayments проводит компания ASV из списка совета PCI.

Если оплата подключается по API сервиса, это тоже записывают в задание; что такое интеграция по API и что выяснить заказчику, описано в статье интеграция по API.

Что спросить у подрядчика и у платёжного сервиса?

Коротко: вопросы подрядчику проверяют, что он назвал тот сценарий оплаты, о котором пишет документация сервиса. Вопросы платёжному сервису и банку-эквайеру выясняют, что должен подтверждать магазин, кому и в каком виде. Ответы на все вопросы стоит получить письменно до начала работ, чтобы сценарий оплаты и обязанности сторон попали в задание и договор.

Подрядчику:

1. Какой сценарий оплаты вы предлагаете, и где в нём покупатель вводит данные карты по документации сервиса?
2. Какие страницы документации сервиса о PCI DSS вы прочитали и что они говорят про этот сценарий?
3. Скрипты платёжной формы подключаются с адресов сервиса или хранятся у нас?
4. Попадают ли на наш сервер номер карты и код CVV2/CVC2: в базу, логи, письма, служебные чаты?
5. На какую версию PCI DSS вы опираетесь?
6. Если сервис требует сканирование ASV: кто его заказывает, кто получает отчёт и кто исправляет найденное? Входит ли это в стоимость работ и как описано в договоре? О договоре на разработку - в статье договор на разработку сайта.

Платёжному сервису:

1. Нужно ли магазину при выбранном способе подключения что-то подтверждать по PCI DSS? Какой документ вы имеете в виду: сертификат, лист самооценки, отчёт, иное?
2. Кому он передаётся: вам, банку-эквайеру или платёжной системе?
3. Кто, когда и по какой версии стандарта подтвердил соответствие самого сервиса, и к чему относится подтверждение?

Банку-эквайеру или платёжной системе:

1. Должен ли наш магазин подтверждать соответствие? Подаём ли мы лист самооценки и какой лист подходит для выбранного способа подключения?
2. В каком виде и кому передаётся подтверждение?

Эти вопросы повторяют слова совета PCI: определить, вправе продавец подавать SAQ или обязан, и какой лист подходит, нужно у организации, которая принимает подтверждение.

Что про интернет-магазин сказано на главной BITSPARK?

На главной странице BITSPARK услуга «Интернет-магазин» описана так: «От 55 000 ₽», далее «каталог, корзина, оплаты и необходимые интеграции». Шаг «Разработка» описан словами «Верстаем, программируем и подключаем сервисы. Технологии выбираем под задачу.» Цена относится к услуге студии.

Источники

• PCI Data Security Standard (PCI DSS) - страница совета PCI: назначение, Intended Audience, QSA и ASV, слова о том, кто решает, нужно ли подтверждать соответствие.
• Merchant Resources - страница совета PCI для торговых предприятий: вопросы о стандарте, о небольших продавцах, о том, кто должен соблюдать стандарты.
• FAQ 1215: What is a PCI DSS Self-Assessment Questionnaire? - ответ совета PCI о листе самооценки; страница датирована апрелем 2024 года.
• FAQ 1133: Why are there multiple PCI DSS Self-assessment Questionnaires (SAQs)? - ответ совета PCI о том, почему листов несколько; апрель 2024 года.
• Document Library - библиотека документов совета PCI: «PCI DSS v4.0.1» и «PCI DSS Summary of Changes v4.0 to v4.0.1» в блоке Featured Documents.
• Program Listings Overview - страница совета PCI: ссылки на поиск компаний QSA и ASV.
• Документация CloudPayments - разделы «PCI DSS», «Платежный виджет», «Скрипт checkout».
• Банковская карта - Прием платежей в интернет-магазине по API ЮKassa - сценарий «Оплата с вводом данных на вашей стороне».
• Checkout.js - Прием платежей по API ЮKassa - описание библиотеки.
• Выбор сценария интеграции - Прием платежей по API ЮKassa - слова о том, кто отвечает за безопасность ввода данных; процитированы в статье о подключении оплаты.
• BITSPARK - Digital studio - услуга «Интернет-магазин» и шаг «Разработка».

Обсудить проект в Telegram: t.me/billioniks