Замовлення оплачене, гроші надійшли, покупець отримав підтвердження. Для магазину все виглядає нормально. Однак реквізити картки могли потрапити до зловмисників ще під час введення — через шкідливий код на сайті. Така атака називається web skimming.
Розберемо, як вона працює, що перевірити у власному магазині та як платіжні інструменти WayForPay допомагають зменшити ризики роботи з картковими даними.
Як дані викрадають без зриву покупки
Web skimming, або e-skimming, — це перехоплення карткових та інших персональних даних під час взаємодії покупця із сайтом. Замість фізичної накладки на банкомат зловмисники використовують програмний код.
За поясненням американського агентства кібербезпеки CISA, такий код може потрапити на сайт через вразливість платформи, викрадені облікові дані адміністратора або скомпрометований сторонній сервіс. Інформація перехоплюється під час введення та передається на сервер нападників.
Уявімо магазин, у якому через застарілий плагін зловмисник змінив сторінку оформлення замовлення. Перед справжньою оплатою покупцеві показують підроблену форму. Після введення реквізитів вона повідомляє про «помилку» та відкриває справжню платіжну сторінку. Людина повторює дію, оплачує покупку, але перша форма вже передала дані стороннім.
Це ілюстративний сценарій, а не опис інциденту. Підроблені вбудовані форми та спливні вікна, які імітують справжній checkout, описані у звіті Visa про загрози.
Інший варіант — непомітне копіювання даних із полів, до яких шкідливий скрипт має доступ. В обох випадках успішна оплата не доводить, що реквізити не були викрадені раніше.
Реальний кейс: усі думали, що безпекою займається хтось інший
Показовий випадок описав британський регулятор ICO щодо магазину Direct Clothing. У серпні 2021 року покупець повідомив про шахрайські операції з карткою після використання сайту компанії.
Перевірка виявила шкідливий код, який дозволяв зловмиснику отримувати реквізити карток покупців. Доступ до сайту він здобув через вразливість WordPress. Однак на момент інциденту сайт мав стільки невиправлених вразливостей, що визначити, яку саме використав нападник, не вдалося.
Важлива деталь: компанія вважала, що за безпеку й обслуговування сайту відповідає IT-підрядник, проте фактично це було не так.
Для підприємця цей кейс починається з простого запитання: хто саме оновлює плагіни, погоджує зміни на сторінці оплати та реагує на підозрілу активність? Відповідь має бути закріплена в домовленостях із підрядником. Формулювання «сайтом займається розробник» недостатньо: створення магазину та його подальший захист — різні завдання.
Читайте також: Чому клієнти не довіряють онлайн-оплатам — і як бізнесу це виправити
Що показують перевірки платіжних сторінок
За результатами SecurityMetrics за 2026 рік, у 67% перевірок платіжних сторінок сервісом Shopping Cart Inspect виявили проблеми різного рівня небезпеки — від потенційних слабких місць до ознак викрадення даних.
Це не означає, що 67% інтернет-магазинів зламані. Йдеться про конкретну вибірку перевірок, яка не представляє весь ринок. Серед усіх виявлених проблем 4% належали до категорії malicious — зі свідченнями крадіжки карткових даних. Решта були підозрілими або потенційно небезпечними.
Практичний висновок: перевіряти варто не лише підтверджені витоки, а й умови для їх виникнення. Застарілий компонент або неконтрольований скрипт ще не доводить наявності атаки, але потребує уваги до того, як його використовує сайт.
Чому HTTPS, 3D Secure та AntiFraud виконують різні завдання
HTTPS шифрує передавання даних між браузером і сервером. Він не перевіряє, чи безпечний кожен скрипт на сторінці. Якщо шкідливий код уже перехопив інформацію в браузері, захищене з’єднання з платіжним сервісом не скасує цієї крадіжки.
Саме тому PCI SSC рекомендує перевіряти, який код завантажується та виконується на сторінці оплати в браузері покупця, і відстежувати несанкціоновані зміни. Перевірки лише файлів на сервері магазину недостатньо: сторінка може додатково завантажувати код сторонніх сервісів.
Інші засоби захисту також мають конкретне призначення:
За поясненням EMVCo, 3D Secure допомагає автентифікувати власника картки. AntiFraud WayForPay, своєю чергою, аналізує транзакції та поведінкові ознаки для оцінювання ризику. Для бізнесу це взаємодоповнювальні засоби: перевірка платежу працює разом із захистом середовища, у якому покупець починає оплату.
Як платіжна інтеграція допомагає зменшити ризики
Один із практичних кроків — організувати оплату так, щоб магазин не збирав карткові реквізити власними формами.
Наприклад, WayForPay пропонує платіжну сторінку, на якій покупець вводить реквізити, та платіжний віджет. Віджет відкривається поверх сторінки магазину, але, за документацією, фактично оплата відбувається на стороні WayForPay. Це дозволяє використовувати готову платіжну форму замість самостійної реалізації збору карткових даних.
Ключове значення має правильне підключення. Розробник повинен перевірити, що реквізити не збираються додатковими полями магазину, не потрапляють у його журнали чи інструменти аналітики, а платіжний компонент завантажується з офіційного джерела.
Для повторних покупок WayForPay також підтримує оплату в один клік на базі токенів. У передбаченому сценарії магазин використовує токен для платіжної операції замість повторного передавання повних реквізитів картки.
Водночас важливо розрізняти крадіжку даних зі справжньої форми та підміну цієї форми. Наявність стороннього скрипту на сайті сама по собі не означає, що він може прочитати вміст належно ізольованої платіжної форми іншого походження. Проте зловмисник, який контролює сторінку магазину, може спробувати показати власні поля перед нею або змінити напрямок переходу до оплати.
Тому використання готового платіжного рішення потрібно поєднувати з контролем сайту, який його відкриває.
Читайте популярне: Скільки насправді коштує онлайн-оплата бізнесу: WayForPay про комісію, конверсію та автоматизацію
Що потрібно знати про PCI DSS
Вимоги PCI DSS 6.4.3 та 11.6.1 стосуються контролю скриптів платіжної сторінки та виявлення несанкціонованих змін. Для власника магазину їхня практична суть — знати, який код працює під час оплати, перевіряти його цілісність і вчасно отримувати повідомлення про підозрілі зміни.
Конкретні обов’язки залежать від інтеграції. У роз’ясненні щодо анкети самооцінки SAQ A PCI SSC окремо розглядає вбудовану форму провайдера та перенаправлення на його сторінку.
Якщо платіжна форма вбудована в сайт магазину, бізнес має підтвердити, що вона захищена від атак через шкідливі скрипти на сайті. Для цього можна впровадити відповідні засоби захисту або отримати від платіжного провайдера підтвердження, що його рішення забезпечує такий захист за умови правильного підключення.
Якщо покупець переходить на окрему сторінку платіжного сервісу, саме ця вимога не застосовується. Проте магазин усе одно має дбати про безпеку свого сайту. Які перевірки та документи потрібні для вашого способу приймання оплат, уточніть у свого еквайра.
П’ять запитань, які варто передати розробнику
Власнику бізнесу не потрібно самостійно читати JavaScript. Потрібні конкретні відповіді, які дозволять перевірити організацію захисту.
Окремо перевірте, чи потрібні на сторінці оформлення всі рекламні теги, чати та віджети відгуків. PCI SSC називає такі сторонні сервіси можливими шляхами проникнення шкідливого коду. Компонент, корисний у каталозі, може бути зайвим біля оплати.
Для адміністративних облікових записів варто застосовувати багатофакторну автентифікацію. Кожному працівнику чи підряднику слід надавати лише ті права доступу, які потрібні для його роботи, а після завершення співпраці — закривати доступ. За регулярне оновлення CMS, плагінів і бібліотек має відповідати конкретний фахівець або команда.
Після зміни теми, встановлення плагіна чи додавання тегу перевіряйте весь шлях покупця. Важливо оцінити не лише те, чи проходить платіж, а й те, які форми, скрипти та мережеві запити з’являються під час оформлення.
Читайте також: Платіж не пройшов: як бізнесу зрозуміти, де виникла проблема і що робити далі
Що робити за підозри на витік
Незаплановане поле для картки, невідомий домен у запитах сторінки або звернення покупців про шахрайські операції після покупки потребують перевірки. Самі скарги ще не доводять, що джерелом витоку є магазин.
За обґрунтованої підозри потрібно:
- залучити відповідального за безпеку та припинити використання підозрілої форми;
- повідомити платіжного партнера й еквайра, узгодити подальші дії;
- зберегти журнали подій, підозрілий код і час виявлення для розслідування;
- встановити точку проникнення, закрити доступ нападника та змінити скомпрометовані облікові дані.
Збереження доказів, визначення джерела шкідливого коду та зміна відповідних облікових даних входять до рекомендацій CISA щодо реагування. Просто видалити видимий фрагмент недостатньо: невиправлена вразливість може дозволити повторне зараження.
Почніть із перевірки трьох речей: де покупець вводить реквізити, хто може змінювати цю сторінку та хто отримає сповіщення про підозрілу зміну. Готові платіжні інструменти WayForPay допомагають передати платіжну частину спеціалізованому сервісу. Контроль доступів, компонентів і змін на сайті має доповнювати це рішення в щоденній роботі магазину.
Ознайомтеся з іншими популярними матеріалами:
Головні причини відмов онлайн-платежів у 2026 році
Від онлайн-курсів до QR-меню: як бізнес в Україні переходить в онлайн
Як ШІ змінює онлайн-платежі — тренди, які бізнесу варто враховувати