Хранение полных данных карт (PAN) на своем сервере в 2024 году — это прямой путь к штрафам от 100 000 рублей до полной блокировки мерчанта банком-эквайером. Для SaaS-сервиса с рекуррентными платежами единственным легальным и безопасным способом управления подписками является токенизация, которая переносит ответственность за PCI DSS на сторону платежного шлюза.
PCI DSS: уровни комплаенса и риски SaaS
Стандарт PCI DSS (Payment Card Industry Data Security Standard) делит бизнес на четыре уровня (Levels) в зависимости от объема транзакций. Для большинства российских SaaS-проектов с оборотом до 6 млн транзакций в год актуален Level 4. Однако ошибка новичков — считать, что «малый бизнес не проверяют». При любой утечке данных или серии фрода банк-эквайер затребует отчет о соответствии (SAQ), и отсутствие которого ведет к мгновенному разрыву договора.
Кейс: SaaS-платформа для автоматизации маркетинга пыталась хранить зашифрованные номера карт в своей БД для «быстрого переезда между эквайерами». При аудите безопасности выяснилось, что ключи шифрования лежали в том же конфиге, что и доступ к БД. Итог: риск компрометации 15 000 карт и необходимость внедрения полной инфраструктуры PCI DSS, стоимость которой для среднего проекта стартует от 500 000 руб. за аудит и настройку.
Экспертный вывод: Никогда не касайтесь «сырых» данных карт. Любая попытка создать собственное хранилище PAN в SaaS-модели экономически нецелесообразна.
Механика токенизации для рекуррентных списаний
Токенизация заменяет чувствительные данные карты уникальным идентификатором — токеном. В схеме с рекуррентными платежами клиент один раз вводит данные через защищенную форму эквайера (iframe или redirect), а ваш сервер получает только токен. Этот токен бесполезен для злоумышленников, так как он привязан к конкретному мерчанту (Merchant ID) и работает только внутри системы конкретного банка.
Технический нюанс: существует «жесткая» и «мягкая» токенизация. При жесткой (Vault-based) токен хранится в защищенном хранилище банка бессрочно. При мягкой — срок жизни токена может быть ограничен (например, 1 год), после чего потребуется повторная авторизация клиента. Для SaaS с LTV более 12 месяцев критически важно использовать бессрочные токены, чтобы не провоцировать Churn rate из-за необходимости перепривязки карты.
Экспертный вывод: Выбирайте эквайринг, который предоставляет полноценный API для управления рекуррентными платежами через токены, чтобы минимизировать вмешательство пользователя в процесс оплаты.
Минимизация рисков: SAQ-A против SAQ-D
Степень вашей ответственности перед PCI DSS зависит от способа интеграции. Если вы используете Hosted Payment Page (редирект на страницу банка), вы заполняете опросник SAQ-A (минимум требований). Если же вы интегрируете форму оплаты прямо в интерфейс через API, передавая данные через свой сервер, вы попадаете под SAQ-D — самый жесткий уровень контроля, требующий ежеквартального сканирования сети и аудита кода.
Сравнение затрат на безопасность: внедрение SAQ-A обходится в 0 рублей, так как данные не проходят через ваш сервер. Переход на SAQ-D требует найма DevOps-инженера по безопасности (ЗП от 200 000 руб./мес) и закупки специализированного ПО для мониторинга трафика. Для 98% SaaS-проектов в РФ переход на SAQ-D не дает никаких преимуществ в конверсии, но кратно увеличивает риски.
Экспертный вывод: Используйте только методы интеграции, позволяющие остаться в рамках SAQ-A. Любой «кастомный» ввод данных карт на вашем домене — это неоправданный риск.
Подводные камни рекуррентов и 54-ФЗ
Безопасность данных — это лишь часть процесса. В России рекуррентные списания должны быть строго согласованы с 54-ФЗ. Ошибка многих SaaS — отсутствие явного согласия клиента на автосписание в пользовательском соглашении. Без этого чек, сформированный при рекуррентной операции, может быть признан некорректным при проверке налоговой, что влечет штрафы до 10 000 руб. за каждый неправильно оформленный документ.
Практический пример: при переходе с зарубежного эквайринга на российский многие забывают, что в РФ для первого списания (валидации карты) часто требуется 3DS-подтверждение (SMS-код). Последующие рекуррентные платежи проходят без 3DS, но если сумма списания резко меняется (например, переход с тарифа «Базовый» на «Про»), банк может отклонить транзакцию по соображениям безопасности, что приведет к потере доступа пользователя к сервису.
Экспертный вывод: Чтобы избежать сбоев, внедряйте уведомления о неудачной оплате и используйте механизм «мягкого» напоминания о смене тарифа перед списанием.
Вывод
Для SaaS в России единственный разумный путь — полная токенизация через API эквайера и использование Hosted Payment Page. Это позволяет переложить 99% ответственности по PCI DSS на банк и сосредоточиться на продукте, а не на защите инфраструктуры. Избегайте хранения любых данных карт в своей БД, даже в зашифрованном виде. Начните с выбора сервиса из топ-100 сервисов интернет-эквайринга для SaaS с рекуррентными платежами по подписке в России (54-ФЗ, API), который поддерживает бессрочные токены и автоматическую отправку чеков по 54-ФЗ.