Содержание
Оплата через платежную систему проходит в несколько стандартных шагов: покупатель инициирует платеж на сайте, магазин передает сумму и данные заказа платежному шлюзу, система перенаправляет пользователя на защищенную страницу (или открывает iframe), где он вводит данные карты/кошелька, после чего платежный шлюз отправляет запрос в банк-эквайер или процессинговый центр, а затем возвращает магазину статус (успех/ошибка) через callback-уведомление (webhook). Весь процесс занимает от 2 до 30 секунд, причем сами финансовые данные продавец никогда не видит.
Участники процесса оплаты
Чтобы понять, как проходит оплата, нужно знать роли всех действующих лиц.
- Покупатель (клиент) — хочет оплатить товар или услугу.
- Продавец (магазин/сайт) — принимает платеж на свой расчетный счет.
- Платежная система (агрегатор) — например, Stripe, PayPal, Robokassa. Предоставляет технический шлюз и берет комиссию.
- Банк-эквайер — банк, обслуживающий продавца и зачисляющий деньги на его счет.
- Банк-эмитент — банк, выпустивший карту покупателя (списывает деньги).
- Платежный шлюз (gateway) — технический API, через который обмениваются данными.
Пошаговая схема работы платежной системы
Процесс можно разбить на 7 логических этапов. Рассмотрим на примере оплаты картой на интернет-сайте.
| Этап | Что происходит | Кто участвует |
|---|---|---|
| 1. Формирование заказа | Покупатель нажимает «Оплатить», сайт создает уникальный идентификатор заказа (order_id) и сумму. | Сайт (CMS, самописный код на Laravel/Django) и покупатель |
| 2. Запрос к платежному шлюзу | Сайт отправляет POST/API-запрос к платежной системе с суммой, описание, callback-URL (адрес, куда придет ответ). | Сайт ↔ Платежный шлюз |
| 3. Перенаправление или виджет | Шлюз возвращает URL для оплаты или iframe. Покупатель переходит на защищенную страницу (HTTPS, PCI DSS). | Платежный шлюз → Покупатель |
| 4. Ввод платежных данных | Покупатель вводит номер карты, срок действия, CVC. Платежная система не передает эти данные магазину. | Покупатель ↔ Платежный шлюз |
| 5. Процессинг и авторизация | Шлюз отправляет запрос в банк-эмитент через платежные сети (Visa/Mastercard). Деньги блокируются на карте. | Платежный шлюз → Банк-эмитент |
| 6. Callback / Webhook | Банк-эмитент возвращает ответ (успех/отказ). Шлюз мгновенно отправляет POST на callback-URL сайта с цифровой подписью. | Платежный шлюз → Сайт |
| 7. Подтверждение и списание | Сайт проверяет подпись, обновляет статус заказа на «Оплачен». В конце дня деньги поступают на счет продавца (клиринг). | Сайт (база данных, CRM) и банк-эквайер |
Способы интеграции оплаты на сайт
Платежные системы предлагают несколько технических вариантов подключения. Выбор зависит от CMS, уровня безопасности и опыта разработчика.
Redirection (перенаправление на страницу платежной системы)
Самый простой способ. Покупатель переходит на домен платежной системы (например, checkout.stripe.com), оплачивает, и его возвращают обратно на сайт. Минус — пользователь покидает сайт. Плюс — продавец не несет ответственности за безопасность карточных данных. Такой метод часто используют сайты на конструкторах (например, SitePro.by или Tilda) и коробочные CMS вроде Joomla с плагинами.
iframe (виджет на странице магазина)
Форма оплаты загружается во всплывающем окне или встроенном фрейме внутри сайта. Покупатель не уходит с вашего домена, но данные всё равно идут напрямую в платежную систему. Этот баланс между удобством и безопасностью популярен в интернет-магазинах на самописных движках.
Direct API (прямая интеграция с сервера)
Сайт собирает данные карты у себя (через собственную форму) и отправляет их в платежный шлюз напрямую. Это требует сертификации PCI DSS Level 1 (очень строгой и дорогой). Используется только крупными игроками (Ozon, Wildberries). Для обычного бизнеса не рекомендуется.
Безопасность и проверки на этапе оплаты
Современные платежные системы обязаны применять 3D Secure (3DS, 3DS2) — двухфакторную аутентификацию. Покупатель дополнительно подтверждает платеж через SMS-код или пуш-уведомление в приложении банка. Без 3DS ответственность за фрод часто ложится на продавца.
Также платежная система проводиет автоматические проверки:
- Лимиты по карте (суточные, месячные).
- Страна выпуска карты и страна IP покупателя (антифрод-система).
- Наличие средств на счете (авторизация).
- Блокировки карты (утеряна, просрочена).
Что происходит после успешной оплаты (постпроцессинг)
После того как платежная система вернула статус «success», запускаются невидимые пользователю процессы:
- Формирование чеков для онлайн-кассы (ФЗ-54) — если магазин работает с фискальными данными.
- Запись транзакции в CRM (чтобы менеджер видел статус оплаты).
- Автоматическая отправка письма покупателю с подтверждением.
- Запуск доставки (если интернет-магазин) или активация услуги (хостинг, подписка).
- Периодические холдинги (если это recurring payment — например, ежемесячная подписка).
Кроме того, через определенный интервал (обычно раз в сутки) происходит клиринг — блокировка с карты превращается в фактическое списание, и деньги уходят на счет продавца.
Возможные ошибки и их причины
Знание типичных сбоев помогает быстрее диагностировать проблемы при интеграции.
- Ошибка подписи (signature mismatch) — не совпадает контрольная сумма в callback. Часто из-за неверного секретного ключа или кодировки.
- Таймаут шлюза — платежная система не отвечает за 30-60 секунд. Нужна повторная попытка или переключение на резервный шлюз.
- Отказ эмитента — недостаточно средств, карта не поддерживает онлайн-платежи, превышен лимит. Пользователь должен связаться со своим банком.
- Double post (дубль-платеж) — когда покупатель дважды нажал кнопку «Оплатить». Защита: идемпотентность ключей (один order_id не может быть оплачен дважды).
Как выбрать платежную систему для сайта
При выборе обращают внимание на: комиссию (от 0,5% до 3%), скорость вывода денег на расчетный счет, поддержку нужных способов оплаты (карты, SBP, Apple/Google Pay, криптовалюта), наличие SDK для вашего языка (PHP, Python, Node.js) и документации по webhook-обработчикам. Если сайт работает на готовой CMS (Joomla, WordPress), проверьте наличие плагина для конкретной платежной системы.
Итог: прозрачность и автоматизация
Оплата через платежную систему — это цепочка технических и финансовых взаимодействий, которая за секунды переводит деньги от покупателя к продавцу, минуя прямой контакт с чувствительными данными. Для конечного пользователя процесс выглядит как пара кликов, а для разработчика — как грамотная настройка API, обработка callback с проверкой подписи и логирование транзакций. Понимание этой схемы позволяет избежать ошибок интеграции и повысить доверие к вашему интернет-магазину.
