Что такое сервис приёма платежей в интернете: как устроен платёжный провайдер и какие веб-технологии используются

Опубликовано: 20 Декабря, 2023

1) Введение

Сервис приёма платежей — это техническая и юридическая «прослойка», которая позволяет сайту, приложению или онлайн-сервису принимать оплату от клиентов и получать деньги на расчётный счёт. На практике под этим термином могут подразумеваться разные роли: платёжный шлюз (gateway), платёжный провайдер/агрегатор (PSP), процессинг, интернет-эквайринг банка. В реальном проекте почти всегда используется цепочка участников, а не один «магический сервис».

Ценность платёжного сервиса для бизнеса — в том, что он берёт на себя сложность: соответствие требованиям безопасности, интеграции с банками и платёжными методами, работу с 3-D Secure, антифрод, статусы платежей, возвраты, отчёты и сверку.

2) Термины и роли: кто участвует в платеже

Чтобы понимать устройство сервиса приёма платежей, нужно различать роли.

2.1. Основные участники

Покупатель (cardholder) — инициирует оплату.
Продавец (merchant) — сайт/приложение, которое принимает деньги.
Платёжный сервис / провайдер (PSP, payment service provider) — поставщик инфраструктуры для приёма платежей.
Платёжный шлюз (payment gateway) — технический слой, принимающий данные оплаты и передающий их дальше (иногда внутри PSP).
Процессинг (processor) — обработка транзакций и взаимодействие с платёжными сетями/банками (может быть у PSP или у партнёров).
Банк-эквайер (acquirer) — банк продавца, обслуживает приём платежей.
Банк-эмитент (issuer) — банк покупателя, выпустивший карту.
Платёжная система — сеть правил и маршрутизации (вокруг карт и расчётов).
Антифрод-провайдер — может быть встроенным или внешним модулем.

2.2. Чем отличается эквайринг от агрегатора

Прямой эквайринг: продавец заключает договор с банком-эквайером напрямую, интегрируется с его шлюзом/процессингом.
Агрегатор/PSP: продавец подключается к провайдеру, который уже имеет договоры и маршруты, а также часто даёт единый API и больше методов оплаты.

3) Как проходит платёж «конец в конец» (end-to-end)

Упрощённо платёж в интернете — это последовательность шагов от нажатия «Оплатить» до финального списания и отражения статуса в системе продавца.

3.1. Поток транзакции (типовой сценарий)

Checkout на стороне продавца
Пользователь выбирает товар/тариф, формируется заказ.
Создание платежа в платёжном сервисе
Продавец на сервере создаёт объект платежа (часто называют payment / payment intent): сумма, валюта, идентификатор заказа, параметры клиента, описание.
Передача пользователя на оплату
Возможны варианты:
- hosted checkout (платёжная страница провайдера);
- встроенный виджет (embedded) с редиректами для подтверждения;
- оплата внутри приложения через SDK.
Авторизация (authorization)
Выполняется проверка возможности списания у банка-эмитента (у покупателя).
Итог: «одобрено/отклонено». Иногда создаётся холд (резерв).
Подтверждение (capture) или отмена авторизации
- при одностадийной оплате capture происходит сразу;
- при двухстадийной — продавец подтверждает списание позже (например, после сборки заказа).
Клиринг и расчёты (settlement)
Средства фактически проходят расчёты и затем поступают продавцу по графику выплат.
Уведомление продавца о статусе
Статус может прийти:
- синхронно в ответе API;
- асинхронно через webhook (и это считается более надёжным источником правды).

3.2. Почему статусы платежа — критически важны

Платёж — это не «один ответ 200 OK». Он живёт в состояниях.

Типовой набор статусов (вариант):

Статус	Смысл	Что должен делать продавец
created	платёж создан, но не начат	показать пользователю переход к оплате
pending	оплата в процессе/ожидание подтверждения	ждать webhook, не выдавать товар
authorized	деньги зарезервированы (двухстадийно)	ожидать capture или отменить
captured / succeeded	платёж успешно списан	выдавать товар/услугу
failed	отклонён	показать причину/предложить повтор
canceled	отменён	вернуть пользователя в оплату/заказ
refunded	выполнен возврат	обновить учёт и уведомить клиента

Практическое правило: успех оплаты фиксируется по серверному событию (webhook) и/или по финальному статусу, а не по тому, что пользователь увидел «Оплата прошла».

4) Основные сценарии оплаты, которые поддерживает платёжный сервис

4.1. Разовая оплата (one-time payment)

