Разработка депозитной системы для торговой платформы — это построение контролируемого финансового процесса от запроса клиента на пополнение до появления доступных средств на торговом счёте или в wallet. Надёжная система не увеличивает баланс только потому, что браузер вернулся со страницы оплаты или провайдер показал пользователю успешный экран. Сначала она создаёт внутреннюю запись депозита, проверяет аутентифицированный callback провайдера, применяет продуктовые и риск-контроли, а затем выполняет единственную аудируемую проводку в ledger.
Для брокера, криптобиржи, prop-trading продукта или мультивалютного wallet это критично. Слабый процесс пополнения приводит к двойным кредитам, зачислению не на тот счёт, потере платежей в статусе pending, ошибкам конвертации и расхождениям между данными провайдера и внутренними остатками. В рамках услуги FinTech и trading-системы команда POLADO проектирует такие решения вместе с back-office, аудитом и операционными процессами.
Почему депозиту нужна модель транзакций, а не только интеграция gateway
После выбора суммы, валюты и метода оплаты платформа должна создать внутренний payment intent или deposit transaction. Эта сущность становится постоянной точкой отсчёта: она связывает клиента, целевой wallet или торговый счёт, запрошенную сумму и валюту, провайдера, метод оплаты, время истечения, ожидаемый внешний идентификатор и начальный статус.
Return URL из hosted checkout нужен для пользовательского интерфейса, но не является финансовым доказательством. Пользователь может закрыть страницу, редирект может задержаться, а данные браузера нельзя считать доверенным источником. Решение о зачислении должно опираться на server-to-server событие с проверенной подписью; в отдельных сценариях его следует дополнительно подтвердить запросом статуса через API провайдера.
Практическая внутренняя модель статусов
- created — запрос на пополнение принят, но сессия у провайдера ещё не создана.
- awaiting_payment — пользователь получил checkout, банковские реквизиты или адрес; подтверждения оплаты пока нет.
- provider_processing — провайдер обрабатывает операцию, окончательный результат неизвестен.
- received — проверенное событие подтвердило получение средств или авторизацию согласно данному методу; внутренние проверки ещё не завершены.
- under_review — операция ожидает решения из-за риска, compliance-проверки или несоответствия данных.
- credited — wallet пополнен проводкой в ledger, а средства доступны в соответствии с правилами продукта.
- failed, expired, reversed, refunded — отдельные конечные либо компенсирующие исходы.
Не копируйте статусы провайдера напрямую в бизнес-логику продукта. Храните внешний статус отдельно, а внутренний используйте для ответа на вопрос: что платформа вправе сделать со средствами клиента? Так несколько провайдеров можно свести к единой операционной и аудиторской модели.
Проверенные callbacks провайдера как канал доказательств
Обработчик webhook/callback — это граница безопасности. Принимайте события только по TLS, проверяйте подпись провайдера по неизменённому raw body запроса, применяйте допустимое окно timestamp/replay, если оно предусмотрено, и сохраняйте уникальный provider event ID. Непроверенный payload не должен менять статус депозита и тем более создавать кредит в wallet.
После проверки и надёжного сохранения событие следует быстро подтвердить и передать в асинхронную обработку. Провайдеры повторяют delivery при timeout, события могут прийти не по порядку, а HTTP 200 означает лишь принятие callback-а, а не завершение ledger-проводки. Сохраняйте raw payload, результат проверки подписи, время получения, тип события и поля корреляции в неизменяемом event record; доступ к этому содержимому должен быть ограничен.
Идемпотентность нужна на трёх уровнях
- Запрос клиента: при создании депозита клиент отправляет idempotency key. Повтор мобильного запроса должен вернуть исходный intent или checkout session, а не создать новую попытку оплаты.
- Событие провайдера: уникальное ограничение для event ID делает повторный callback безопасным.
- Зачисление в ledger: для внутреннего deposit transaction и типа проводки допускается только один кредит. Параллельные worker-ы и дубликаты событий не создают второй баланс.
Проверки вида «уже зачислено?» только в коде приложения недостаточно. Нужны уникальные ограничения БД и атомарная транзакция вокруг решения и проводки; для конфликтующих операций — корректные блокировки строк или serializable-обработка. OWASP рекомендует постоянные idempotency keys и транзакционное сохранение результата для внешних неидемпотентных действий, а также защищённое TLS-взаимодействие между сервисами с чувствительными данными.
Зачисляйте средства через контролируемые проводки ledger
Событие провайдера со статусом “paid” не должно превращаться в команду balance = balance + amount. Сервис зачисления повторно проверяет состояние депозита, связь клиента и счёта, принятую валюту, внешний transaction reference, фактически полученную сумму и ограничения. Затем он создаёт сбалансированную неизменяемую проводку: например, дебет счёта расчётов с провайдером и кредит обязательства по клиентским средствам.
Это особенно важно, если продукт различает доступные деньги, бонусные средства, маржинально допустимое обеспечение, заблокированные средства и средства с ограничением на вывод. Политика депозита должна однозначно определять, в какой bucket попадает сумма и когда она становится доступной для торговли или вывода. Эти правила должны одинаково использоваться в модулях торговли, риска, вывода и отчётности. Основу подхода раскрывает материал о неизменяемой double-entry архитектуре ledger.
Явное сопоставление валют, счетов и сумм
Значение «100» не является полным финансовым фактом. Сохраняйте сумму в minor units, ISO-валюту, валюту settlement у провайдера, валюту целевого wallet, источник и timestamp FX-курса, обработку комиссии, правило округления и внешние идентификаторы. Если провайдер получает EUR, а клиенту зачисляется USD на торговый wallet, заранее определите момент конвертации, применяемый курс, место учёта спреда или комиссии и доказательства для последующего разбора.
Карты, банковские переводы, open banking, локальные методы оплаты и on-chain переводы можно подключать через общий adapter interface, но их характеристики подтверждения и отмены различаются. Поэтому статус, при котором разрешена торговля, не всегда означает экономическую необратимость платежа. При необходимости отдельно определяйте доступность для торговли, доступность для вывода и риск последующего reversal.
Очередь ручной проверки вместо таблиц и переписки
Автоматизация не означает, что каждый депозит нужно зачислять автоматически. В under_review могут попадать операции выше лимита, первое пополнение, несовпадение имени, повтор provider reference, подозрительная частота, правило юрисдикции или риск конкретного метода оплаты. Оператору нужны reason code, данные клиента и KYC-статус, timeline callback-ов, идентификаторы провайдера, связанные проводки и ясная история решения.
Полезный back-office включает поиск и фильтры, разграничение ролей, просмотр доказательств, принцип четырёх глаз для чувствительных override-действий и audit log: кто, когда и почему одобрил, отклонил или скорректировал операцию. KYC должен оставаться самостоятельным контролируемым процессом, но передавать депозитному модулю нужный результат eligibility. Связанные принципы рассмотрены в материале о KYC onboarding для торговой платформы.
Ежедневная reconciliation подтверждает полноту процесса
Сверка — не только задача финансовой команды в конце месяца. Ежедневный автоматизированный процесс должен сопоставлять settlement-отчёты или API провайдера с внутренними deposit transaction, сохранёнными provider event-ами, проводками ledger и движениями по clearing/банковским счетам. Он помогает быстро найти незачисленные подтверждённые платежи, неподтверждённые кредиты, разницы по сумме или валюте, поздние reversal и комиссии settlement.
- Каждый provider transaction reference связан максимум с одним внутренним депозитом.
- Каждый credited deposit имеет ровно одну соответствующую проводку по клиентским средствам.
- Gross receipt, комиссия провайдера, reversal и net settlement учитываются раздельно, а не одной непрозрачной суммой.
- Несопоставленные строки попадают в очередь исключений с владельцем, reason code, приоритетом и историей решения.
- Исправления создают новые одобренные компенсирующие записи, а не переписывают исходный финансовый факт.
Вопросы архитектуры до выбора и интеграции провайдера
- Какие юридические лица, страны, валюты и методы оплаты входят в первый релиз?
- Какое событие провайдера достаточно для кредита и когда нужен повторный запрос статуса через API?
- Как без неоднозначности связаны provider customer ID, пользователь платформы, wallet и торговый счёт?
- Что увидят клиент и операционная команда при pending, failed, expired, reversed, chargeback и refund?
- Какие KYC, AML, лимиты и риск-сигналы создают hold или manual review?
- Когда средства доступны для торговли, для вывода или ограничены для обоих действий?
- Каковы retry, alerting и incident runbook для недоступности провайдера, задержанных callback-ов и сбоев reconciliation?
- Кто отвечает за ежедневные исключения и какие полномочия требуются для корректировки?
Для карточных платежей hosted payment components и токенизированные потоки, при которых данные карты не проходят через ваше приложение, могут уменьшить объём риска. Однако они не отменяют автоматически все применимые обязанности PCI DSS. Scope зависит от фактических потоков данных, связанных систем и контрмер. PCI SSC также указывает, что токенизация в отдельных реализациях способна сократить scope, но не заменяет оценку и соблюдение применимых требований.
Спланируйте депозитный контур, готовый к росту
Production-ready депозитный модуль — это не только checkout widget. Это state machine транзакций, слой provider adapters, контролируемый wallet ledger, back-office, мониторинг и процесс reconciliation. POLADO может помочь определить scope нового funding flow для брокера или wallet, заменить хрупкую платёжную логику либо спроектировать многопровайдерскую модель вокруг реальных сценариев ошибок. Если вашей команде нужны надёжные контроли депозитов до масштабирования привлечения и пополнений, обратитесь в POLADO за технической консультацией.