Чому важливо використовувати оригінальні платіжні форми
Платіжна форма - це точка, де користувач вводить найчутливіші дані: номер карти, CVC, логіни гаманців. Якщо форма неоригінальна (підроблений сайт, «самописне» поле картки у мерчанта замість хостед-форми провайдера, зламана інтеграція), ви ризикуєте витоком даних, відмовами банку, chargeback-ами і блокуваннями. Оригінальна форма - це сторінка/віджет платіжного провайдера (PSP/банку), що пройшла сертифікацію безпеки і підключена за коректним сценарієм (iFrame/Hosted Fields/редирект).
Що таке «оригінальна платіжна форма»
Хостед у PSP: поля PAN/CVC/терміну - всередині iFrame/Hosted Fields провайдера або на його домені (редирект).
Відповідає PCI DSS: мерчант не бачить і не зберігає «сирі» дані карти, отримує тільки токен.
Підтримує SCA/3-D Secure 2: підтвердження платежу через банк (push/SMS/біометрія).
Захищена протоколами: строгий TLS, HSTS, CSP, захист від clickjacking.
Ідентифікується: коректний домен/сертифікат і передбачуваний UX з реквізитами мерчанта.
Чому це критично (для користувача і бізнесу)
Для користувача
Захист карткових даних: токенізація та ізоляція полів карти виключають «підглядання» мерчантом і скриптами.
Менше фішингу і крадіжці акаунта: ім'я одержувача і 3-DS2 підтверджують платіж саме вашому банку.
Вище шанси успішної оплати: коректна інтеграція = менше технічних відмов.
Для бізнесу
Комплаєнс і менші штрафи: відповідність PCI DSS знижує відповідальність і вартість аудиту.
Менше chargeback-ів: 3-DS2 переносить відповідальність на емітента при суперечці.
Більше конверсії: швидкий SCA, Apple/Google Pay, збережені токени для one-click.
Захист бренду: відсутність «формджекінгу» (вбудовування шкідливих скриптів) і витоків.
Як повинна виглядати коректна інтеграція
1. Редирект на домен PSP або Hosted Fields/iFrame всередині сторінки мерчанта.
2. Поля карти (PAN/CVC/expiry) технічно належать провайдеру - мерчант отримує токен.
3. SCA/3-DS 2 запускається автоматично: пуш в додаток банку, біометрія, SMS-код.
4. Захисту на рівні сторінки: HSTS, Content Security Policy (CSP), X-Frame-Options, nonce/хеші для скриптів.
5. Чистий UX: єдиний шрифт/верстка або фірмовий віджет PSP, коректний descriptor торговця.
Чим небезпечні неоригінальні форми
Формджекінг (Magecart): шкідливі JS знімають PAN/CVC «на льоту».
Фішинг/підміна домену: схожі URL, підроблені логотипи, «замок» сам по собі нічого не гарантує.
Недотримання PCI: штрафи, обов'язкові аудити, блокування еквайрингу.
Відмови та утримання: емітенти ріжуть «сірі» інтеграції, більше «Don't honor».
Витоки KYC: запит «фото картки з обох сторін» і паспорта по e-mail - грубе порушення.
Ознаки оригінальної форми (для користувача)
Поля карти знаходяться у вбудованому iFrame (курсор і рамка «всередині» маленького вікна) або ви потрапляєте на домен відомого PSP/банку.
Адресний рядок: HTTPS, валідний сертифікат, правильний домен без помилок.
3-D Secure/SCA з'являється автоматично (пуш/SMS/біометрія з вашого банку).
Немає запитів надіслати PAN/CVC/фото карти в чат/пошту.
Політика конфіденційності та умови оплати відкриваються і читабельні.
Червоні прапори (відразу стоп)
Поля карти безпосередньо на сайті мерчанта без iFrame/Hosted Fields.
Просять PAN/CVC по e-mail/месенджеру або «фото карти з обох сторін».
Домен дивний: `pay-secure. shop-brand-verify. net'замість домену бренду/PSP.
Сторінка тягне несекьюрні ресурси (http) на кроці оплати або «лається» на сертифікат.
Зламана локалізація, піксельні логотипи, орфошибки, таймери "плати за 2:59».
Чек-лист для користувача (1 хвилина)
- Оплата йде через редирект на PSP або iFrame/Hosted Fields.
- HTTPS/сертифікат валідни, домен без підмін.
- SCA/3-DS2 спрацював (пуш/SMS/біометрія).
- Не відправляю PAN/CVC/фото карти в чат/пошту.
- Політика конфіденційності та контакти підтримки в наявності.
Чек-лист для бізнесу (інтеграція/безпека)
- Використовую Hosted Fields/iFrame або редирект PSP; мерчант не бачить PAN/CVC.
- PCI DSS: SAQ A/SAQ A-EP за типом інтеграції, токенізація, сегментація мереж.
- CSP/HSTS/XFO включені; зовнішні скрипти - по allow-list з хешами/nonce.
- 3-DS 2/SCA включений; fallback на OTP/push; підтримка Wallets (Apple/Google Pay).
- Моніторинг змін фронту (SRI, канарські скрипти), захист від formjacking.
- Чіткі тексти: хто еквайєр/PSP, як обробляються дані, терміни повернень.
Регулярні пентести і контроль залежностей (SCA - Software Composition Analysis).
Типові проблеми і як їх вирішити швидко
FAQ (коротко)
Замок в адресному рядку = безпечно?
Ні, ні. Це лише шифрування. Дивіться на домен, хостед-форму, 3-DS2 і політику.
Чому iFrame краще полів на сайті?
Тому що PAN/CVC йдуть безпосередньо до PSP і не стосуються фронту мерчанта - менше ризиків і вимог PCI.
Чи можна брати дані карти по телефону/в чаті?
Ні, ні. Це грубе порушення PCI. Використовуйте платіжне посилання/інвойс з хостед-формою.
Якщо форма «висить» без SCA?
Перезавантажте, перевірте мережу/браузер. Переконайтеся, що не блокуєте спливаючі вікна/скрипти PSP.
Міні-політика для компанії (готовий каркас)
1. Тільки Hosted Fields/редирект для PAN/CVC.
2. 3-DS 2/SCA обов'язковий для карт; підключені Apple/Google Pay.
3. CSP/HSTS/XFO/SRI + строгий allow-list доменів.
4. Моніторинг фронту та алерти на підміну скриптів.
5. SAQ/аудит PCI щорічно; пентести за розкладом.
6. Саппорт ніколи не запитує PAN/CVC/фото карти; тільки захищені KYC-канали.
Оригінальна платіжна форма - це не естетика, а безпека і законність. Хостед-поля, токенізація і SCA захищають власника карти, підвищують конверсію і знімають з бізнесу значну частину ризиків. Користувачеві - перевіряти домен, форму і SCA; бізнесу - використовувати тільки сертифіковані інтеграції з жорсткими захистами фронту. Дотримуючись цих правил, ви закриваєте 90% сценаріїв витоку даних і платіжних відмов.