Контекст

PCI DSS (Payment Card Industry Data Security Standard) — набор требований безопасности, обязательных для всех организаций, которые хранят, обрабатывают или передают данные платёжных карт. QA-инженер в финтехе не просто проверяет функциональность — он является последней линией обороны перед релизом, гарантируя, что чувствительные карточные данные нигде не утекают и не хранятся в открытом виде.

PAN (Primary Account Number) — номер карты — должен маскироваться везде вне защищённого хранилища: отображаться как **** **** **** 4242.
CVV/CVC нельзя хранить после авторизации транзакции ни в базе данных, ни в логах, ни в кеше.
Передача карточных данных должна происходить только по TLS 1.2 или выше; HTTP-соединения недопустимы для cardholder data environment (CDE).
Логи приложения, серверов и сетевого оборудования — первое место, где карточные данные появляются случайно при отладке.
Scope тестирования по PCI DSS охватывает все системы, которые соприкасаются с CDE: платёжный шлюз, сервис уведомлений, API Gateway, базы данных.
Токенизация (Stripe, Braintree) выводит большинство систем из scope: QA проверяет, что реальный PAN никогда не достигает серверов компании.

Рабочий алгоритм

При тестировании любого платёжного флоу пройдите следующие шаги, чтобы убедиться в соответствии PCI DSS:

Выполните платёжную операцию в тестовой среде с карточными данными из официального набора test-карт (Stripe: 4242 4242 4242 4242).
Немедленно проверьте логи приложения (stdout, файловые логи, ELK/Splunk): ищите паттерны 4[0-9]{12,15} — наличие совпадений это баг P0.
Откройте DevTools → Network: убедитесь, что в теле запросов и ответов PAN не передаётся в открытом виде на фронтенде; допустим только token или masked PAN.
Проверьте запись в базе данных: поле card_number должно содержать маску или токен, поле cvv должно отсутствовать или быть null.
Убедитесь, что соединение с платёжным шлюзом использует TLS ≥ 1.2: проверьте через curl -v или SSLyze.
Задокументируйте результат каждого шага в артефакте тест-rana для аудита: скриншоты, фрагменты логов с маскированными данными.

Пример из практики

Команда выкатила новую фичу — детальный лог ошибок оплаты для службы поддержки. Тестировщик провёл платёж тест-картой 4111 1111 1111 1111 и сразу открыл Kibana. В поле message он нашёл строку: 'Payment failed for card 4111111111111111, CVV 123, exp 12/26'. Это критический баг: PAN и CVV попали в логи в открытом виде. Тестировщик заблокировал деплой, завёл баг с severity Critical и приложил маскированный скриншот (номер карты замазан). Разработчик исправил логирование так, чтобы выводился только токен и последние 4 цифры. После фикса тестировщик повторил сценарий и подтвердил, что в логах теперь отображается только 'card token: tok_abc123, last4: 1111'.

Частые ошибки

QA-инженеры, впервые работающие с платёжными системами, регулярно допускают следующие ошибки:

Проверяют только UI, не заглядывая в логи и базу данных — именно там чаще всего оседают карточные данные.
Используют реальные карточные данные в тестовой среде: это нарушение PCI DSS само по себе, даже если транзакция не проходит.
Считают маскированный PAN (•••• 4242) в логах допустимым — маскирование должно производиться до попадания в лог, а не постфактум в UI.
Пропускают проверку TLS-версии, ограничиваясь тем, что адрес начинается на https://.
Не документируют прохождение PCI-чеклиста: для аудита нужны доказательства, а не только факт зелёного билда.

✅ Самопроверка

1После платёжной транзакции QA-инженер находит в логах строку 'card=4111111111111111'. Как правильно классифицировать эту находку и какие немедленные действия нужно предпринять?

Это баг с severity Critical (или P0): PAN попал в лог в открытом виде — прямое нарушение PCI DSS требования 3.3. Нужно немедленно заблокировать деплой или инициировать откат, завести баг-репорт со скриншотом (PAN маскируется в самом репорте), уведомить команду безопасности и зафиксировать инцидент согласно внутренним процедурам.