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

Відповідність PCI (правила безпеки індустрії платіжних карток для всіх, хто обробляє дані карток) — це ціна слів "приймаємо кредитні картки". Коротка версія: якщо дані карток бодай колись торкаються написаного вами коду або серверів, якими ви керуєте, ви успадковуєте стандарт безпеки з сотнями вимог контролю, щорічною атестацією (офіційно підписаною декларацією про відповідність стандарту) та наслідками, що застосовуються через вашого платіжного провайдера. Болюча версія відповідності PCI для розробників додатків: більшість дізнається про це вже після того, як оформлення замовлення побудовано.

Зауваження перед тим, як перейти до деталей. Номери версій, дати та правила опитувальників, наведені нижче, є актуальними на момент публікації; стандарт змінюється, тому сприймайте деталі як зріз на певний момент.

Що таке відповідність PCI насправді?

PCI DSS (Payment Card Industry Data Security Standard) — це договірне зобов'язання, а не закон. Карткові системи накладають його на банки та платіжні провайдери, а ті — на продавців і програмне забезпечення, яке ці продавці використовують. Поточна версія — 4.0.1, і остання хвиля її нових вимог стала обов'язковою 31 березня 2025 року¹. Стандарт охоплює 12 сімейств вимог — від мережевої безпеки та шифрування до контролю доступу та ведення логів, які розгортаються у сотні окремих пунктів контролю².

Жоден регулятор не прийде до ваших дверей. Наслідки настають через комерційні важелі: штрафи, передані через ваш банк-еквайр (банк, який здійснює розрахунки за картковими платежами для продавця), вищі комісії за еквайринг, а у найгіршому випадку — втрата можливості приймати картки взагалі. У разі витоку даних витрати на криміналістичне розслідування та перевипуск карток йдуть тим самим шляхом.

Чому фраза "просто додайте платежі" залучає весь ваш додаток у сферу застосування стандарту?

Сфера застосування (scope) — це найголовніше. PCI DSS застосовується до кожної системи, яка зберігає, обробляє або передає дані власників карток, а також до всього, що підключено до цих систем. Перевірка відповідності працює як драбина, і кожна наступна сходинка суттєво важча за попередню²:

• SAQ A (Self-Assessment Questionnaire A, опитувальник самооцінки A): платежі повністю аутсорсяться сертифікованому провайдеру, і дані карток ніколи не торкаються ваших систем. Найкоротший опитувальник.

• SAQ A-EP: ваш сайт ніколи не торкається даних карток, але контролює, як клієнти потрапляють на форму оплати. Значна частина повного стандарту тепер застосовується до ваших вебсерверів.

• SAQ D: дані карток проходять через будь-що створене вами, навіть короткочасно, навіть без збереження. Фактично увесь стандарт, який документується та атестується щороку.

Найнижча сходинка — це також не "нічого". У січні 2025 року PCI Security Standards Council вилучив вимоги щодо скриптів сторінки оплати з SAQ A, але додав умову відповідності: ви повинні підтвердити, що ваш сайт не є вразливим до скриптових атак, які можуть вплинути на систему електронної комерції¹. Навіть рівень з повним аутсорсингом вимагає захисту сторінки, на якій розміщена чужа форма оплати.

Якщо кількість карткових транзакцій перевищує шість мільйонів на рік, самооцінка повністю припиняється і починається аудит на місці, який проводить QSA (сертифікований зовнішній аудитор)².

Чи можна обійти платежі за наявності картки за допомогою коду?

Ні. Офлайн-платежі — це те місце, де драбина перетворюється на стіну. Транзакції за наявності картки вимагають сертифікованого обладнання: фізичних зчитувачів, які пройшли лабораторну програму Ради PTS, працюють на схваленому прошивному забезпеченні та налаштовані через платіжного провайдера. Перетворення телефону на зчитувач лише за допомогою програмного забезпечення підпадає під окремий стандарт Mobile Payments on COTS (MPoC), і він сертифікує провайдера рішення, а не вашу збірку.

Це межа, яку генерація коду за допомогою ШІ не може подолати. Модель може створити переконливий екран оформлення замовлення за день; статті Чи можна побудувати POS за допомогою Lovable або Replit? та Вайб-кодинг точки продажу показують, де такі збірки зупиняються. Жоден згенерований код не створить сертифікований зчитувач, договір еквайрингу або атестат відповідності, незалежно від того, як довго модель кодить без нагляду. Відповідність вимогам також є постійною причиною, чому платіжні додатки, написані на вайб-кодингу, відхиляються з App Store.

Як розробникам реально зменшити сферу застосування PCI?

Ви не намагаєтеся дотримуватися вимог «сильніше» — ви будуєте архітектуру так, щоб об'єктів для дотримання вимог було менше:

• Ніколи не дозволяйте PAN (основному номеру рахунку, тобто самому номеру картки) торкатися вашого коду. Використовуйте хостовані платіжні поля вашого провайдера, щоб дані картки передавалися з браузера клієнта безпосередньо провайдеру.

• Зберігайте токени, а не картки. Токенізація (заміна номера картки на референсний рядок, який є марним у разі викрадення) заважає збереженим карткам та поверненням коштів затягнути вашу базу даних у сферу застосування PCI.

• Для офлайн-продажів використовуйте сертифіковані зчитувачі від вашого провайдера, щоб дані карток передавалися зі зчитувача провайдеру без проходження через ваш додаток.

• Зробіть сторінку оплати максимально простою. Кожен сторонній скрипт на ній стає чимось, за що вам доведеться звітувати.

Тож наскільки болючою є відповідність PCI для розробників додатків?

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

Саме так цю архітектуру реалізовано й у Final. Оформлення замовлення, побудоване на Final, незалежно від того, чи створене воно через запит у Build, чи побудоване вашим власним ШІ через MCP, проводитиме платежі через Final Pay: платіжний провайдер та сертифіковане термінальне обладнання обробляють дані карток, тому сам сценарій ніколи не володіє номером картки. Стаття Де доступний Final Pay висвітлює практичний бік, а Підключення Tap to Pay до сценарію AI POS показує, як виглядає прийом карток, коли рівень відповідності вимогам уже лежить в основі.