Платёжная система начинается с денег как инварианта: ошибки в повторах, частичных сбоях и порядке событий здесь опаснее любого дефицита производительности.
Кейс связывает в одну архитектуру платёжное намерение, оркестрацию списания, журнал проводок, сверку статусов, антифрод и аудит.
В интервью и архитектурных разборах он быстро показывает, умеете ли вы сначала защищать корректность финансового состояния и только потом говорить о масштабировании.
Идемпотентность
Повторный запрос не должен превращаться во второе списание, даже если клиент, сеть или очередь пытаются выполнить его заново.
Журнал проводок
Одного статуса платежа недостаточно: системе нужен отдельный неизменяемый журнал финансовых эффектов, который можно проверить и восстановить.
Сверка статусов
Внешний PSP и внутренняя БД расходятся по времени, поэтому регулярная сверка обязательна, а не является дополнительной опцией.
Контур PCI DSS
Токенизация, минимизация зоны обработки карточных данных и строгие операционные границы важны не меньше, чем скорость пользовательского пути.
Источник
System Design Interview
Классический разбор платёжной архитектуры: оркестрация, журнал проводок и интеграция с платёжным провайдером.
Платёжная система — это не просто API для списания денег. Это распределённая система, в которой важны корректность состояний, устойчивость к частичным сбоям и аккуратная работа с чувствительными данными. На практике гарантия обычно заменяется сочетанием , и регулярной сверки статусов.
Требования
Функциональные
- Создание для заказа и поддержка сценария авторизации с последующим списанием средств.
- Поддержка карт и альтернативных платёжных методов через .
- Идемпотентные операции списания и , включая частичный возврат.
- Приём от платёжного провайдера со статусами `authorized`, `captured`, `failed` и `chargeback`.
- История платежей и прозрачный для поддержки и финансовой команды.
Нефункциональные
Доступность: 99.99%
Платежи лежат на критичном пути выручки, поэтому простой сразу превращается в прямой бизнес-ущерб.
Задержка: p95 < 300ms
Checkout должен оставаться быстрым и предсказуемым даже при медленных внешних зависимостях.
Корректность: Без двойного списания
Повторные запросы, тайм-ауты и сетевые сбои не должны приводить к повторному списанию денег.
Безопасность: Минимизация зоны PCI DSS
Чем меньше чувствительных карточных данных проходит через платформу, тем ниже операционный риск.
Высокоуровневая архитектура
Платёжная платформа: общая схема
синхронный путь оплаты и асинхронный путь расчётов и сверкиСинхронный путь
Асинхронный путь
Платёжная система разделяет быстрый пользовательский путь оплаты и более долгий асинхронный путь расчётов и сверки.
Ключевой паттерн здесь — разделить быстрый пользовательский путь оплаты и асинхронный путь расчётов и сверки. Это снижает для пользователя и помогает удерживать финансовую даже при нестабильности внешних зависимостей.
Критические потоки
Навигатор по платёжным сценариям
Синхронный путь оплаты и асинхронный путь сверки статусов.
Синхронный путь оплаты: что важно
- Платёжный 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)
Надёжность и консистентность
Обязательные паттерны
- Ключ для всех изменяющих операций: авторизации, списания и возврата.
- Transactional outbox для публикации событий без потерь и без дублирования.
- Повторные попытки с , и на вызовах PSP.
- со строгими переходами
INITIATED -> AUTHORIZED -> CAPTURED/FAILED/REFUNDED. - Регулярная сверка внутренних статусов, журнала проводок и отчётов платёжного провайдера.
Опасные антипаттерны
- Считать вебхук единственным источником истины и не проводить регулярную сверку.
- Не хранить ключ идемпотентности или удалять его слишком рано.
- Записывать финансовый статус в одну изменяемую таблицу без отдельного журнала изменений.
- Смешивать бизнес-логику checkout и код конкретного платёжного провайдера в одном модуле.
- Обрабатывать PAN/CVV внутри своей системы, если этого можно избежать.
Минимальные требования по безопасности и соответствию
- : PAN/CVV не должны попадать в основной сервис платформы.
- mTLS и сервисная идентичность между внутренними сервисами платёжного контура.
- Строгий RBAC для операций возврата и ручного списания.
- Непрерывный для финансовых и операционных действий.
- Границы : чем меньше зона обработки карточных данных, тем ниже операционный риск.
Справка
Payment Intents
Практический пример платёжного сценария с явными состояниями авторизации и списания.
Связанные главы
- Rate Limiter - Как защитить платёжный API от всплесков трафика, злоупотреблений и перегрузки критического пути.
- API Gateway - Единая точка входа, политики доступа и маршрутизация перед платёжным контуром.
- Identification/AuthN/AuthZ - Управление доступом к списаниям, возвратам и чувствительным финансовым операциям.
- Шифрование, ключи и TLS - Криптографическая защита платёжного контура: mTLS, управление ключами и защита трафика.