Безопасность платежей на сайте начинается с правильного разделения ролей: покупатель вводит реквизиты в защищённой форме провайдера, сайт получает подтверждённый статус на сервере, а товар или доступ выдаётся только после этой проверки. Не подтверждайте заказ по странице «Оплата успешна» и не принимайте реквизиты карты в чате, CRM или самописной форме.
Кому пригодится эта схема: интернет-магазинам с предоплатой и возвратами, сервисам с подписками и рекуррентными списаниями, а также продавцам цифровых товаров и онлайн-услуг. Для всех трёх моделей критичны серверная сверка статуса, защита от повторных уведомлений и понятный порядок возврата или спора.
Рабочая цепочка: клиент выбирает оплату → открывает форму провайдера → проходит нужный сценарий аутентификации → провайдер отправляет уведомление на сервер → сервер проверяет его и статус операции → заказ получает статус «оплачен» → при необходимости формируется кассовый чек. Каждый шаг должен иметь владельца: разработчика, менеджера заказов, бухгалтера или сотрудника, который разбирает спорные платежи.
Выдавайте заказ в сборку после подтверждения оплаты на сервере. Возврат проводите через платёжный сервис, затем сверяйте его со статусом заказа и кассовым документом. Схему оплаты и чеков для интернет-торговли разберите в статье «Онлайн-касса для интернет-магазина: выбор, подключение и запуск».
До первого списания покажите стоимость, периодичность, порядок отмены и условия подписки. Сохраняйте согласие клиента, дату подключения, историю списаний и отмен, а также подтверждение оказания услуги. Эти материалы понадобятся, если клиент оспорит операцию.
Открывайте доступ к файлу, ключу или личному кабинету только после подтверждённого статуса платежа. Для рискованных заказов настройте ручную проверку по правилам антифрода; не просите покупателя присылать номер карты или код безопасности в переписке.
Передайте карточную форму провайдеру. Выбирайте платёжную страницу провайдера или его защищённый виджет. Тогда ваш сайт не принимает номер карты, срок действия и CVV/CVC, а в CMS, CRM и логах остаются только данные заказа и идентификатор операции.
Проверьте 3-D Secure в реальных сценариях интеграции. Не ставьте задачу «включить 3-D Secure всегда»: решение об аутентификации принимает платёжная инфраструктура и банк-эмитент в конкретной операции. Протестируйте, как сайт обрабатывает успешный frictionless-сценарий, challenge с подтверждением, отказ и тайм-аут. Во всех неуспешных сценариях заказ должен остаться неоплаченным.
Настройте антифрод как процесс. Начните с лимита попыток оплаты с одного IP-адреса, устройства или карты, уведомлений о всплеске отказов, контроля необычно крупных сумм и ручной проверки части рискованных заказов. Сразу назначьте сотрудника и срок проверки: например, он подтверждает или отменяет подозрительный заказ до передачи в доставку.
Запросите подтверждение PCI DSS и разграничьте ответственность. Попросите у провайдера действующий документ о соответствии PCI DSS: Attestation of Compliance либо письмо, где указана область соответствия. В договоре или регламенте зафиксируйте, где размещена платёжная форма, кто обрабатывает карточные данные и токены, кто уведомляет об инцидентах, как передаются webhook и кто готовит материалы по чарджбэку. PCI DSS провайдера не заменяет защиту аккаунтов сотрудников, обновления сайта и контроль доступа к API-ключам.
Платёжная ссылка подходит для ручных счетов, заявок из мессенджеров и быстрого старта без доработки сайта. Виджет выбирайте для стандартной формы оплаты в корзине: покупатель остаётся в интерфейсе магазина, а карточные данные обрабатывает провайдер. API требуется для подписок, личного кабинета, сложных статусов, разделения оплат и тесной связки с CRM, складом и кассой.
| Критерий | Что запросить или проверить | Решение для бизнеса |
|---|---|---|
| Форма оплаты | Где вводятся реквизиты и какие данные попадут в ваш контур | Ссылка — для ручных оплат; виджет — для стандартной корзины; API — для сложной логики |
| 3-D Secure | Поддержку и статусы frictionless, challenge, отказа, тайм-аута в тестовой среде | Не переводить заказ в «оплачен» при любом незавершённом сценарии |
| PCI DSS | Attestation of Compliance или письмо с областью соответствия; границы ответственности | Не хранить реквизиты карты и CVV/CVC в своих системах |
| Webhook и API | HTTPS, подпись или секрет, документацию по повторам и запросу статуса | Выбирать API, если нужны подписки, CRM-статусы или нестандартная логика |
| Антифрод и споры | Лимиты, фильтры, отчёты, порядок возвратов и сроки ответа по спору | Назначить владельца процесса и хранить доказательства исполнения заказа |
| Касса и ОФД | Передачу состава заказа, контакта покупателя, возвратов и защиту от дублей | Проверить на тестах: один расчёт — один чек, возврат — отдельный корректный сценарий |
Страница успеха в браузере не подтверждает оплату. Источник истины — серверное уведомление провайдера и, при необходимости, запрос статуса операции через его API.
Ошибка: заказ выдаётся после редиректа. Исправление: выдавайте товар или доступ только после серверной проверки webhook и статуса платежа.
Ошибка: webhook принимается без проверки подписи. Исправление: валидируйте подпись или секрет, сопоставляйте параметры с заказом и при расхождении запрашивайте статус через API.
Ошибка: повторное уведомление создаёт дубль. Исправление: привяжите payment ID к операции и сделайте обработчик идемпотентным.
Ошибка: тестируется только успешная оплата. Исправление: добавьте в приёмку отказ, тайм-аут, возврат, повторный webhook и сбой связи с кассой.
Ошибка: никто не отвечает за антифрод и чарджбэки. Исправление: назначьте владельца процесса, настройте уведомления и храните заказ, логи, согласия и подтверждение доставки в одной карточке случая.
Команда «Интернет Касса» помогает интернет-магазинам, сервисам подписки и продавцам онлайн-услуг подготовить запуск приёма оплат. На разборе проверим карту потока, платёжную форму, webhook и статусы, защиту от дублей, возвраты, связку с кассой и передачу чеков. По итогам вы получите список критичных ошибок, порядок доработок и схему ответственных по этапам.
Запросить разбор платёжного потока.
Да, выберите провайдера с поддержкой 3-D Secure и протестируйте обработку его результатов. Аутентификация не запрашивается при каждой операции: сайт должен корректно обработать frictionless-сценарий, challenge, отказ и тайм-аут, не выдавая заказ без подтверждённой оплаты.
Нет, соответствие PCI DSS не защищает ваш сайт и бизнес-процессы автоматически. Используйте форму провайдера, проверяйте webhook на сервере, ограничьте доступы и настройте антифрод с обработкой возвратов и споров.
Да, передайте ввод карты на платёжную страницу или в защищённый виджет провайдера. В своей системе храните идентификатор платежа, номер заказа, сумму, валюту, статус и технические логи без карточных реквизитов и CVV/CVC.
Проверьте форму оплаты, 3-D Secure, webhook, антифрод, возвраты, споры, отчёты и тестовую среду. Запросите действующее подтверждение PCI DSS — например, Attestation of Compliance или письмо с областью соответствия — и закрепите в договоре, кто отвечает за карточные данные, токены, инциденты, уведомления и документы по чарджбэку.
Не исполняйте заказ и запросите статус платежа через API провайдера. Сверьте payment ID, номер заказа, сумму и валюту с созданной операцией; расхождение передайте в поддержку провайдера и зафиксируйте в журнале инцидентов.