PCI DSS і Adgora: що перевірити щодо карткових платежів

Коротка відповідь: що означала б тут відповідність PCI DSS

PCI DSS — це стандарт безпеки даних індустрії платіжних карток. Простими словами, це звід правил для всіх, хто зберігає, обробляє або передає дані картки. Тож справжнє питання за формулюванням «чи відповідає Adgora PCI DSS для карткових платежів» — не в тому, чи звучить це “безпечно”, а в тому, чи можна використовувати Adgora для карткових платежів так, щоб дані власника картки не потрапляли туди, де їм не місце.

Ця різниця важлива. Платформа може бути безпечною для маркетингу, аналітики чи керування кампаніями і при цьому взагалі не мати справи з номером картки. Якщо Adgora не обробляє платіжні дані напряму, тоді обов’язки щодо PCI DSS зазвичай лежать на продавцеві або окремому платіжному провайдері, а не на самій Adgora; і саме тут виникає питання, чи обробляє Adgora дані картки.

Коротко: шукайте докази, а не припущення. PCI DSS — це не розмите позначення «захищено». Це набір контролів, документів і відповідальностей, пов’язаних із даними картки, і ці відповідальності змінюються залежно від того, де саме відбувається платіж і хто бачить дані.

Коли це питання важливе для типового користувача Adgora

Зазвичай це питання виникає у трьох ситуаціях. По-перше, ви продаєте товар або послугу й хочете приймати карткові платежі на сторінці, пов’язаній з Adgora. По-друге, ви використовуєте Adgora разом із платіжним стеком і хочете знати, чи можуть будь-які платіжні дані проходити через Adgora. По-третє, ви оцінюєте ризики постачальника і хочете зрозуміти, чи взагалі Adgora торкається процесу оформлення замовлення.

Практичний сенс тут простий. Якщо Adgora ніколи не бачить номери карток, коди CVC або повні дані власника картки, навантаження щодо PCI інше, ніж у схемі, де платіжні поля вбудовані прямо в потік Adgora. Один прихований iframe може змінити всю картину відповідності.

Поставте конкретне запитання: Adgora торкається платіжного шляху чи просто розташована поруч із ним? Відповідь на нього може визначити, чи потрібна вашій команді легка самоперевірка, чи більш глибокий платіжний аудит.

Для читачів, які будують комерційні кампанії, логіка така сама. Лендинг, який відправляє покупців до окремого платіжного сервісу, — це одне. Форма оформлення замовлення, що збирає платіжні дані на вашій сторінці, — зовсім інше. Якщо ви також запускаєте кампанії для магазинів, дивіться криптореклама для інтернет-магазинів — там є схожий підхід до налаштування кампаній.

Що перевірити в документації Adgora щодо платежів і безпеки

Почніть із платіжних умов. Потім перевірте сторінки безпеки. Після цього прочитайте будь-які документи для постачальників або юридичні документи, пов’язані з білінгом, обробкою платежів або мерчант-сервісами. Саме ці чотири джерела зазвичай дають більше, ніж головна сторінка.

Шукайте угоду про обробку даних, заяву про безпеку постачальника та будь-яку документацію щодо оформлення платежу. Якщо Adgora використовує окремий платіжний сервіс, назва цього сервісу має десь згадуватися. Якщо ні — і ця тиша теж важлива.

Зверніть увагу на заяву про відповідність, документ із розподілом обов’язків щодо PCI або примітку про те, що дані карток ніколи не зберігаються на серверах Adgora. Один документ із такими формулюваннями може зекономити години здогадок. А відсутність такого документа — навпаки.

Якщо сторінка безпеки занадто загальна, не зупиняйтеся на цьому. Запитайте, чи має Adgora підтвердження PCI від свого процесора, чи оформлення замовлення відбувається на сторонньому хості, і чи якась частина платіжної форми працює на інфраструктурі Adgora. Це не дрібниці для дизайну.

Також перевірте, чи рахунки, підписки або оновлення акаунта обробляються через сторонній білінговий сервіс. Продавець може все одно нести зобов’язання щодо PCI, навіть якщо сама Adgora не бере участі в обробці картки. Це залежить від того, хто саме збирає дані картки і куди браузер їх надсилає.

