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

> Published: 2026-07-28
> Updated: 2026-07-28
> Author: Mathias Nielsen
> Category: POS
> Canonical: https://finalpos.com/uk/blog/pci

Якщо дані платіжних карток хоч колись торкаються написаного вами коду, ви отримуєте весь тягар PCI DSS. Ось драбина ескалації від SAQ A до SAQ D, чому для платежів за наявності картки потрібне сертифіковане обладнання та як будувати архітектуру, щоб нічого з цього на вас не впало.

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

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

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

PCI DSS (Payment Card Industry Data Security Standard) — це договірне зобов'язання, а не закон. Карткові системи накладають його на банки та платіжні провайдери, а ті — на продавців і програмне забезпечення, яке ці продавці використовують. Поточна версія — 4.0.1, і остання хвиля її нових вимог стала обов'язковою 31 березня 2025 року[¹](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a). Стандарт охоплює 12 сімейств вимог — від мережевої безпеки та шифрування до контролю доступу та ведення логів, які розгортаються у сотні окремих пунктів контролю[²](https://secureframe.com/blog/pci-saq).

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

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

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

- **SAQ A** (Self-Assessment Questionnaire A, опитувальник самооцінки A): платежі повністю аутсорсяться сертифікованому провайдеру, і дані карток ніколи не торкаються ваших систем. Найкоротший опитувальник.
- **SAQ A-EP**: ваш сайт ніколи не торкається даних карток, але контролює, як клієнти потрапляють на форму оплати. Значна частина повного стандарту тепер застосовується до ваших вебсерверів.
- **SAQ D**: дані карток проходять через будь-що створене вами, навіть короткочасно, навіть без збереження. Фактично увесь стандарт, який документується та атестується щороку.

![Стопка документів про відповідність із кредитною карткою нагорі, що символізує опитувальники самооцінки PCI DSS](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/0c4ed4b3d666d99c-pci-saq-paperwork-stack.png)

Найнижча сходинка — це також не "нічого". У січні 2025 року PCI Security Standards Council вилучив вимоги щодо скриптів сторінки оплати з SAQ A, але додав умову відповідності: ви повинні підтвердити, що ваш сайт не є вразливим до скриптових атак, які можуть вплинути на систему електронної комерції[¹](https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a). Навіть рівень з повним аутсорсингом вимагає захисту сторінки, на якій розміщена чужа форма оплати.

Якщо кількість карткових транзакцій перевищує шість мільйонів на рік, самооцінка повністю припиняється і починається аудит на місці, який проводить QSA (сертифікований зовнішній аудитор)[²](https://secureframe.com/blog/pci-saq).

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

Ні. Офлайн-платежі — це те місце, де драбина перетворюється на стіну. Транзакції за наявності картки вимагають сертифікованого обладнання: фізичних зчитувачів, які пройшли лабораторну програму Ради [PTS](https://www.pcisecuritystandards.org/standards/pts-point-of-interaction-poi/), працюють на схваленому прошивному забезпеченні та налаштовані через платіжного провайдера. Перетворення телефону на зчитувач лише за допомогою програмного забезпечення підпадає під окремий стандарт [Mobile Payments on COTS (MPoC)](https://www.pcisecuritystandards.org/standards/mobile-payments-on-cots-mpoc/), і він сертифікує провайдера рішення, а не вашу збірку.

![Сертифікований платіжний термінал без брендингу на прилавку магазину — апаратний рівень, якого PCI вимагає для платежів за наявності картки](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/0d02d9e5e5229253-certified-payment-terminal-counter.jpg)

Це межа, яку генерація коду за допомогою ШІ не може подолати. Модель може створити переконливий екран оформлення замовлення за день; статті [Чи можна побудувати POS за допомогою Lovable або Replit?](/blog/build-a-pos-with-lovable-or-replit) та [Вайб-кодинг точки продажу](/blog/vibe-coding-a-point-of-sale) показують, де такі збірки зупиняються. Жоден згенерований код не створить сертифікований зчитувач, договір еквайрингу або атестат відповідності, незалежно від того, [як довго модель кодить без нагляду](/blog/claude-opus-5-pos-more-than-code). Відповідність вимогам також є постійною причиною, чому [платіжні додатки, написані на вайб-кодингу, відхиляються з App Store](/blog/why-vibe-coded-payment-apps-get-rejected).

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

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

- Ніколи не дозволяйте PAN (основному номеру рахунку, тобто самому номеру картки) торкатися вашого коду. Використовуйте хостовані платіжні поля вашого провайдера, щоб дані картки передавалися з браузера клієнта безпосередньо провайдеру.
- Зберігайте токени, а не картки. Токенізація (заміна номера картки на референсний рядок, який є марним у разі викрадення) заважає збереженим карткам та поверненням коштів затягнути вашу базу даних у сферу застосування PCI.
- Для офлайн-продажів використовуйте сертифіковані зчитувачі від вашого провайдера, щоб дані карток передавалися зі зчитувача провайдеру без проходження через ваш додаток.
- Зробіть сторінку оплати максимально простою. Кожен сторонній скрипт на ній стає чимось, за що вам доведеться звітувати.

![Кредитна картка, запечатана у скляному футлярі, що символізує виведення даних карток із сфери застосування PCI](https://hy9joxwes0n0bta4.public.blob.vercel-storage.com/media/43399b6a-0d29-48b6-84dd-88ef01fcb193/generated/2630089c92683ed9-card-data-out-of-scope-glass-case.jpg)

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

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

Саме так цю архітектуру реалізовано й у Final. Оформлення замовлення, побудоване на Final, незалежно від того, чи створене воно через запит у Build, чи побудоване вашим власним ШІ через MCP, проводитиме платежі через Final Pay: платіжний провайдер та сертифіковане термінальне обладнання обробляють дані карток, тому сам сценарій ніколи не володіє номером картки. Стаття [Де доступний Final Pay](https://finalpos.com/help/where-final-pay-is-available) висвітлює практичний бік, а [Підключення Tap to Pay до сценарію AI POS](/blog/connecting-tap-to-pay-to-an-ai-pos-flow) показує, як виглядає прийом карток, коли рівень відповідності вимогам уже лежить в основі.

## FAQ

**Q: Чи є відповідність PCI юридичною вимогою?**
A: Ні. PCI DSS — це договірне зобов'язання, яке накладається картковими системами через банки та платіжні провайдери. Наслідки є комерційними: штрафи від вашого банку-еквайра, вищі комісії за обробку або втрата можливості приймати картки.

**Q: Чи знімає повний аутсорсинг платежів зобов'язання щодо PCI?**
A: Ні. Продавці з повним аутсорсингом можуть підтверджувати відповідність за допомогою SAQ A (найкоротшого опитувальника), але починаючи з нової редакції січня 2025 року вони також повинні підтвердити, що їхній сайт не вразливий до скриптових атак, які можуть вплинути на систему електронної комерції.

**Q: Яка різниця між SAQ A та SAQ D?**
A: SAQ A застосовується, коли сертифікована третя сторона обробляє всі дані карток, і охоплює невелику частину стандарту. SAQ D застосовується, коли дані карток торкаються ваших власних систем, і охоплює фактично весь стандарт із щорічним підтвердженням.

**Q: Чи може додаток, згенерований ШІ, відповідати вимогам PCI?**
A: Код може відповідати шаблонам безпеки, але відповідність вимогам прив'язана до бізнесу та його інфраструктури: сертифікованих зчитувачів карток, угоди з провайдером та щорічної атестації. Жоден згенерований код не надає цих компонентів.

**Q: Яка версія PCI DSS є актуальною?**
A: PCI DSS 4.0.1 станом на момент публікації цієї статті. Її останні вимоги з майбутньою датою набрання чинності стали обов'язковими 31 березня 2025 року. Перевірте актуальний стан на сайті PCI Security Standards Council.