Приём онлайн-оплаты кажется простым: подключил платёжную систему — и деньги идут. Но за этой простотой стоит вопрос, который способен разорить бизнес при неудачном решении: где вводятся и хранятся данные карт покупателей. Одна утечка номеров карт — это репутационная катастрофа, штрафы и потеря доверия. Хорошая новость: правильная архитектура приёма платежей снимает большую часть этих рисков ещё до первой транзакции.
Разберём практично, как обеспечить безопасность платежей в магазине на 1С-Битрикс: что такое стандарт PCI DSS и как уменьшить его требования, зачем нужна токенизация карт, почему данные карты не должны проходить через ваш сервер и как это реализовано в модуле «Интернет-магазин». Это тема на стыке разработки и бизнес-процессов, которую мы закрываем вместе с автоматизацией продаж и склада на 1С.
Коротко
- PCI DSS — стандарт безопасности данных карт; чем меньше данных карт касается вашего сайта, тем меньше требований.
- Данные карты не должны проходить через ваш сервер: ввод происходит на стороне платёжного провайдера.
- Токенизация заменяет номер карты на безопасный токен — так работают сохранённые карты и подписки.
- Безопасность платежей — это архитектура приёма, а не один SSL-сертификат.
Почему безопасность платежей — это архитектура
Ключевая мысль, с которой стоит начать: безопасность платежей определяется не одним сертификатом или галочкой, а тем, как устроен приём денег. Главный вопрос — касаются ли данные карты вашего сервера. Если да, вы берёте на себя огромную ответственность и попадаете под строгие требования. Если нет, большая часть рисков и обязанностей уходит к платёжному провайдеру, у которого для этого есть сертифицированная защищённая среда.
Поэтому грамотный магазин проектирует приём платежей так, чтобы конфиденциальные данные карт вообще не проходили через его инфраструктуру. Это не только безопаснее, но и дешевле: не нужно строить и сертифицировать сложную защищённую среду под данные карт. Всю тяжёлую работу берёт на себя платёжный провайдер.
Что такое PCI DSS
PCI DSS (Payment Card Industry Data Security Standard) — международный стандарт безопасности данных платёжных карт. Он описывает набор требований к любому, кто обрабатывает, передаёт или хранит данные карт. Основные группы требований:
- Защита сети. Межсетевые экраны, сегментация, защита периметра.
- Защита данных карт. Шифрование при передаче и хранении, минимизация хранимых данных.
- Контроль доступа. Ограничение доступа к данным карт по необходимости, уникальные учётные записи.
- Мониторинг и тестирование. Логирование, регулярные проверки и сканирования уязвимостей.
Стандарт обязателен для участников платёжной индустрии. Практический вывод для магазина простой: объём требований прямо зависит от того, сколько данных карт проходит через вас. Минимизируя контакт с этими данными, вы минимизируете и обязательства.
Зона ответственности магазина
Не каждый магазин обязан проходить полноценную сертификацию. Уровень требований зависит от схемы приёма платежей.
| Схема приёма | Где вводится карта | Требования PCI DSS |
|---|---|---|
| Редирект на банк | На стороне провайдера | Минимальные (лёгкая самооценка) |
| Встроенная форма провайдера | Форма провайдера на вашей странице | Небольшие |
| Своя форма карты на сайте | На вашем сервере | Максимальные, дорого |
Отсюда стратегия по умолчанию: выбирать схему, при которой карта вводится вне вашего сайта. Тогда сервер не обрабатывает конфиденциальные данные карт, и на вас распространяется наиболее облегчённый вариант самооценки. Прямой приём данных карты на своём сайте оправдан лишь для крупных игроков, готовых строить и сертифицировать защищённую среду.
Данные карты не должны касаться сайта
Главный принцип безопасности повторим отдельно: данные карты не должны проходить через ваш сервер и тем более храниться в базе Битрикса. Как только номер карты, срок и CVV оказываются на вашей стороне, сервер становится и объектом строгих требований, и лакомой целью для атак.
Этот подход резко упрощает жизнь: не нужно защищать то, чего у вас нет. Разбор ответственности и рисков хранения данных мы также затрагиваем в статье про REST, вебхуки и безопасность в Битрикс.
Токенизация: как работают сохранённые карты
Возникает вопрос: если данные карты не хранятся у нас, как сделать оплату «в один клик» и подписки? Ответ — токенизация. Это замена реальных данных карты на токен: случайный идентификатор, бесполезный для мошенника сам по себе.
Реальные данные карты хранит платёжный провайдер в своей защищённой среде, а магазину возвращается токен, по которому можно инициировать повторные списания. Клиент при первой оплате «привязывает» карту, а дальше платит одним действием — но на вашей стороне лежит только токен, а не номер карты. Так реализуют сохранённые карты, автоплатежи и подписки без хранения конфиденциальных данных у себя.
Схемы приёма платежей
На практике безопасные схемы приёма сводятся к двум основным вариантам, оба выносят ввод карты за пределы вашего сервера.
- Редирект на платёжную форму. После оформления заказа покупатель переходит на страницу оплаты провайдера, вводит карту там и возвращается на сайт с результатом.
- Встроенная форма провайдера. На вашей странице отображается платёжная форма, которую размещает и обслуживает провайдер (например, через его виджет), — данные карты идут напрямую к нему, минуя ваш сервер.
- Подтверждение статуса. В обеих схемах провайдер уведомляет сайт о результате оплаты через callback, по которому заказ переводится в оплаченный.
Выбор между редиректом и встроенной формой — вопрос UX и требований провайдера; с точки зрения безопасности оба варианта хороши тем, что данные карты не касаются вашего сервера.
3-D Secure и антифрод
Дополнительный слой защиты при оплате — 3-D Secure: подтверждение держателя карты через код из СМС или в приложении банка. Он снижает мошенничество с украденными картами и переносит часть ответственности за спорные операции на банк-эмитент. Для магазина это стандартный и желательный механизм, который обеспечивает платёжный провайдер на своей стороне.
Помимо 3-D Secure, провайдеры применяют антифрод-системы: анализ подозрительных операций, лимиты, проверки по различным признакам. Всё это работает вне вашего сайта — от вас требуется лишь корректно интегрировать приём платежей. Ещё один довод в пользу схемы, где сложную защиту берёт на себя платёжный сервис, а не ваш магазин.
Реализация в 1С-Битрикс
В модуле «Интернет-магазин» приём платежей строится на платёжных системах и их обработчиках. Общая последовательность:
- Подключение платёжной системы. В настройках торгового каталога/магазина добавляется платёжная система с нужным обработчиком провайдера.
- Переход на оплату. При оформлении заказа покупатель уходит на форму провайдера или видит его встроенную форму — карта вводится не на вашем сервере.
- Обработка callback. Провайдер присылает уведомление о статусе оплаты, по которому заказ переводится в оплаченный и запускаются дальнейшие процессы.
- Токены для повторных списаний. Если нужны сохранённые карты, магазин работает с токеном провайдера, а не с данными карты.
Важно, что в этой схеме база Битрикса не хранит данные карт — только статусы и идентификаторы транзакций. Настройку заказов и их движение в учёт мы закрываем услугой автоматизации продаж и склада на 1С, а надёжность инфраструктуры, где всё это работает, — темой хостинга и инфраструктуры BitrixVM.
Связь с 54-ФЗ и кассовыми чеками
Безопасность платежей соседствует с другой обязательной задачей — фискализацией по 54-ФЗ. При онлайн-оплате нужно пробить кассовый чек и передать его в ФНС и покупателю. Это отдельная от PCI DSS история, но она завязана на тот же момент — успешную оплату.
После подтверждения платежа должен корректно сформироваться чек, а данные заказа — согласованно пройти в учётную систему и онлайн-кассу. На практике это выстраивается на стыке сайта, платёжного провайдера и кассового сервиса. Чтобы всё сходилось без ручных сверок, обмен заказами с 1С должен быть надёжным — про предсказуемую выкладку и обновление таких интеграций мы пишем в статье про CI/CD и деплой в Битрикс.
SSL, callback и защита обмена
Даже при безопасной схеме приёма остаются технические требования к защите. HTTPS с актуальным SSL/TLS обязателен: он шифрует канал между покупателем и сайтом и между сайтом и провайдером. Но это лишь часть — шифрование канала не отменяет главного принципа не хранить данные карт.
Отдельного внимания требует обработка callback от провайдера: уведомление о статусе оплаты нужно проверять на подлинность (подпись), чтобы никто не мог подделать «заказ оплачен». Это классическая зона безопасности интеграций — те же принципы, что мы разбираем для вебхуков в материале про REST, вебхуки и безопасность: проверка подписи, ограничение доступа, идемпотентность обработки.
Частые ошибки
- Своя форма карты на сайте. Данные карты идут через ваш сервер — максимальные требования и риски.
- Хранение данных карт в базе. Номера карт в базе Битрикса — недопустимо, вместо этого — токены провайдера.
- Ставка только на SSL. Считают, что сертификат решает всё; архитектура приёма важнее.
- Callback без проверки подписи. Статус «оплачено» можно подделать, если не верифицировать уведомление.
- Нет 3-D Secure. Отключённое подтверждение повышает мошенничество и споры.
- Оплата и чек рассинхронизированы. Платёж прошёл, а чек по 54-ФЗ не сформировался.
- Игнорируют объём требований PCI DSS. Не понимают свою зону ответственности и рискуют.
Чек-лист безопасности платежей
- Карта вводится вне сайта. Редирект или встроенная форма провайдера; ваш сервер не видит данных карты.
- Данные карт не хранятся. В базе — только токены, статусы и идентификаторы транзакций.
- Токенизация настроена. Сохранённые карты и повторные списания работают через токен провайдера.
- 3-D Secure включён. Подтверждение держателя карты на стороне провайдера активно.
- Callback проверяется. Подпись уведомления об оплате верифицируется, обработка идемпотентна.
- HTTPS повсюду. Актуальный SSL/TLS на всех страницах оплаты и оформления.
- Чек по 54-ФЗ формируется. После оплаты корректно пробивается кассовый чек и уходит в учёт.
- Зона PCI DSS понята. Схема приёма выбрана осознанно, объём требований минимизирован.
Вывод
Безопасность платежей — это в первую очередь архитектура, а не отдельный сертификат. Постройте приём так, чтобы данные карты никогда не касались вашего сервера: ввод — на стороне платёжного провайдера, повторные списания — через токены, а не хранимые номера карт. Тогда PCI DSS не превращается в тяжёлое бремя, а большая часть рисков уходит к тому, у кого для их обработки есть сертифицированная среда.
На сайте 1С-Битрикс это реализуется штатно через платёжные системы модуля «Интернет-магазин»: редирект или встроенная форма провайдера, проверяемый callback, токенизация для сохранённых карт. Добавьте к этому HTTPS, 3-D Secure и корректную фискализацию по 54-ФЗ — и вы получите безопасный приём оплаты, который защищает и покупателя, и бизнес, не требуя строить дорогую защищённую среду под данные карт.
