Как работает взаимодействие магазина, эквайера и платёжной системы при онлайн‑оплате

При совершении покупки в интернет‑магазине деньги перемещаются между несколькими участниками: продавец (магазин), эквайер (банк, обслуживающий счёт продавца), платёжная система (Visa, Mastercard, МИР и др.) и банк‑эмитент (банк, выпустивший карту покупателя). Понимание цепочки помогает выбрать подходящий способ подключения, избежать ошибок при интеграции и быстро диагностировать проблемы с оплатой.

Основные участники и их функции

• Магазин (торговая точка) — получает заказ от покупателя, формирует запрос на оплату и передаёт его платёжному шлюзу или напрямую эквайеру.
• Эквайер — банк, открывший расчётный счёт магазину. Он принимает запрос на авторизацию, взаимодействует с платёжной системой и после успешного завершения зачисляет средства на счёт продавца (за вычетом комиссии).
• Платёжная система — международная или национальная сеть, которая обеспечивает передачу данных авторизации между эквайером и банком‑эмитентом, а также устанавливает правила взаимодействия, стандарты безопасности и размеры комиссий.
• Банк‑эмитент — банк, выпустивший карту покупателя. Он проверяет доступность средств, выполняет антифрод‑проверки и посылает ответ об авторизации или отказе обратно через платёжную систему.

Этапы обработки онлайн‑оплаты

1. Инициирование платежа — покупатель вводит данные карты (или выбирает сохранённый способ) на странице магазина. Магазин формирует запрос, включающий сумму, валюту, идентификатор заказа и необходимые реквизиты карты (номер, срок действия, CVC).
2. Передача запроса в платёжный шлюз — магазин может использовать собственный шлюз, готовое решение от провайдера или API эквайера. Шлюз шифрует данные (PCI DSS) и отправляет их эквайеру.
3. Авторизация у эквайера — эквайер получает запрос, добавляет свой идентификатор магазина и пересылает его в платёжную систему.
4. Маршрутизация в платёжной системе — система определяет, какой банк‑эмитент обслуживает карту (по первым шести цифрам номера — BIN), и направляет запрос ему.
5. Проверка у банка‑эмитента — эмитент проверяет лимит, блокировки, 3‑D Secure (если подключён) и формирует ответ: одобрение или отказ с кодом причины.
6. Обратная передача ответа — ответ проходит обратным путём: эмитент → платёжная система → эквайер → магазин. Магазин получает результат и показывает покупателю страницу успеха или ошибки.
7. Очистка (settlement) и расчёт — после авторизации (обычно в конце дня) эквайер отправляет пакет одобренных транзакций в платёжную систему, которая осуществляет clearing (сопоставление сумм) и переводит деньги от эмитентов к эквайеру. Эквайер зачисляет чистую сумму на счёт магазина за вычетом своей комиссии и комиссии платёжной системы.

Схемы интеграции магазина

Выбор способа взаимодействия зависит от требуемого уровня контроля над процессом оплаты и требований к безопасности.

• Перенаправление (redirect) — покупатель отправляется на страницу платёжного шлюза или банка, где вводит данные карты. После оплаты возвращается в магазин. Просто в реализации, но магазин не контролирует дизайн формы оплаты.
• Встроенная форма (hosted payment form) — форма оплаты размещается на домене шлюза, но выглядит как часть сайта магазина (через iframe или JS‑виджет). Снижает усилия по PCI DSS, сохраняя более привычный UX.
• Полная API‑интеграция — магазин самостоятельно собирает данные карты и отправляет их напрямую эквайеру через защищённое соединение. Требует сертификации PCI DSS уровня SAQ D или использования токенизации, но даёт полный контроль над пользовательским опытом.

Ключевые параметры, влияющие на стоимость и надёжность

• Комиссия эквайера — процент от суммы транзакции плюс фиксированная плата за операцию. Зависят от типа карты (дебетовая/кредитная), страны выпуска и объёма продаж.
• Комиссия платёжной системы — обычно включается в ставку эквайера, но может выделяться отдельно для международных карт.
• Стоимость подключения и абонентская плата — некоторые провайдеры взимают плату за подключение к API, ежемесячную плату за терминал или за доступ к антифрод‑сервисам.
• Поддержка 3‑D Secure 2.0 — снижает риск мошеннических chargeback, но может добавить шаг ввода пароля или биометрии, влияя на конверсию.
• Сроки зачисления средств — обычно T+1 (один рабочий день) после очистки, но у некоторых эквайеров возможны мгновенные выплаты за дополнительную плату.