Вузьке питання: чи обробляє Adgora дані власника картки напряму?

Це й є вузьке питання, і саме воно має значення. Дані власника картки включають номер картки, термін дії та ім’я власника; конфіденційні дані автентифікації включають CVC і дані магнітної смуги, які в звичайних випадках не слід зберігати після авторизації. Якщо Adgora напряму працює з цією інформацією, сфера дії PCI DSS швидко розширюється.

Якщо реквізити картки йдуть лише до окремого платіжного процесора, навантаження змінюється. Більшу частину технічної та договірної відповідальності бере на себе платіжний процесор, а Adgora може залишатися поза платіжним потоком. Саме тому варто простежити шлях у браузері, дію форми та передачу даних на бекенд.

Допомагає простий тест. Відкрийте сторінку оформлення замовлення, подивіться форму і перевірте, куди вона надсилає дані. Якщо платіжна форма належить Stripe, Checkout.com або іншому хостинговому процесору, це один сценарій. Якщо форма спершу надсилає дані в Adgora, а вже потім — до процесора, це інший.

Не вважайте, що “приховане” означає “безпечне”. Деякі сторінки спочатку збирають мінімальні платіжні дані, а потім передають карткову інформацію далі. Інші використовують токенізацію, коли процесор замінює номер картки токеном ще до того, як він потрапляє в систему продавця. Токенізація може зменшити ризики, але не скасовує обов’язків щодо PCI.

Якщо ви дивитесь на це з боку ad-tech або кампаній, це вузьке питання часто пропускають, бо платіжний етап не є самим продуктом. Але платіжний етап усе одно може бути поруч із продуктом. Окремий процесор — це поширено, але поширено не означає підтверджено.

Пов’язані терміни, які ви можете побачити

PCI DSS — це сам стандарт. Він визначає, як продавці та постачальники послуг мають захищати дані карток. Дані власника картки — це інформація, надрукована або закодована на картці, зазвичай номер рахунку та пов’язані відомості.

Платіжний процесор — це компанія, яка приймає платіж карткою і взаємодіє з картковими мережами або банком-еквайром. Платіжний шлюз — це технічний міст, який передає реквізити картки з форми оформлення замовлення до цього процесора. Іноді обидві ролі виконує одна компанія, а іноді ні.

Токенізація замінює справжній номер картки на токен. Токен можна використовувати пізніше для списань, підписок або повернень, але токен — це не сам номер картки. Така невелика заміна може зменшити кількість систем, яким потрібен повний набір PCI-контролів.

SAQ означає Self-Assessment Questionnaire, тобто опитувальник самооцінки. Саме його багато продавців використовують, щоб задокументувати свою позицію щодо PCI, і різні типи SAQ застосовуються до різних схем. PCI scope — це сукупність систем, людей і процесів, які можуть впливати на безпеку даних картки. Якщо Adgora ніколи не торкається платіжних даних, вона може не входити до вашої PCI-сфери. Якщо торкається — сфера швидко зростає.

Для команд, які порівнюють платіжні інструменти та інструменти трафіку, терміни можуть змішуватися. Якщо вам потрібен ще й контекст із боку кампаній, корисним суміжним читанням буде гайд про крипторекламу для сучасних кампаній. Це не PCI-документ, але він допомагає відокремити медіафлоу від платіжного флоу.

Приклади сценаріїв і як їх тлумачити

Сценарій 1: хостингове оформлення замовлення. Користувач натискає «Сплатити», залишає вашу сторінку і вводить дані картки на хостинговій сторінці процесора. У такій схемі Adgora може взагалі не бачити дані картки. Ваше навантаження щодо PCI зазвичай менше, хоча все одно потрібно перевірити перенаправлення та відповідальність процесора.

Сценарій 2: вбудовані платіжні поля. Форма картки знаходиться на сторінці Adgora, але поля надані процесором через iframe або захищений компонент. Це поширено, але відповідь щодо відповідності залежить від того, як саме працює інтеграція і чи може Adgora впливати на сторінку навколо неї. Безпечний iframe — це не те саме, що хостингове оформлення замовлення.