Один заказ → один платёж → один результат.

4.2. Двухстадийная оплата (authorize / capture)

Применяется когда:

товар нужно подтвердить/собрать;
есть риск частичной комплектации;
услуга предоставляется после проверки.

Логика:

сначала авторизация (резерв),
затем capture на фактическую сумму (иногда возможны частичные списания, зависит от схемы).

4.3. Рекуррентные платежи и подписки

Для подписок важны:

хранение «платёжного токена» (а не данных карты);
правила повторных списаний;
обработка отказов и ретраев;
корректная отмена и управление периодами.

4.4. Платёж по ссылке (payment link)

Часто применяется для:

счетов на оплату,
продаж без полноценного интернет-магазина,
оплаты в мессенджерах/соцсетях.

4.5. Маркетплейсы: сплит и выплаты (payouts)

Для маркетплейса сервис должен уметь:

разделять платежи между получателями (split);
выполнять выплаты продавцам;
учитывать требования к идентификации получателей (KYC/AML) в зависимости от юрисдикции.

5) Архитектура платёжного сервиса: какие модули внутри

С точки зрения технологий платёжный сервис — это набор компонентов, где каждый отвечает за часть риска и надёжности.

5.1. Checkout/UI-слой

Варианты:

hosted checkout — платёжная страница у провайдера. Продавец минимально касается чувствительных данных.
embedded widget — виджет/форма на сайте продавца, но чувствительные данные обычно всё равно уходят напрямую провайдеру по защищённой схеме (токенизация).

Практический смысл: снижать объём данных, которые проходят через сервер продавца, чтобы упростить требования безопасности.

5.2. API-слой

Обычно есть методы:

создать платёж;
подтвердить платёж;
отменить/аннулировать авторизацию;
сделать возврат (полный/частичный);
запросить статус;
получить список операций по периоду.

5.3. Процессинговый слой и маршрутизация

Функции:

маршрутизация запросов к эквайерам/процессингу;
ретраи при временных сбоях;
защита от дублей (идемпотентность);
управление состояниями платежа.

5.4. Хранилища и аудит

Минимально нужны:

база транзакций и их статусов;
журнал событий (event log);
аудит действий (кто сделал возврат, кто изменил настройки);
хранилище токенов (если провайдер хранит токены).

5.5. Webhooks и событийная модель

Платёжный сервис отправляет продавцу события: успех, отказ, возврат, спор и т.д. Вебхуки считаются стандартом, потому что:

клиент может закрыть вкладку после оплаты;
сеть может “упасть” в момент ответа;
платёж может перейти в финальный статус позже.

5.6. Антифрод (risk engine)

Антифрод оценивает вероятность мошенничества по признакам:

поведение пользователя (скорость действий, повторные попытки);
устройство и сеть (IP, география, прокси-признаки);
совпадение данных (имя, страна, BIN карты, адрес);
исторические паттерны (по мерчанту и глобально);
признаки атаки (перебор карт, аномальные суммы, всплеск попыток).

Действия антифрода:

разрешить;
запросить 3-D Secure/доп. проверку;
отклонить;
отправить на ручную модерацию (в некоторых схемах).

6) Веб-технологии и протоколы: что применяется на практике

6.1. HTTP(S), REST, JSON

Типовая интеграция строится на:

HTTPS (обязателен),
REST-подобных API,
JSON-формате запросов/ответов.

Иногда для внутренних микросервисов используется gRPC, но наружный интеграционный контур обычно остаётся HTTP API.

6.2. Webhooks: как они устроены правильно

Webhook — это HTTP-запрос от провайдера к вашему серверу. Правильная реализация на стороне продавца включает:

проверку подписи (обычно HMAC) или другой механизм аутентификации;
проверку временных меток/nonce (если предусмотрено) для защиты от повторов;
быстрое подтверждение приёма (не блокировать ответ долгой обработкой);
постановку события в очередь и обработку асинхронно.

Практическая модель: webhook-endpoint принимает событие, валидирует, кладёт в очередь, отвечает 200, дальше воркер обновляет заказ/платёж.

6.3. Идемпотентность (idempotency keys)

Идемпотентность — механизм, который предотвращает двойное создание платежа или двойной возврат при повторной отправке запроса.

Сценарии, где это критично:

пользователь нажал «Оплатить» несколько раз;
сеть дала таймаут, клиент повторил запрос;
сервер продавца повторно отправил confirm.

Правило: все операции, которые могут приводить к движению денег, должны быть идемпотентными.