Типичные ограничения и что проверять перед подключением

• География приёма карт — убедитесь, что эквайер и платёжная система поддерживают карты стран, из которых вы ожидаете покупателей.
• Типы карт и альтернативные способы оплаты — помимо Visa/Mastercard/МИР могут потребоваться Apple Pay, Google Pay, кошельки, банковские переводы.
• Требования к безопасности — уточните, какой уровень PCI DSS необходим для выбранной схемы интеграции и предоставляет ли провайдер инструменты токенизации или шифрования.
• Лимиты по сумме и количеству транзакций — некоторые тарифы имеют верхний порог за операцию или месячный оборот.
• Документы для подключения — обычно требуются учредительные документы, выписка из расчётного счёта, описание товаров/услуг и политика возврата.
• Тестовая среда (sandbox) — проверьте наличие тестовых карт и возможности имитировать разные ответы (одобрение, отказ, 3‑D Secure) перед запуском в продакшн.

Частые ошибки при интеграции и как их избежать

• Отправка незашифрованных данных карты — приводит к нарушению PCI DSS и штрафам. Решение: использовать токенизацию или передавать данные только через сертифицированный шлюз.
• Необработанные ответы от эквайера — если магазин не проверяет коды ответа (например, 00 — одобрено, 51 — недостаточно средств), может ошибочно считать платёж успешным. Решение: реализовать полную обработку всех возможных кодов и логировать их.
• Отсутствие проверки подписи или хеша ответа — открывает возможность подмены ответа злоумышленником. Решение: проверять подпись согласно документации провайдера (HMAC, SHA‑256 и т.п.).
• Неучёт асинхронных уведомлений (webhooks) — некоторые операции (например, возврат или отложенный платёж) приходят позже через веб‑хуки. Игнорирование приводит к несинхронному состоянию заказа. Решение: настроить приём и обработку webhook‑ов с проверкой подписи.
• Тестирование только на одобрённых транзакциях — не проверяется поведение при отказах, что приводит к плохому пользовательскому опыту. Решение: смоделировать различные сценарии в sandbox.

Практический порядок действий при подключении нового способа оплаты

1. Определить географию покупателей и необходимые типы карт/кошельков.
2. Сравнить предложения эквайеров по комиссии, поддерживаемым платёжным системам, срокам зачисления и требованиям к PCI DSS.
3. Выбрать схему интеграции (redirect, hosted form или API) в зависимости от ресурсов разработки и желаемого уровня контроля.
4. Получить тестовые учётные данные в sandbox‑окружении эквайера.
5. Реализовать запрос на авторизацию, обработку ответов и логирование всех кодов.
6. Настроить проверку подписи/хэша ответа и, если требуется, токенизацию карты.
7. Добавить обработку webhook‑ов для очистки, возвратов и отложенных платежей.
8. Провести полное тестовое покрытие: одобрение, отказ по разным причинам, 3‑D Secure, частичный возврат.
9. Перейти в режим продакшн, мониторить первые транзакции на наличие отклонений по времени и сумме.
10. Настроить еженедельный сверку полученных средств с выпиской эквайера и своевременно обращаться в поддержку при расхождениях.

Когда стоит обращаться к специалисту

Если у вас нет опыта работы с PCI DSS, вы планируете хранить данные карт на своих серверах или вам требуется сложная схема с несколькими валютами и динамическим конвертированием, лучше привлечь сертифицированного интегратора или пользоваться готовым решением уровня PCI DSS Level 1 провайдера. Это снижает риск штрафов и упрощает аудит.

Материал носит информационный характер. Для выбора конкретного эквайера, настройки интеграции и оценки соответствия требованиям безопасности рекомендуется проконсультироваться с квалифицированным специалистом по платёжным системам и/или аудитором PCI DSS.