Сценарій 3: ручне виставлення рахунків. Відділ продажів використовує Adgora для лідів, а потім надсилає рахунки електронною поштою або через окремий білінговий інструмент. Якщо співробітники вводять дані картки в термінал або в портал процесора поза Adgora, платформа може бути поза платіжним потоком. Але обов’язки щодо PCI для використаного методу все одно залишаються на продавцеві.

Сценарій 4: регулярні списання із збереженими картками. Тут важливими стають токенізація та збережені платіжні реквізити. Якщо Adgora зберігає лише токени, а номер картки зберігається в процесора, сфера відповідності може залишатися обмеженою. Якщо Adgora зберігає щось більше, ніж токен, це вже інша розмова.

Сценарій 5: змішані системи. Маркетинг працює в Adgora, оформлення замовлення — десь інде, а служба підтримки бачить деталі замовлень. Саме в таких змішаних схемах і трапляються помилки. Панель підтримки, яка навіть на короткий час показує повні номери карток, може втягнути весь цей набір інструментів у PCI-сферу.

Що запитати у підтримки або служби комплаєнсу, перш ніж покладатися на Adgora

Ставте точні запитання. «Чи зберігає, обробляє або передає Adgora дані власника картки?» — краще, ніж просто «Це безпечно?». Запитайте, чи входить Adgora до PCI-сфери, і якщо так, то для яких саме сервісів або компонентів.

Запитайте, який SAQ застосовується до вашої схеми. Якщо представник не може назвати ймовірний тип SAQ, це не доводить наявність проблеми, але означає, що вам потрібно більше деталей. Також запитайте, чи проходять дані картки через сервери Adgora, журнали, аналітичні інструменти або тікети підтримки.

Попросіть письмові докази. Підтвердження PCI від процесора, сторінка безпеки, заява про сферу відповідальності або лист від постачальника можуть бути достатніми, щоб прояснити схему. Якщо вам не можуть надати доказів, вважайте це сигналом ризику.

Також варто запитати, чи підтримує Adgora лише хостингове оформлення замовлення, вбудовані компоненти або обидва варіанти. Ці три моделі мають різні наслідки. Одна письмова відповідь може вберегти від дорогої помилки в майбутньому.

Якщо вашій команді потрібен контекст по каналах, стаття про гайд із варіантів таргетингу в крипторекламній мережі допоможе зрозуміти, як налаштування аудиторії та налаштування платежів залишаються окремими речами. Суть у тому, щоб не змішувати рекламний таргетинг із роботою з карткою. Це різні контролі.

Якщо документація незрозуміла

Якщо документи розмиті, вважайте, що продавець усе ще несе зобов’язання щодо PCI, доки письмове підтвердження не скаже інакше. Це найбезпечніша базова позиція. Мовчання — не контроль безпеки.

Попросіть у Adgora або в платіжного процесора актуальну письмову заяву з описом того, хто обробляє дані картки, де саме це відбувається і яка сторона зберігає докази відповідності PCI. Якщо у відповідь ви отримуєте лише маркетингові формулювання, продовжуйте ставити запитання.

Для складних схем залучіть фахівця з платіжної безпеки. Короткий перегляд від людини, яка добре розуміє PCI scope, може коштувати менше, ніж виправлення помилково визначеної платіжної схеми пізніше. Це особливо актуально, якщо ваша checkout-система, служба підтримки та CRM працюють із одним і тим самим записом клієнта.

Ще одна практична перевірка не завадить: перегляньте журнали, вебхуки та експорти з підтримки на предмет полів із даними картки. Іноді сам checkout чистий, але інша система зберігає те, чого зберігати не повинна. Одна така помилка може рознести дані картки по 3 чи 4 інструментах, перш ніж хтось це помітить.

Якщо хочете поєднати це з ширшим оглядом платформи, стаття огляд крипторекламної мережі може допомогти відокремити заяви про продукт від операційних фактів. Але щодо карткових платежів остаточна відповідь завжди приходить через платіжний шлях, процесора та письмові PCI-докази.