PCI DSS і некостодіальні криптошлюзи

Спочатку критерії PCI DSS: що вважається витоком карткових даних

PCI DSS починається з простого питання: чи торкається платіжний потік даних власника картки? Якщо ні, PCI DSS може взагалі не стосуватися цього потоку. Якщо так, обсяг вимог може швидко зрости — навіть через один API-виклик або один запит у службу підтримки.

Тут ключовим є саме поняття карткових даних. Зазвичай це номер основного рахунку, або PAN, а також пов’язані чутливі автентифікаційні дані, наприклад CVV. Потік, який зберігає, передає або може вплинути на безпеку цих даних, — саме той тип потоку, який цікавить PCI DSS.

Кастодіальність криптовалюти тут не є вирішальним фактором. Некостодіальний криптоплатіжний шлюз усе одно може бути поруч із картковими даними у ширшому стеку оформлення замовлення, і це одразу змінює картину. Саме тому питання "чи потрібен PCI DSS для криптошлюзу" має сенс лише тоді, коли зрозуміло, чи торкається цей стек карткових даних. Слово «некостодіальний» звучить як остаточний аргумент. Але це не так.

Для продавця це важливо, бо одна платіжна сторінка може приховувати дві дуже різні дії. Криптоінвойс може взагалі не бачити номера картки. Кнопка резервного варіанта оплати карткою на тій самій сторінці може змінити картину відповідності за один крок, і саме тоді треба думати про те, коли checkout підпадає під PCI DSS.

Порівняння поруч: некостодіальний криптошлюз і обробка карткових даних

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

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

Гібридне оформлення замовлення — звична річ. Магазин може пропонувати USDC на checkout і поруч опцію оплати карткою, бо клієнтам потрібен вибір або фінансовому відділу важливо зменшити кількість невдалих замовлень. Щойно з’являється картковий шлях, питання PCI потрібно ставити для всього середовища, а не лише для крипточастини.

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

Вирішальна межа: лише криптоплатіж, без збору карткових даних

Ось сценарій, який насправді потрібен багатьом продавцям. Шлюз лише створює криптоадресу, визначає блокчейн-платіж, підписує webhook-и та позначає замовлення як оплачене. Жодного PAN. Жодного CVV. Жодної карткової форми. У такому налаштуванні некостодіальний криптоплатіжний шлюз є некостодіальним криптоплатіжним шлюзом, а PCI DSS стосується його лише тоді, коли карткові дані з’являються десь ще у потоці.

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

Уявімо магазин цифрових товарів, який приймає 0,05 BTC або 120 USDT за замовлення. Шлюз підтверджує оплату в блокчейні, замовлення розблоковується, а клієнт жодного разу не вводить номер картки. Для PCI DSS у цій конкретній операції немає що перевіряти.

Втім, не забувайте про навколишні системи. Продавець може використовувати одну й ту саму адмінпанель для криптозамовлень і карткових замовлень, і така спільна панель може стати релевантною, якщо в ній є карткові дані або звіти, пов’язані з картками. Одна панель може нести дві історії відповідності.

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

Прихований тригер PCI: hosted checkout, вбудовані карткові поля та редиректи

Сфера PCI часто з’являється через фронтенд, а не через бекенд. Hosted checkout-сторінка може збирати карткові дані. Так само це можуть робити вбудовані карткові поля, JavaScript-бібліотеки, віджети редиректу, сервіси токенізації і навіть чат або інструменти підтримки, які бачать те, що вводить клієнт.

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

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

До браузерних скриптів треба ставитися особливо обережно. Платіжна бібліотека, що завантажується на сторінці, може бачити більше, ніж планував продавець, якщо її не контролювати жорстко. Саме тому продавцям варто перевіряти будь-який hosted checkout, iframe або клієнтський скрипт, перш ніж вважати, що криптосередовище лишається окремим.

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

Продавець чи оператор шлюзу: чия це відповідальність за PCI?

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

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

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

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

Для продавців, які працюють на WordPress, архітектура checkout заслуговує окремого перегляду. Стаття про прийом криптоплатежів на WordPress може допомогти, коли сайту потрібна логіка криптооплати без зайвого залучення карткових даних у той самий стек плагінів.

Операційні контролі, важливі, якщо карткові дані десь поруч із потоком

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

Логи мають значення, але вони можуть стати ризиком, якщо випадково захоплюють PAN або CVV. Правила безпечної розробки повинні це блокувати. Маскування, редагування та валідація введення — не «приємні бонуси», а різниця між чистим аудиторським слідом і інцидентом відповідності.

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

По можливості тримайте карткові дані поза системами продавця. Один цей принцип зменшує навантаження PCI більше, ніж майже будь-що інше. Hosted card page, яка ніколи не повертає номери карток продавцю, зазвичай простіша в управлінні, ніж саморобна форма, скопійована зі старого шаблону.

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

Чесний висновок: коли відповідь «ні», «можливо» або «так»

Для некостодіального шлюзу лише для криптовалюти відповідь зазвичай «ні» для цього потоку. Якщо шлюз ніколи не торкається даних власника картки, PCI DSS загалом не є релевантною рамкою саме для цього крипточек-ауту. Причина — у чіткому розділенні.

Для шлюзу, який поруч із картковим checkout або збереженими картковими даними, відповідь стає «можливо», а після перевірки архітектури часто переходить у «так». Точний scope залежить від того, де входять карткові дані, чи вони зберігаються, і чи може будь-яка система впливати на їхню безпеку. Одного вбудованого поля може бути достатньо.

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

Таке розділення важливе для планування, підбору команди та підготовки до аудиту. Команда може побудувати некостодіальний крипточек-аут і водночас нести відповідальність за PCI DSS в іншій продуктовій лінійці. Два платіжні методи. Два перегляди. Одна компанія.

Коротка таблиця рішень для продавців та інтеграторів

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

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

І ще один практичний момент: ставте те саме запитання до кожного плагіна, віджета й скрипта, який завантажується на платіжній сторінці. Три рядки JavaScript можуть мати більше значення, ніж тридцять рядків політики. Тримайте цю сторінку нудною. Зазвичай це найкращий варіант.