6.4. Ретраи, rate limiting и защита от перегрузки

Платёжные API обычно применяют:

лимиты запросов (rate limits);
ретраи с backoff для временных ошибок;
«circuit breaker» внутри инфраструктуры.

На стороне продавца аналогично полезно:

не делать бесконечных повторов при ошибке;
разделять синхронную оплату и фоновые проверки статусов.

6.5. Аутентификация и управление доступом

На практике применяются:

API keys (ключи доступа) с разграничением прав;
подписи запросов (HMAC) для критических методов;
иногда OAuth 2.0 (если есть сложная модель делегирования);
ротация ключей и хранение секретов в безопасном хранилище.

6.6. Frontend-механики

В браузере важны:

защита контента и ограничение источников (CSP);
корректные CORS-настройки (если есть кросс-доменные запросы);
предотвращение утечки токенов и секретов (никаких секретов в фронтенде);
защита от XSS и подмены скриптов.

7) Безопасность: что принципиально важно в платёжной интеграции

7.1. PCI DSS и почему это влияет на архитектуру

Главная идея: продавец не должен хранить и обрабатывать критичные данные карты (PAN/CVV) у себя, если хочет минимизировать требования и риски. Поэтому используется:

hosted checkout (платёжная страница провайдера),
или токенизация: браузер отправляет карточные данные провайдеру, а продавец получает токен, который можно использовать для подтверждения/подписок без хранения карты.

7.2. Токенизация

Токен — это идентификатор, который представляет платёжный инструмент без раскрытия его реквизитов. Токен хранится у провайдера (в vault), а мерчант использует его для:

повторного списания (подписки),
быстрых повторных оплат,
«one-click» сценариев (где разрешено правилами и согласиями).

7.3. 3-D Secure 2

3-D Secure добавляет шаг подтверждения у банка-эмитента (пуш, код, биометрия). Он снижает риск мошенничества, но может:

снижать конверсию (лишний шаг),
увеличивать долю незавершённых платежей.

Поэтому провайдеры часто применяют риск-ориентированный подход: включать 3DS по правилам и скорингу.

7.4. Что нельзя логировать

Технически важно исключить попадание чувствительных данных в логи и аналитику:

полный номер карты (PAN),
CVV,
секретные ключи,
полные персональные данные без необходимости.

8) Надёжность: как сервис предотвращает «двойные списания» и потерю статусов

Платёжные системы строят архитектуру вокруг типовых проблем: повторы, задержки, сетевые сбои, “at least once” доставка событий.

8.1. Почему webhook может прийти дважды

Провайдер не всегда знает, дошёл ли webhook до вашего сервера (ошибка сети, таймаут). Поэтому он повторит отправку.

Следствие: обработчик вебхуков должен быть идемпотентным. То есть одно и то же событие не должно дважды:

менять статус заказа,
начислять доступ/подписку,
выдавать товар.

8.2. Дедупликация событий

Практика: хранить уникальный event_id и отмечать обработанные события.

8.3. Модель «истина на сервере»

Надёжная схема:

фронтенд показывает пользователю промежуточный статус,
сервер ждёт webhook и только после него фиксирует финальное состояние заказа.

9) Интеграция платёжного сервиса в продукт: прикладной контур (пошагово)

Ниже — схема внедрения, которая снижает риск ошибок на проде.

9.1. Смоделировать сущности у себя

Минимальные сущности в вашей системе:

Order (заказ): что продаём, сумма, пользователь.
Payment (платёж): сумма, валюта, провайдер, статус.
PaymentAttempt (попытка): полезно, если допускаются повторы.
Refund (возврат): сумма, причина, статус.

9.2. Серверная часть: создание платежа

Типовой шаг:

Клиент нажимает «Оплатить».
Ваш сервер создаёт заказ (или проверяет существующий).
Ваш сервер создаёт платёж у провайдера (payment intent).
Ваш сервер возвращает клиенту данные для продолжения (redirect URL, client secret, payment token — что предусмотрено схемой).

9.3. Клиентская часть: переход к оплате

Варианты:

редирект на hosted checkout;
открытие виджета и выполнение подтверждения;
возврат пользователя на success_url/fail_url после оплаты.

Важно: success_url — это не гарантия успеха. Это элемент UX. Финальный успех определяется сервером.

9.4. Обработка вебхуков

Шаги обработки на вашем сервере:

