Платёжная система начинается с денег как инварианта: ошибки в повторах, частичных сбоях и порядке событий здесь опаснее любого дефицита производительности.
Кейс связывает в одну архитектуру платёжное намерение, оркестрацию списания, журнал проводок, сверку статусов, антифрод и аудит.
В интервью и архитектурных разборах он быстро показывает, умеете ли вы сначала защищать корректность финансового состояния и только потом говорить о масштабировании.
Идемпотентность
Повторный запрос не должен превращаться во второе списание, даже если клиент, сеть или очередь пытаются выполнить его заново.
Журнал проводок
Одного статуса платежа недостаточно: системе нужен отдельный неизменяемый журнал финансовых эффектов, который можно проверить и восстановить.
Сверка статусов
Внешний провайдер платёжной инфраструктуры и внутренняя БД расходятся по времени, поэтому регулярная сверка обязательна, а не является дополнительной опцией.
Контур платёжного стандарта
Токенизация, минимизация зоны обработки карточных данных и строгие операционные границы важны не меньше, чем скорость пользовательского пути.
Источник
System Design Interview
Классический разбор платёжной архитектуры: оркестрация, журнал проводок и интеграция с платёжным провайдером.
Платёжная система кажется простым API для списания денег ровно до первого тайм-аута на половине транзакции. Дальше начинается распределённая система, где цена ошибки измеряется в реальных деньгах: важны корректность состояний, поведение при частичных сбоях и аккуратное обращение с чувствительными данными. Поэтому строгую гарантию на практике почти не строят напрямую — её собирают из , и регулярной сверки статусов.
Требования
Функциональные
- Создание для заказа и поддержка сценария авторизации с последующим списанием средств.
- Поддержка карт и альтернативных платёжных методов через .
- Идемпотентные операции списания и , включая частичный возврат.
- Приём от платёжного провайдера со статусами `authorized`, `captured`, `failed` и `disputed`.
- История платежей и прозрачный для поддержки и финансовой команды.
Нефункциональные
Доступность: 99.99%
Платежи лежат на критичном пути выручки, поэтому простой сразу превращается в прямой бизнес-ущерб.
Задержка: p95 < 300ms
Checkout должен оставаться быстрым и предсказуемым даже при медленных внешних зависимостях.
Корректность: Без двойного списания
Повторные запросы, тайм-ауты и сетевые сбои не должны приводить к повторному списанию денег.
Безопасность: Минимизация зоны карточных данных
Чем меньше чувствительных карточных данных проходит через платформу, тем ниже операционный риск.
Высокоуровневая архитектура
Платёжная платформа: общая схема
синхронный путь оплаты и асинхронный путь расчётов и сверкиСинхронный путь
Асинхронный путь
Платёжная система разделяет быстрый пользовательский путь оплаты и более долгий асинхронный путь расчётов и сверки.
Главное решение здесь — развести быстрый пользовательский путь оплаты и асинхронный путь расчётов и сверки. Тогда медленный платёжный провайдер бьёт по фоновых задач, а не по checkout, и финансовая восстанавливается сверкой, а не блокировкой пользователя.
Критические потоки
Навигатор по платёжным сценариям
Синхронный путь оплаты и асинхронный путь сверки статусов.
Синхронный путь оплаты: что важно
- Платёжный API создаёт намерение и фиксирует ключ , чтобы повторный запрос не дал второе списание.
- проводит платёж по допустимым переходам состояний
INITIATED -> AUTHORIZED -> CAPTURED. - Адаптер платёжного провайдера изолирует особенности конкретной интеграции от основного платёжного домена.
- Синхронный ответ checkout не ждёт полного цикла расчётов и финальной сверки статусов.
- Промежуточные статусы сохраняются во внутренней базе, чтобы систему можно было корректно восстановить после сбоя.
Асинхронный путь сверки: что важно
- обрабатываются по модели с дедупликацией.
- и outbox фиксируют финансовые эффекты в неизменяемом виде.
- Фоновые задачи сверяют внутренние статусы с отчётами платёжного провайдера и закрывают расхождения.
- Сценарии с пропавшим списанием или несовпадающим возвратом отправляются в очередь ручной дообработки.
- Финансы, поддержка и контур получают события через outbox без прямой связи с платёжным провайдером.
Модель данных (упрощённо)
payment_transactions
- payment_id (UUID), order_id, customer_id
- amount, currency, status, psp_reference
- idempotency_key, created_at, updated_at
ledger_entries
- entry_id, payment_id, account_id
- direction (debit/credit), amount, currency
- entry_type (auth/capture/refund/chargeback)
Надёжность и консистентность
Обязательные паттерны
- Ключ для всех изменяющих операций: авторизации, списания и возврата.
- Транзакционный журнал исходящих событий для публикации без потерь: доставка , а дубликаты снимает идемпотентная дедупликация на потребителе.
- Повторные попытки с , и на вызовах платёжного провайдера.
- со строгими переходами
INITIATED -> AUTHORIZED -> CAPTURED/FAILED/REFUNDED. - Регулярная сверка внутренних статусов, журнала проводок и отчётов платёжного провайдера.
Опасные антипаттерны
- Считать вебхук единственным источником истины: потерянное или задержанное событие тихо разойдётся с реальным состоянием денег, а без сверки расхождение всплывёт только в жалобе.
- Удалять ключ идемпотентности слишком рано или не хранить его вовсе — тогда первый же ретрай после тайм-аута приводит к повторному списанию.
- Держать финансовый статус в одной изменяемой таблице без отдельного журнала изменений: после спора с клиентом восстановить, что и когда произошло, уже нечем.
- Смешивать бизнес-логику checkout и код конкретного провайдера в одном модуле — смена или добавление провайдера превращается в правку платёжного ядра.
- Пропускать PAN/CVV через свою систему там, где этого можно избежать: каждая такая точка расширяет зону действия стандарта PCI DSS и операционный риск.
Минимальные требования по безопасности и соответствию
- : PAN/CVV не должны попадать в основной сервис платформы.
- Взаимная криптографическая аутентификация и сервисная идентичность между внутренними сервисами платёжного контура.
- Строгая ролевая модель доступа для операций возврата и ручного списания.
- Непрерывный для финансовых и операционных действий.
- Границы : чем меньше зона обработки карточных данных, тем ниже операционный риск.
Справка
Payment Intents
Как один и тот же сценарий выглядит у реального провайдера: явные состояния авторизации и списания вместо одного непрозрачного вызова «оплатить».
Связанные главы
- Rate Limiter - Платёжный API лежит на пути выручки — разбираем, как удержать его при всплесках трафика и переборе карт, не уронив честных пользователей.
- API Gateway - Куда вынести аутентификацию, политики доступа и маршрутизацию, чтобы платёжный контур не занимался этим сам.
- Identification/AuthN/AuthZ - Возврат и ручное списание — самые опасные операции; здесь про то, кто и на каком основании имеет к ним доступ.
- Шифрование, ключи и защита трафика - Чем защищён трафик между сервисами платёжного контура: взаимная аутентификация, управление ключами и защита транспорта.