PCI DSS для інтернет-магазину: що залишається вашою відповідальністю з LiqPay
Підключили LiqPay або інший платіжний сервіс — і питання безпеки карткових даних закрито? Не зовсім. Провайдер відповідає за свою інфраструктуру та послуги в межах підтвердженої відповідності. Магазин — за власну інтеграцію, застосовні вимоги до сайту й контроль підрядників. PCI DSS для інтернет-магазину залежить передусім від маршруту карткових даних, а не від логотипа сервісу біля кнопки «Оплатити».
Чи потрібен PCI DSS з LiqPay?
Так, використання провайдера не скасовує відповідальність продавця. Проте обсяг перевірки може суттєво зменшитися, якщо магазин не зберігає, не обробляє та не передає карткових даних власними системами.
Важливо розрізняти дотримання вимог і спосіб підтвердження відповідності. Не кожному магазину потрібен повний зовнішній аудит: залежно від умов може застосовуватися SAQ — анкета самооцінки. Форму звітності погоджують з еквайром, тобто банком, який забезпечує приймання карткових платежів, або іншою стороною, що приймає підтвердження відповідності.
PCI DSS і платіжний шлюз: три сценарії інтеграції
Переадресація на сторінку провайдера
Покупець переходить на платіжну сторінку сервісу й там вводить реквізити. Наприклад, LiqPay Checkout передбачає передавання карткових даних безпосередньо в LiqPay.
За виконання всіх критеріїв така модель може відповідати SAQ A. Але сайт магазину залишається важливим: зламана CMS або плагін можуть підмінити адресу переходу й спрямувати покупця на шахрайську сторінку.
Вбудована форма: iframe
Платіжна форма відображається всередині сторінки магазину, але завантажується від провайдера. Для можливості застосувати SAQ A всі елементи форми, що збирають карткові дані, мають надходити безпосередньо від відповідного PCI DSS провайдера.
Для такої моделі актуальна SAQ A також передбачає підтвердження захисту сайту від атак через скрипти, здатних вплинути на оплату. Це можуть бути власні захисні заходи або підтвердження провайдера щодо захисту його рішення за умови правильної інтеграції. Самого слова «віджет» у назві модуля недостатньо.
Власна форма або передавання через сервер
Якщо магазин створює поля введення, а браузер надсилає дані прямо провайдеру, це може бути Direct Post із застосуванням SAQ A-EP.
Якщо реквізити проходять через сервер магазину, обсяг вимог зазвичай значно ширший: для самооцінки розглядають SAQ D, а за умовами програми відповідності може знадобитися зовнішній аудит. Навіть короткочасне оброблення даних має значення. Принцип «ми нічого не зберігаємо» не виключає передавання чи оброблення.
Які вимоги PCI DSS до сайту залишаються?
Межі перевірки визначають за фактичною архітектурою. До них можуть входити CMS, платіжні модулі, вебсервер, адміністративні доступи, механізми оновлення коду та інші компоненти, здатні впливати на безпеку оплати.
Перевірте також журнали помилок, резервні копії, CRM і системи аналітики: чи не потрапляють туди карткові реквізити? Не всі ці системи автоматично входять до обсягу оцінки — вирішальними є дані, зв’язки та можливість впливу.
Навіть SAQ A не означає «нічого перевіряти». Зокрема, для сайтів із переадресацією або iframe застосовуються вимоги щодо зовнішнього сканування вразливостей ASV.
Що уточнити у провайдера й еквайра
До запуску підготуйте схему руху даних: від натискання кнопки до отримання статусу платежу. Попросіть письмові відповіді на ключові запитання.
- У провайдера: чи охоплює актуальний AOC — документ підтвердження відповідності — саме обрану послугу?
- У розробника: хто формує поля оплати, куди йдуть реквізити та що записується в журнали?
- У провайдера: які вимоги виконує він, які залишаються магазину та як захищена вбудована форма?
- В еквайра: яка форма підтвердження потрібна, які строки подання й вимоги до сканування?
Розподіл відповідальності потрібно зафіксувати, а статус відповідності провайдера перевіряти щонайменше щороку. Після зміни інтеграції варто переглянути й застосовність обраної SAQ.
Коротке дерево рішень
Дані картки проходять через ваш сервер?
Так → розглядайте SAQ D або аудит відповідно до вимог еквайра.
Ні, але поля картки створює ваш сайт?
Так → перевіряйте критерії SAQ A-EP.
Ні, використовується переадресація або iframe провайдера?
Перевіряйте критерії SAQ A; для iframe — також захист від атак через скрипти.
Це початкова орієнтація, а не автоматичне призначення анкети. Запити «PCI DSS Україна» та «SAQ A Україна» стосуються міжнародного стандарту: окремої спрощеної української SAQ немає.
Визначте вимоги до запуску оплати
Плануєте запуск магазину або зміну платіжного модуля? Зверніться до «Систем Менеджмент» щодо оцінки платіжної інтеграції та визначення застосовних вимог PCI DSS. Почніть зі схеми оплати — вона допоможе зрозуміти обсяг робіт до того, як інтеграція запрацює.