Принять webhook.
Проверить подпись/аутентификацию.
Проверить, что событие относится к вашему мерчанту/платежу.
Дедуплицировать по event_id.
Поставить в очередь обработку (воркер).
Обновить Payment и Order.
Выполнить бизнес-действие (выдать доступ, отгрузить, активировать подписку).
Записать аудит.

9.5. Сверка (reconciliation)

Даже при идеальных webhooks нужна сверка:

отчёт провайдера по платежам за период;
ваша база заказов/платежей;
выявление расхождений (платёж прошёл, но заказ не обновился; возврат выполнен, но не отражён).

10) Комиссии, выплаты и бухгалтерская реальность

10.1. Из чего складывается стоимость

Часто есть:

комиссия эквайринга/банка,
комиссия провайдера,
комиссии по методам оплаты,
комиссия за возвраты/споры (в зависимости от условий).

10.2. Выплаты и удержания

Деньги обычно поступают не мгновенно, а по графику:

ежедневные/еженедельные выплаты,
возможная задержка на расчёты,
возможные удержания/резервы в риск-сценариях (в некоторых моделях).

10.3. Возвраты и споры (chargeback)

Платёжный сервис обычно предоставляет:

создание возврата по API,
частичный возврат,
статусы возврата,
обработку спорных операций по регламенту (при наличии).

Для продавца важно хранить доказательства оказания услуги/поставки товара (особенно для цифровых услуг и подписок).

11) Когда выбирать агрегатор, а когда прямой эквайринг

11.1. Агрегатор/PSP подходит, если

нужен быстрый запуск;
нужна широкая география и методы оплаты;
нужен единый API и минимум интеграций;
важны готовые антифрод и виджет оплаты.

11.2. Прямой эквайринг подходит, если

крупные обороты и важны ставки;
нужен полный контроль маршрутизации;
есть компетенция сопровождать несколько интеграций;
требуется кастомная логика платежей и риск-менеджмента.

12) Типовые ошибки при внедрении (и как их избежать)

Считать платёж успешным по редиректу на success_url
Правильно: успех фиксируется по серверному статусу и webhook.
Не внедрять идемпотентность
Итог: дубли платежей/возвратов при повторах запросов.
Игнорировать вебхуки
Итог: «платёж прошёл, но заказ не оплатился» — классическая проблема.
Логировать чувствительные данные
Итог: риски утечки и несоответствие требованиям безопасности.
Не делать сверку
Итог: расхождения накапливаются и всплывают в бухгалтерии/поддержке.
Не моделировать статусы как конечный автомат
Итог: хаотичная обработка переходов, баги при возвратах и отменах.

13) Плюсы и минусы использования сервиса приёма платежей

Плюсы

Быстрое подключение и готовая инфраструктура оплаты.
Снижение объёма работы с чувствительными данными (токенизация/hosted checkout).
Поддержка 3-D Secure и стандартных сценариев оплаты.
Антифрод и риск-контуры на стороне провайдера.
Единый API, webhooks, отчёты, инструменты для возвратов.
Масштабируемость под рост транзакций.

Минусы

Зависимость от SLA провайдера и его регламентов.
Комиссии и ограничения по методам оплаты/странам.
Необходимость корректной серверной интеграции (webhooks, идемпотентность, сверка).
Возможные задержки выплат и дополнительные требования (KYC, проверка бизнеса).
Ограничения на кастомную логику по сравнению с собственным процессингом.

14) FAQ

Почему обязательно нужны webhooks?

Потому что браузер пользователя и сеть ненадёжны: пользователь может закрыть вкладку, а финальный статус может обновиться позже. Webhook — канал, по которому провайдер сообщает «что произошло на самом деле».

Как избежать двойного списания?

Использовать идемпотентность для запросов создания/подтверждения, корректно обрабатывать повторы webhook-событий и хранить уникальные идентификаторы событий.

В чём разница между authorization и capture?

Authorization — резерв/проверка средств, capture — фактическое списание. При двухстадийной схеме это разные шаги.

Можно ли хранить карту у себя, чтобы делать подписки?

Технически возможно, но это резко усложняет требования безопасности. Типовой подход — хранить токен у провайдера и использовать его для повторных списаний.

Что считать успешной оплатой в вашей системе?

Только финальный серверный статус платежа, полученный из API/вебхука и записанный в вашу базу транзакций, после чего выполняется бизнес-действие (выдача товара/доступа).

Как тестировать платежи без риска?

Использовать тестовый контур провайдера, тестовые ключи, тестовые карты/методы, а также имитировать негативные сценарии: таймауты, повторные webhook-события, отмены, частичные возвраты.

Статьи