Якщо ви створюєте власний інструмент, який працює з платежами, хто несе комплаєнс-ризик?
Сертифікат PCI вашого платіжного провайдера не переходить до вас автоматично. Розповідаємо, хто насправді несе комплаєнс-ризик, коли самостійно розроблений інструмент працює з платежами, та яка архітектура дозволяє вивести кастомні рішення за межі аудиту.
Ви. Не штучний інтелект, який згенерував код, не ваш хостинг-провайдер і не ваш платіжний провайдер. Щощойно створений вами інструмент торкається платежів, комплаєнс-ризик лягає на ваш бізнес, і він залишається там незалежно від того, скільки сертифікованих підрядників ви підключите. Що ви можете змінити, так це розмір цього ризику, а різниця між добре спроектованим кастомним інструментом і недбало створеним — величезна.
Чому ризик лягає на вас, а не на ваших підрядників?
Прийом карток працює на основі ланцюжка договорів. Карткові платіжні системи встановлюють правила, ваш еквайр (банк, який здійснює розрахунки за картковими продажами) забезпечує їх виконання, а ваша угода про торгівельний еквайринг передає ці зобов'язання вам. Зводом правил є PCI DSS — стандарт безпеки даних індустрії платіжних карток, і він застосовується до будь-якого бізнесу, який зберігає, обробляє або передає дані власників карток (номери карток та пов'язані з ними реквізити). Поточна версія — 4.0.1. (Номери версій та деталі програми є точними на момент публікації; сприймайте ці дані як зріз інформації на поточний момент.)
Ваші підрядники несуть зобов'язання щодо власних систем, і відповідність вашого платіжного провайдера вимогам безпеки суттєво зменшує вашу частку роботи. Але жодні дії підрядника не перекладають відповідальність. Рада зі стандартів безпеки PCI чітко зазначає, що необхідність підтвердження відповідності визначається картковими брендами та вашим еквайром, і їхня відповідь, прописана у вашому договорі еквайрингу, — так. Щороку хтось у вашій компанії підписує лист про відповідність (attestation of compliance), підтверджуючи, що ваше середовище відповідає стандарту. Цей підпис належить вам, а не вашому підряднику.
Що змінюється, щойно ваш власний код починає торкатися даних карток?
Сфера застосування (Scope). Складність комплаєнсу вимірюється обсягом цієї сфери: кожна система, яка торкається даних власників карток, а також усе, що до неї підключено, підпадає під дію стандарту.
Торговець, чиї платежі повністю обробляються сертифікованим провайдером та його сертифікованими пристроями, підтверджує відповідність за допомогою короткого опитувальника самооцінки (щорічного чек-листа), який містить кілька десятків запитань. Торговець, чиє власне програмне забезпечення обробляє номери карток, потрапляє до найсуворішої категорії, яка фактично дублює більшу частину повного стандарту: понад двісті вимог, що включають щоквартальне сканування вразливостей, тестування на проникнення, контроль доступу, ведення журналів подій та офіційні політики безпеки¹.
Та форма оплати, яку штучний інтелект написав для вас за пів дня? Якщо вона приймає номери карток, ваш вебсервер, база даних, адміністративний ноутбук і Wi-Fi у магазині — усе це стає кандидатами на включення до сфери аудиту. І ви не зможете тихцем подати короткий опитувальник. Вибір категорії, під яку ви не підпадаєте, не зменшує ваш ризик; це означає, що підписаний вами документ є недостовірним, що зазвичай випливає на поверхню в найгірший момент — одразу після витоку даних.
Скільки насправді коштує помилка?
Забезпечення дотримання правил має договірний характер, тому штрафи зазвичай з'являються у вашій виписці за еквайринг. Багато процесингових центрів нараховують щомісячну комісію за невідповідність вимогам, доки ви не підтвердите відповідність. Після витоку даних витрати накопичуються: обов'язкове розслідування інциденту, яке оплачуєте ви, витрати на перевипуск карток та зростаючі штрафи, що передаються через вашого еквайра (зазвичай вони становлять від 5 000 до 100 000 доларів США на місяць відповідно до тарифів штрафів, опублікованих асесорами з відповідності PCI). У серйозних випадках бізнес може взагалі втратити можливість приймати картки.
Для малого бізнесу найважчий тягар є менш помітним, ніж будь-який штраф: підтримка реальної програми безпеки вимагає часу, який ви планували витратити на розвиток бізнесу.
Як створювати кастомні інструменти, не потрапляючи під сферу аудиту даних карток?
Тримайте свій код подалі від шляху проходження карткових даних. Ваш кастомний інструмент має лише координувати продаж: формувати кошик, застосовувати знижки, підраховувати суму замовлення та надсилати суму до оплати. Сама ж картка має взаємодіяти виключно з сертифікованим терміналом (платіжним обладнанням, перевіреним для роботи з картками) або платіжною сторінкою вашого провайдера, які передають дані безпосередньо платіжному процесору (компанії, що переказує гроші). Ваш інструмент отримує лише результат (схвалено чи відхилено) та токен (ідентифікатор, який не має жодної цінності для зловмисників у разі крадіжки).
Цей поділ є головним аргументом на користь headless POS-архітектури: кастомні екрани зверху, сертифікована платіжна інфраструктура знизу. Саме тому створені ШІ форми оплати чудово виглядають на демо, але не працюють у реальних умовах, і саме тому вебформа є неправильним рішенням для дебетових транзакцій із фізичною карткою, таких як Interac: особисті платежі мають здійснюватися на сертифікованому обладнанні як з технічної, так і з договірної точки зору.
Final побудовано саме навколо цієї межі. Створювані вами процеси (flows), незалежно від того, чи налаштовуєте ви їх самостійно, чи підключаєте власний ШІ через MCP, керують екранами, кошиками та каталогами. Дані карток передаються із сертифікованого терміналу платіжному процесору через Final Pay і ніколи не потрапляють у створений вами процес. Кастомні рішення там, де це безпечно, стандартизовані — там, де лежить відповідальність.
Тож хто несе комплаєнс-ризик?
Ви, і так буде завжди. Справжнє рішення полягає в тому, який обсяг сфери аудиту ви берете на себе, і це вибір архітектури, а не паперів. Перш ніж запускати інструмент, який працює з платежами, поставте одне запитання: чи може мій код колись побачити номер картки? Якщо так, то програму комплаєнсу доведеться вести вам. Якщо ні, ви зберігаєте гнучкість кастомного рішення з мінімальним навантаженням. Якщо ви зараз розглядаєте такий варіант розробки, почніть із ознак того, що ви переросли свою готову POS-систему.
Поширені запитання
Чи робить використання сумісного з PCI платіжного провайдера ваш бізнес відповідним вимогам?
Ні. Провайдер, який відповідає вимогам, зменшує обсяг вашої роботи, але ваш бізнес усе одно щороку підтверджує власну відповідність вимогам через договір еквайрингу. Відповідальність ніколи не переходить на постачальника.
Яка різниця між SAQ A та SAQ D?
Обидва документи є опитувальниками для самооцінки (SAQ) відповідно до стандарту PCI DSS. Найпростіші рівні застосовуються, коли обробка платежів повністю передана сумісному провайдеру та сертифікованому обладнанню. SAQ D застосовується, коли ваші власні системи обробляють дані власників карток, і він дублює більшість вимог повного стандарту, включаючи сканування, тестування та офіційні політики.
Чи змінює згенерований ШІ код мої зобов'язання щодо PCI?
Ні. Для стандарту важливо, які саме системи взаємодіють із даними власників карток, а не те, хто чи що написало код. Згенероване ШІ оформлення замовлення, яке приймає номери карток, повністю вводить ваші системи в область дії стандарту, так само як і написаний вручну код.
Чи дійсно малий бізнес можуть покарати за невідповідність вимогам PCI?
Так, хоча зазвичай це відбувається у вигляді щомісячної комісії за невідповідність вимогам від вашого платіжного процесора, а не гучного штрафу в новинах. Великі стягнення зазвичай накладаються після витоку даних, разом із витратами на технічне розслідування та перевипуск карток.
Що таке токенізація?
Заміна номера картки на референтний токен, який є марним за межами платіжної системи, що його випустила. Ваші інструменти можуть зберігати та використовувати токен для повернення коштів або повторного виставлення рахунків, ніколи не зберігаючи реальних даних картки.