Безпечні онлайн-платежі: як працює захист даних у платіжних системах?

Онлайн-оплата давно стала звичкою. Але звичка не скасовує ризику: номер картки, CVV і ім’я власника — це не «просто поля форми», а ключ до чужих грошей. Коли покупець натискає «Оплатити», дані не летять у відкритий інтернет як листівка. Їх шифрують, підміняють токеном, перевіряють антифродом і, за потреби, просять підтвердження в банку. Саме тому платіжна система з захистом даних Tranzzo будує процес так, щоб повний номер картки майже не затримувався на стороні магазину. Питання не в тому, чи безпечно платити взагалі. Питання в тому, хто тримає ці дані і за якими правилами.

Що саме захищають і чому «просто HTTPS» вже мало

HTTPS — це лише конверт. Він не дає відповіді, хто відкриє лист і куди його покладуть. У карткових платежах діє PCI DSS: стандарт індустрії, який описує, як зберігати, шифрувати і передавати дані картки. Найвищий рівень — PCI DSS Level 1. Його підтверджують аудитом щороку. Якщо магазин збирає номер картки на власній сторінці, сертифікат потрібен і йому. Якщо дані одразу йдуть у віджет або hosted-форму шлюзу, тягар сертифікації лягає на провайдера.

Токенізація працює простіше, ніж звучить. Замість «4111 1111 1111 1111» система зберігає випадковий рядок. Цим рядком можна повторити оплату, але вкрасти його — як украсти квиток у кіно без залу. Навіть якщо хтось зламає базу магазину, там не буде повного PAN. Visa Token Service і Mastercard MDES ідуть далі: токен оновлюється, коли банк перевипускає картку. Покупець не помічає цього. Магазин теж.

3-D Secure 2 додає ще один шар. Банк бачить не лише суму, а й пристрій, геолокацію, історію. Якщо ризик низький, підтвердження не питають — і конверсія не падає. Якщо щось дивне, клієнт підтверджує оплату в застосунку банку або кодом з SMS.

Як виглядає захист у реальному сценарії покупки

Уявіть інтернет-магазин одягу. Клієнт обирає куртку з телефону. Далі оплата в мобільному додатку не повинна відрізнятися від сайту за рівнем захисту: той самий HTTPS, той самий 3DS 2, той самий токен. SDK шлюзу вбудовує форму так, щоб магазин не бачив повний номер. Apple Pay і Google Pay взагалі не віддають PAN мерчанту — лише криптограму пристрою.

Антифрод дивиться не одним оком. Типові маркери такі:

різка зміна країни IP і країни банку-емітента;
кілька спроб з різними картками з одного пристрою за хвилини;
нічна покупка на велику суму з нового акаунта;
нетиповий BIN картки для цієї категорії товару.

У серйозних шлюзів таких правил сотні. Вони оновлюються, бо шахраї теж не сплять. Якщо правило спрацювало, платіж блокують або відправляють на 3DS. Магазин отримує статус, а не «тихий» chargeback через два тижні.

Що має перевірити покупець і продавець, перш ніж довіряти кнопці «Сплатити»

Покупцеві варто дивитися на дрібниці. Замок у адресному рядку. Знайомий домен, а не «pay-shop-ua.xyz». Підтвердження в банківському застосунку, а не лише «код на пошту невідомого сервісу». Якщо магазин просить надіслати фото картки в месенджер — це вже не оплата, а роздача ключів від квартири.

Продавцю список коротший і жорсткіший:

чи провайдер має актуальний PCI DSS Level 1 і чи публікує атестат;
чи є токенізація і hosted/віджет, щоб не тягнути сертифікацію на себе;
чи працює 3DS 2 з можливістю frictionless-потоку;
чи антифрод можна налаштувати під нішу, а не лише «ввімкнути галочку»;
чи підписи API йдуть через HMAC і чи обов’язковий HTTPS.

Без цього «швидка інтеграція за три години» легко перетворюється на витік і відмову банків.

Tranzzo: платіжний шлюз з 2017 року для сайту, додатка і месенджерів

Tranzzo працює на ринку онлайн-платежів з 2017 року як платіжний шлюз для бізнесу. Компанія пропонує інтернет-еквайринг, платіжну сторінку, лінки й QR, підписки, виплати на картки, програмний РРО, SDK для мобільних застосунків, Apple Pay і Google Pay, каскадування платежів і white-label для тих, хто сам хоче стати провайдером. Дані захищають за PCI DSS Level 1, HTTPS, GDPR і елементами PSD2; антифрод тримає понад 200 правил моніторингу в реальному часі, а карткові номери замінює токенами, зокрема VTS і MDES.

Цікава вона не гучними слоганами, а практичною зв’язкою: бізнес може не збирати чужі картки на своїй сторінці, не будувати власний антифрод з нуля і все одно приймати оплату на сайті, в месенджері чи в додатку. Для ніш від e-commerce до маркетплейсів і iGaming це означає менше роботи з сертифікацією і більше уваги до самого продукту — за умови, що інтеграцію роблять через API, віджет або SDK, а не «на око».