PCI DSS та безпека платежів

Найдорожча помилка в кар'єрі розробника

Розробник нового стартапу вирішує «зекономити час» та зберегти номери карток клієнтів у власній базі даних — без шифрування, для «майбутніх повторних покупок». Через рік стається витік. Компанія отримує штраф від Visa/Mastercard у розмірі від $50,000 до $500,000, втрачає право приймати картки та зазнає репутаційної катастрофи.

Це не гіпотетичний сценарій — це реальна модель покарання у платіжній індустрії. Стандарт PCI DSS (Payment Card Industry Data Security Standard) існує саме для того, щоб такі ситуації не виникали. І знаємо щось, що полегшить вашу відповідальність: більшість розробників ніколи не повинні бачити дані карток.

Що таке PCI DSS

PCI DSS (Payment Card Industry Data Security Standard) — це набір вимог безпеки, розроблених спільно Visa, Mastercard, American Express, Discover та JCB у рамках організації PCI Security Standards Council (PCI SSC). Стандарт застосовується до всіх організацій, які зберігають, обробляють або передають дані платіжних карток.

Поточна версія — PCI DSS 4.0 (вийшла у березні 2022 року, обов'язкова з березня 2024 року).

Стандарт складається з 12 основних вимог, згрупованих у 6 цілей:

Рівні відповідності (Compliance Levels)

Рівень відповідності визначається обсягом транзакцій на рік і впливає на те, який тип аудиту потрібен.

Більшість стартапів та середніх e-commerce проєктів потрапляють на рівень 4 — і саме для них найважливіший інструмент — SAQ (Self-Assessment Questionnaire).

Типи SAQ: яка форма потрібна вам

Принцип «Не торкайся даних карток»

Це найважливіший практичний принцип для розробників. Якщо ваш додаток ніколи не бачить PAN (номер картки), CVV, PIN — більшість вимог PCI DSS просто не застосовуються до вашого коду.

Три моделі інтеграції за рівнем ризику

Токенізація (Tokenization)

Токенізація — це заміна чутливих даних (номер картки) на непрозорий токен, який безпечно зберігати та передавати. Токен не містить математичного зв'язку з оригінальними даними, тому навіть при витоку токен марний для зловмисника.

Реальний PAN:  4111 1111 1111 1111
Токен:         tok_live_AbCxYzQ1r2s3t4u5...

PSP зберігають відповідність токен → PAN у власній захищеній системі Token Vault. Ви отримуєте токен і використовуєте його для:

• Повторних списань (рекурентні платежі)
• Відображення замасковного PAN користувачу (**** **** **** 1111)
• Скасування та повернень коштів

У вашій базі даних зберігається лише токен — НЕ картка. Це ключова різниця.

sequenceDiagram
    participant U as User
    participant S as Your Site (iframe)
    participant PSP as PSP Server
    participant DB as Your DB

    U->>S: Вводить картку в JS-форму
    Note over S: Дані НЕ йдуть на ваш сервер!
    S->>PSP: Пряма передача даних картки (TLS)
    PSP-->>S: token = "tok_live_AbC..."
    S->>DB: Зберегти token (НЕ PAN!)
    DB-->>S: OK
    Note over S,DB: Ваш код ніколи не бачив PAN

3-D Secure (3DS)

3-D Secure — протокол додаткової автентифікації власника картки. Назва «3-D» відображає трьох учасників: платіжну мережу, банк-емітент та банк-еквайрер.

Версії 3DS

3DS 1.0 (застарілий): завжди відображав додатковий екран підтвердження (SMS-код або карткова сторінка банку). Низька конверсія через погану UX.

3DS 2.x (EMV 3DS) (сучасний): використовує risk-based authentication (RBA). Банк-емітент аналізує десятки факторів ризику (пристрій, локація, сума, поведінка) та у більшості випадків підтверджує платіж без втручання користувача (frictionless flow).

Frictionless vs Challenge flow

Frictionless (80–90% транзакцій):
User → Cart → Pay → ✅ Done (без додаткових дій)

Challenge flow (10–20% транзакцій):
User → Cart → Pay → 📱 SMS/Push від банку → Підтвердження → ✅ Done

Реалізація: При інтеграції через PSP (LiqPay, Monobank, Stripe) — 3DS обробляється автоматично. Вам потрібно лише коректно обробити action_url від PSP, якщо emitted заклик на challenge.

Що можна і не можна зберігати в БД

Логування: що маскувати

Один з найпоширеніших векторів витоку — логи. Розробник додає _logger.LogInformation($"Payment request: {JsonSerializer.Serialize(request)}") — і дані картки потрапляють у файли логів.

Правило: Ніколи не логуйте об'єкти запитів до PSP без явного маскування.

public static string MaskSensitiveData(string json)
{
    // Маскуємо типові поля карткових даних
    return Regex.Replace(json,
        @"(""card_number""\s*:\s*"")(\d{6})\d+(\d{4})("")",
        "$1$2******$3$4");
}

Підсумок

PCI DSS — це не бюрократія, це система захисту, яка evolved під реальні загрози. Для більшості розробників ключовий висновок простий: делегуйте обробку карткових даних PSP через Hosted Page або Embedded JS Form (SAQ-A або SAQ-A-EP). Зберігайте лише токени, ніколи не логуйте реквізити. 3-D Secure 2.x позбавляє вас від відповідальності за chargeback і покращує безпеку з мінімальним впливом на конверсію.

Практичні завдання