Автор: Аван, веб-юрист
Цифровые платежи уже вошли в массы, но расчеты еще нет.
Это мнение Дэна Моттиса, бывшего высокопоставленного сотрудника Visa и основателя Beam. Транзакции Visa авторизуются в любом торговом пункте по всему миру, но расчеты все еще проходят через SWIFT — агрегируются пакеты транзакций, средства переводятся через трансграничные банковские переводы, проходят через местное регулирование, праздничные дни и многоуровневые промежуточные банки, после чего торговцы ждут поступления средств. Это не проблема Visa, а структурная задолженность всей отрасли. А PSP — это место, где эта задолженность сосредоточена наиболее сильно.
Настоящая статья фокусируется на поставщиках платежных услуг (PSP), которые эволюционировали от простых инструментов для приема платежей до ключевой инфраструктурной платформы, управляющей потоками资金, расчетами и бухгалтерским учетом. Изначально они были созданы для более простой эпохи — одноканальной системы, линейных процессов транзакций и высокоинтегрированной инфраструктуры.
В современной платежной среде «платеж» больше не является единичной транзакцией, а представляет собой серию изменений состояний, охватывающих несколько участников и платежных каналов. Сегодня платеж может включать: приложения для конечных пользователей, PSP, поставщиков услуг по борьбе с мошенничеством и верификацией личности, хранящие банки, один или несколько платежных каналов, а также внутренние бухгалтерские системы компании.
Компании должны поддерживать одновременно банковские карты, ACH, банковские переводы, RTP, FedNow и все больше расчетов на основе стабильных монет. Каждый канал имеет различные сроки расчетов, режимы отказа, форматы данных и операционные требования.
В этой статье представлены рекомендации Modern Treasury, которые исследуют, как PSP эволюционировали, как должна адаптироваться их базовая архитектура для современных платежных систем, а также какую стратегию должны применять команды, создающие платежные продукты, при выборе следующего PSP.
Основной вывод
01｜Цифровые платежи вошли в массы, но расчеты — нет. Visa позволяет вам совершать авторизацию в любом магазине по всему миру, но сам расчет все еще происходит через SWIFT. Интерфейс решен, а базовая инфраструктура — нет.
02｜PSP выполняет платеж, но не объясняет движение средств. Stripe сообщает вам, что произошло на его участке, но не может сказать, в каком реальном состоянии находятся эти деньги сейчас. Исполнение и учет — это две разные вещи.
03｜ Каждая платежная система — это отдельная операционная система, а не вариация одной модели. ACH можно отменить, RTP — нельзя; карточные сети допускают споры, а стабильные монеты имеют окончательное подтверждение в цепочке. Абстрактный слой PSP скрывает эти различия, но только до тех пор, пока не возникнут проблемы.
04｜Платежы в реальном времени устранили буферы, контроль должен быть смещен вперед. Логика управления рисками, одобрения и сверки традиционных PSP предполагала, что «если произошла ошибка, есть время исправить ее». RTP и FedNow сделали это предположение невозможным. Решения должны приниматься до перемещения средств, а не после.
05｜Стабильные монеты — это расчетная система, а не новый способ оплаты. Они решают не проблему интерфейса оплаты, а задержку между «завершением учета» и «реальным поступлением средств». Самый практичный путь внедрения — это трехслойная структура: фиатные деньги входят, осуществляется оборот на блокчейне, фиатные деньги выходят — конечные пользователи не должны понимать стабильные монеты.
06｜Средства в пути могут приносить доход, что практически невозможно в традиционной системе. При международных платежах средства замораживаются на 24–72 часа до завершения расчетов, не принося дохода и блокируя оборотный капитал. Стабильные монеты впервые позволяют «движущимся средствам» также генерировать ценность.
07｜支付运营最大的失败，是无法回答一个简单问题：这笔钱去哪了。对账、异常处理、流动性管理——这些问题不在支付发起时出现，而是在事后出现。没有统一的协调层，每个服务商只能告诉你它自己那一段的故事。
08｜Настоящий стратегический риск — не в том, используете ли вы стабильные монеты. А в том, что ваши конкуренты перестроили свои затраты на расчеты и эффективность капитала с помощью стабильных монет, а вы всё ещё ждете идеального момента для входа.
I. Историческое развитие PSP
За последние двадцать лет роль PSP претерпела фундаментальные изменения.
В ранние годы электронной коммерции PSP в основном функционировали как платежные шлюзы. Их задачи были просты и ясны: соединять продавцов с карточными сетями и эквайерами, обеспечивая авторизацию и расчет транзакций.
Эти системы PSP были разработаны для очень специфического мира. Платежи осуществляются в основном через карты, проходят через единый счет продавца и следуют линейному жизненному циклу от авторизации до расчета. PSP оптимизированы для эффективной обработки транзакций в рамках этой модели.
В 2010-е годы Marketplace, SaaS-платформы и финтех-продукты начали напрямую интегрировать платежи в свои продукты. Платформам требовалось завершить процесс регистрации пользователей, распределять платежи между несколькими сторонами и управлять выплатами. PSP соответственно расширились, добавив инфраструктуру для регистрации мерчантов, выплат и инструменты защиты от мошенничества.
Однако, несмотря на постоянное расширение возможностей PSP, их базовая архитектура по-прежнему основана на модели, разработанной для линейных платежных процессов — в первую очередь оптимизированной для обработки транзакций, а не для координации сложных многоэтапных перемещений средств через несколько сервисов и каналов.
К началу 2020-х годов компании начали работать по нескольким направлениям, в различных регионах и в различных сценариях. Традиционные PSP продолжали объединять множество компонентов, позволяя компаниям взаимодействовать с одной платформой. Однако по мере усложнения платежных процессов один платежный процесс может охватывать несколько этапов: верификация личности, проверка рисков, принятие решения о финансировании, выполнение канала, внутренний учет.
Это изменение превратило роль PSP из «соединителя» в «координатора», но их архитектура не развивалась с той же скоростью.
The result is: PSP still handles fund transfers, but operates within a more complex, full transaction payment lifecycle.
II. Современный стек технологий PSP-платежей
Чтобы понять ограничения PSP, необходимо сначала понять более широкую платежную среду, в которой они функционируют.
2.1 Технологический стек PSP
Современная платежная среда — это не одна платформа или служба, а набор многоуровневых компонентов инфраструктуры, совместно обеспечивающих перемещение, расчет и учет средств.
Уровень приложений: платформы электронной коммерции, инициирующие платежи, Marketplace, финтех-приложения, SaaS-продукты с встроенной оплатой.
Уровень PSP: отвечает за выполнение платежных инструкций, таких как маршрутизация транзакций через платежные сети, инициирование банковских переводов и подключение к платежным каналам. В большинстве случаев эта нижележащая сложность абстрагирована за интерфейсом PSP, и пользователь взаимодействует с единой системой, а не напрямую с несколькими поставщиками, стоящими за ней.
Комплаенс-уровень: Современные платежные процессы также зависят от провайдеров верификации личности, инструментов обнаружения мошенничества и комплаенс-инфраструктуры, которые определяют, следует ли разрешить проведение платежа.
Банковский уровень: Контролируемые банки хранят средства, предоставляют регулируемые счета и обеспечивают доступ к платежным сетям, таким как ACH, банковские переводы, RTP и FedNow.
Внутренний уровень сверки: система, используемая предприятиями для отслеживания балансов, обозначения статуса транзакций и ведения согласованных записей финансовой деятельности.
Каждый из вышеперечисленных уровней играет роль в движении средств, но ни один из них не предоставляет полной картины того, что происходит после инициации платежа. Именно поэтому внутренний уровень сверки становится незаменимым.
2.2 Синхронные и асинхронные
У традиционных PSP есть фундаментальный дефект дизайна: они просто отправляют деньги, не отслеживая, что происходит после отправки.
Проблема в том, что «после отправки» — это именно та часть, которая наиболее сложна в оплате.
API-интерфейс PSP синхронен — вы отправляете команду, и он возвращает результат. Однако реальные финансовые потоки асинхронны: расчеты завершаются позже, ошибки проявляются с задержкой, а возвраты и корректировки могут произойти в любое время. Это несоответствие создает постоянную информационную дыру.
Конкретное проявление черной дыры — это фрагментация состояния:
Ни один узел не может сообщить вам, каково настоящее состояние этих средств прямо сейчас.
Например, при выводе средств продавцом на маркетплейсе весь процесс представляет собой длинную цепочку: проверка квалификации → риск-менеджмент и соответствие нормам → подтверждение средств → отправка инструкции → выполнение транзакции → возврат подтверждения → постфактум-расчеты → обновление учетных записей. PSP охватывает только несколько средних этапов; принятие решений на начальном этапе и сверка на заключительном не входят в его обязанности. Если перевод не удастся или будет возвращен, ни одна система не сможет предоставить полный ответ.
Вот в чем заключается смысл существования внутреннего уровня сверки: он не заменяет PSP в выполнении платежей, а создает единый уровень наблюдения над всей цепочкой — непрерывно преобразуя асинхронные события от разных провайдеров, с разными временными метками и в разных форматах, в единую, надежную внутреннюю对企业 состояние. Независимо от того, через сколько промежуточных звеньев прошли деньги, всегда есть место, где можно ответить на самый простой вопрос: где именно находятся эти деньги сейчас.
Три. Ограничения традиционных PSP в оплате
Абстрактный уровень традиционных PSP построен вокруг платежей по банковским картам — авторизация, захват, расчет, жизненный цикл предсказуем. Хотя существуют исключения (например, споры и возвраты), общая структура предсказуема и хорошо понятна. Эта модель определила способ проектирования PSP.
С появлением новых способов оплаты PSP расширил поддержку на другие каналы, но поведение этих каналов отличается от поведения банковских карт и не соответствует тем же предположениям:
- ACH-переводы: введена задержка, а также возможен возврат платежа в течение нескольких дней после его инициации.
- Wire transfer: Faster settlement, but typically requires manual processes and higher costs.
- Сети мгновенных платежей, такие как RTP и FedNow: обеспечивают мгновенное перемещение средств, но после завершения транзакции они, как правило, необратимы.
- Перевод стабильных монет: осуществляется на совершенно другой инфраструктуре с другими механизмами защиты и операционными соображениями.
На примере перевода средств американской компанией филиппинскому поставщику:
- ACH-переводы поступают за T+2, но филиппинские банки не принимают ACH напрямую — требуется дополнительный перевод через локальную систему, поэтому фактическое поступление может занять T+4; в течение этого периода перевод может быть отклонен из-за несоответствия данных счета.
- Используйте банковский перевод — быстрее, но подайте заявку до 15:00, до окончания приема переводов; в случае праздников срок продлевается. Комиссия SWIFT составляет от 25 до 45 долларов США, а банк получателя может дополнительно удержать комиссию за корреспондентский банк, в результате чего сумма на счете получателя не совпадет с отправленной суммой.
- Используйте стабильную монету в виде сэндвича: USDC отправляется с американского счета, подтверждение в цепочке занимает несколько секунд, после получения партнером на Филиппинах монета конвертируется в песо и зачисляется на местный счет — весь процесс занимает менее одного часа, а стоимость ниже 1% от суммы перевода.
Три пути, одни и те же деньги, разница во времени расчета — 96 часов, разница в затратах — десятки долларов, и полная разница в прослеживаемости. Это не различие в пользовательском опыте продукта, а различие между тремя операционными системами. Абстрактный уровень PSP не может скрыть эти различия — он лишь передает их разработчикам и операционным командам для решения.
Это не варианты одной и той же платежной модели, а совершенно разные модели операций.
Традиционные PSP решают эту проблему, предоставляя разные API и определения состояний для каждого маршрута — вместо того чтобы действительно унифицировать различия, они просто перекладывают их на разработчиков. Инженерные команды начинают писать специальную логику для каждого маршрута, операционные команды начинают вручную обрабатывать различные режимы сбоев, а финансовые команды начинают сверять однотипные транзакции, прошедшие совершенно разные пути.
Это и есть утечка абстракции: сложность треков, которая должна была быть скрыта, начинает проникать на уровень приложения.
По мере добавления все большего количества каналов платежная среда превратилась в серию слабо связанных интеграций, а не в единую абстрактную прослойку. На более медленных каналах задержка создает окно времени для выявления проблем. На реальном канале это окно исчезает — платежи завершаются за несколько секунд, ошибки невозможно легко отменить, а решения должны приниматься до перемещения средств, а не после.
Четвертый: Реальная оплата вынуждает ПСП сдвинуть контроль вперед
Переход на сеть реального времени платежей — это не просто ускорение скорости движения средств, а фундаментальное изменение требований к проектированию платежной инфраструктуры.
В эпоху ACH и банковских переводов время служит буфером.
ACH-переводы могут занимать несколько дней для завершения, операции с банковскими картами могут оспариваться после авторизации, а банковские переводы часто требуют ручной проверки. Хотя эти задержки снижают эффективность, они также предоставляют возможность выявить ошибки, вмешаться в подозрительную активность и сверить данные до окончательного завершения расчетов.
Традиционная модель PSP была построена вокруг этого буфера.
Однако такие системы реального времени, как RTP и FedNow, полностью нарушили это предположение. Средства мгновенно переводятся между счетами за несколько секунд, и после завершения платежа он, как правило, необратим.
- Обнаружение мошенничества должно быть завершено раньше
- Комплаенс-проверка должна проводиться в реальном времени
- Финансовые решения должны быть точно приняты в момент освобождения платежа
- Возможность исправить ошибки после события больше не существует
Платформы, предлагающие мгновенные выплаты, не могут полагаться на рабочие процессы, разработанные для отложенного расчета. Внутренние системы предприятий, управляющие платежами через несколько счетов, не могут в момент выполнения точно определить ликвидность. Служба поддержки не может гарантировать возможность отмены, когда базовая инфраструктура просто не позволяет этого.
Результатом является передача ответственности: PSP должны развиваться, чтобы поддерживать внутренние системы, которые определяют, когда следует выполнять платежи. Другими словами, контроль должен смещаться вперед.
Инфраструктура платежей должна быть спроектирована так, чтобы одобрение, логика средств, проверка рисков и верификация статуса были завершены до движения средств, а не после. Это требует более согласованного представления о балансах, статусах транзакций и условиях между сервисами, чем могут предоставить традиционные архитектуры PSP.
Реальный трек — это не конечное состояние, а всего лишь переломный момент. После поступления стабильных монет проблема перейдет на следующий уровень.
Пять: Стабильные монеты: новый трек, а не новый способ оплаты
Самое частое заблуждение в отношении стабильных монет — это воспринимать их как новый платежный продукт. Это не так. Это новый расчетный канал, решающий проблему задержки между «завершением учета» и «реальным поступлением средств».
В отличие от карт, ACH и банковских переводов, сделки со стабильными монетами происходят на блокчейн-сетях:
- Settlement is ongoing, not batched
- Практически мгновенная финальная подтверждённость (зависит от сети)
- Работает 7×24 часа, без ограничений по банковским срокам и праздничным дням
- Not dependent on specific domestic payment systems
- Примитивы для отслеживания баланса, права собственности и истории транзакций совершенно разные
Традиционная архитектура PSP построена вокруг интеграции с банками и платежными сетями, тогда как стабильные монеты вводят сети, не зависящие от этих посредников. Источник, расчет и учет происходят за пределами первоначальной архитектуры. Предприятию может потребоваться одновременная координация банковских каналов, сетей в реальном времени и блокчейн-расчетов, при этом каждый тип предполагает разные представления о финализации, временных рамках и контроле — эти различия нельзя унифицировать с помощью единого API, и позиция PSP как единого абстрактного уровня становится все более неустойчивой.
Как системы реального времени оплаты поставили под сомнение предположения о временной последовательности и отменяемости, стабильные монеты ставят под сомнение предположения о месте и способе осуществления платежей.
В этом процессе они ввели новый уровень сложности.
Стабильные монеты — это наиболее практичный текущий путь реализации: фиат в → оборот в блокчейне → фиат из.
Клиенты и поставщики на обоих концах сделки не обязаны понимать стабильные монеты — стабильные монеты служат лишь промежуточным каналом, специально предназначенным для решения проблем медленной, дорогой и нестабильной традиционной международной расчетной системы. Наиболее ценное применение сосредоточено на «трудных каналах» — международных сценариях, где традиционные методы медленны, дороги или вообще недоступны.
Компании не должны и не должны полностью переходить на стабильные монеты; реальный путь — выбрать один-два конкретных варианта использования для частичной замены, сформировать понимание, а затем масштабировать.
Стабильные монеты также добавляют дополнительный измерение: доход от средств в пути, чего практически не существует в традиционных системах. В традиционных платежных процессах средства находятся в ожидании от отправки до зачисления в течение 24–72 часов, не принося никакого дохода и блокируя оборотный капитал. Стабильные монеты на блокчейне могут генерировать доход в процессе движения — это не незначительная оптимизация стоимости платежей, а полная перестройка логики эффективности капитала.
Шесть: Текущая экосистема: десять уровней разделения труда и отсутствующий уровень
По мере того как платежная инфраструктура охватывает все больше каналов, поставщиков и типов инфраструктуры, определение роли PSP становится все более сложным.
Ранее обязанности по управлению движением средств внутри единого PSP теперь распределены по нескольким уровням технологического стека.
Работа PSP больше не ограничивается просто перемещением средств, а включает в себя интерпретацию потоков средств.
Это изменение отражает более глубокие сдвиги: самого выполнения уже недостаточно. PSP теперь должны поддерживать внутренние системы предприятий, чтобы те могли отображать, вести учет и сверять, как средства перемещаются между различными средами.
① Платформа уровня продукта: интеграция платежей в программное обеспечение
Платформы специализированного программного обеспечения, такие как Shopify, Square, Toast, Mindbody, ServiceTitan и Housecall Pro, интегрируют платежи непосредственно в свои продукты.
В этих сценариях оплата интегрирована в опыт использования приложения, а не обрабатывается как отдельная платежная система. Эти платформы обычно полагаются на базовые PSP, банковские партнеры и поставщиков инфраструктуры, добавляя еще один уровень абстракции между приложением и потоком средств.
② Уровень исполнения: перемещение средств между орбитами
Основу технологического стека составляют сервисы, отвечающие за обработку платежей, такие как Stripe, Adyen, Checkout.com, Worldpay, PayPal, Nuvei, dLocal — традиционные PSP, задача которых — подключать компании к платежным системам и обеспечивать перемещение средств.
Они остаются ключевыми компонентами платежного стека, но работают в основном на уровне выполнения — инициируют платежи, сообщают о статусе, предоставляют API, но сами по себе не предоставляют полной модели того, как средства перемещаются между сервисами и внутренними системами.
Вы спрашиваете Stripe: «Где именно эти деньги сейчас?», и она может сообщить вам только то, что произошло на её участке. Stripe — это лишь один из узлов; в этой транзакции могут участвовать еще четыре-пять этапов, включая PSP, банк, платежную систему и внутренние книги, но она видит всегда только частичную картину, а не полную.
③ Уровень компоновки и маршрутизации: подключение поставщиков исполнения
По мере того как компании внедряют несколько PSP и способов оплаты, появляются оркестрационные платформы, отвечающие за маршрутизацию через различных провайдеров. Компании, такие как Primer, Gr4vy, Spreedly, Paydock и CellPoint Digital, позволяют предприятиям направлять транзакции в зависимости от географии, стоимости или производительности. Эти системы повышают гибкость уровня выполнения, но не предоставляют единую модель поведения после инициации платежа.
④ Уровень управления рисками и соответствия: решение о том, следует ли перемещать средства
Группа независимых поставщиков услуг отвечает за определение, следует ли разрешить платеж. Системы верификации личности, обнаружения мошенничества и соответствия требованиям таких поставщиков, как Persona, Sardine, Alloy, Unit21, Sift и Sumsub, оценивают пользователей и транзакции до их выполнения. В реальном времени эти решения должны быть приняты до перемещения средств, поэтому ключевая логика управления была перемещена за пределы PSP.
⑤ Уровень банковской инфраструктуры: хранение средств и поддержка подключения
Трастовые банки, такие как Cross River Bank, Lead Bank, Column и Sutton Bank, предоставляют регулируемые счета и доступ к платежным сетям. Они хранят средства клиентов, управляют ликвидностью и выступают в качестве шлюзов для подключения к таким системам, как ACH, банковские переводы, RTP и FedNow. Этот уровень критически важен для доступа к финансовой системе, но функционирует независимо от логики приложения и API PSP.
⑥ Уровень выпуска карт: расширение функций оплаты
Платформы выпуска карт, такие как Marqeta, Lithic и Rain, позволяют компаниям выпускать дебетовые и кредитные карты в качестве части своих продуктов, поддерживая сценарии использования, такие как управление расходами, корпоративные карты и рынки потребления. Платформы выпуска карт соединяют банки и платежные сети, но функционируют как отдельный уровень в технологическом стеке, добавляя дополнительные рабочие процессы, механизмы контроля и состояния, требующие координации с другими частями платежного технологического стека.
⑦ Уровень платежной инфраструктуры: базовая исполнительная сеть
Платежные каналы — это сети, перемещающие средства между финансовыми учреждениями. Традиционные каналы включают ACH, банковские переводы и платежные сети, тогда как новые сети, такие как RTP и FedNow, поддерживают мгновенное зачисление. Каждый канал основан на разных предположениях относительно временных рамок, окончательности и отменяемости, создавая несоответствия, которые PSP должны либо раскрывать, либо обходить (а не полностью абстрагировать).
⑧ Сетевой уровень стабильных монет: расширение за пределы банковской инфраструктуры
Сети стабильных монет, такие как Ethereum, Solana, Polygon и Base, ввели новую форму инфраструктуры для платежей, функционирующую вне традиционной банковской системы. Эти сети обеспечивают перевод цифровых долларов на глобальной инфраструктуре с использованием различных моделей расчетов и механизмов обеспечения. Они расширяют границы платежных систем за пределы банковских каналов, добавляя дополнительный уровень сложности, который необходимо интегрировать в существующие рабочие процессы.
⑨ Уровень «Банк как услуга»: подключение приложений к банкам
Платформы банковских услуг (BaaS), такие как Unit, Galileo и Treasury Prime, предоставляют инфраструктуру для подключения финтех-приложений к регулируемым банкам. Они позволяют компаниям предлагать услуги счетов, карт и платежей, не будучи банками. Этот уровень упрощает доступ к банковской инфраструктуре, но добавляет еще одного посредника между приложением, PSP и базовыми финансовыми потоками.
⑩ Отсутствующий уровень: единый PSP, охватывающий полный жизненный цикл потоков средств
Просматривая все девять уровней, можно заметить единую закономерность: каждый поставщик услуг отвечает за определенную функцию, и ни один из них не может предоставить полную картину движения средств — включая понимание, контроль и сверку.
Обработка выполнения осуществляется одним поставщиком, принятие решений о рисках — другим, средства хранятся в банке, а процесс оплаты может охватывать сети карт, реальное время и блокчейн-системы. Каждая система предоставляет разные данные, временные рамки и определения состояний.
В фрагментированной среде эта проблема не проявляется на этапе инициации — она возникает позже: когда система расходится, средства задерживаются или возвращаются, а команда нуждается в ответах. Именно здесь начинает разрушаться платежная система.
Семь. Где именно сбоит платежная операционная система
В пятницу в 14:55 финансовая команда отправила банковский перевод поставщику на сумму 50 000 долларов США. В 15:00 завершился лимит банковских переводов. Система показывает «отправлено», но подтверждающее письмо не пришло.
В 16:00 поставщик отправил сообщение, запросив статус платежа. Финансовый отдел проверил бэкенд PSP — отображалось «В обработке». Затем проверили банковский счет — отображалось «Ожидает расчета». Две системы, один и тот же платеж, два разных статуса — ни одна из них не сообщает, где именно находится деньги сейчас.
В пятницу в 17:00 служба поддержки банка заканчивает работу. Поставщик ждет перевода средств для организации доставки на выходные. Финансовая команда не знает, что сказать поставщику, и не уверена, поступят ли деньги автоматически в понедельник утром или были возвращены и требуют повторной отправки.
Это не экстремальная ситуация, а сценарий, с которым команда платежных операций сталкивается каждую неделю. Его не найдешь в руководстве по продукту PSP, но он есть в рабочих записях каждой команды международных платежей.
Самые сложные проблемы в оплате часто возникают не на этапе инициации, а после — когда команде нужно объяснить, что именно произошло.
Карта рынка из предыдущей главы раскрыла широту экосистемы платежей. Кажущаяся единой транзакция часто проходит через множество поставщиков услуг в технологическом стеке до того, как произойдет расчет. Каждая сторона может по-разному отображать одно и то же движение средств, с разной хронологией, разными статусами, документы приходят по разным графикам, а исключения сообщаются через разные каналы.
Вот где платёжные операции становятся сложными.
Reconciliation: Multiple versions of the same event
Финансовая команда должна сопоставить внутренние книги с банковскими выписками, отчетами о расчетах и данными обработчиков. Если один поставщик услуг указывает, что платеж завершен, а другой — что он все еще обрабатывается, компании нужна модель для устранения расхождений. Если возврат поступает после того, как внутренний баланс уже обновлен, книга должна быть соответствующим образом отменена или скорректирована.
Обработка исключений: сбои без четкой ответственности
Выплата может завершиться неудачей из-за недействительного целевого аккаунта, использования неправильного финансового аккаунта, приостановки транзакции из-за проверки соответствия или пропуска срока выполнения операции. Эти сбои различны и не происходят одновременно. Однако пользователи все же ожидают единообразного ответа, а внутренние команды по-прежнему должны обрабатывать процесс.
Ликвидность и средства: деньги не там, где нужно
Предприятия, работающие через несколько сервисов и счетов, должны обеспечить, чтобы средства попадали на правильные счета в нужное время. Даже при достаточном общем балансе платежи могут не выполниться, если средства остаются на неверных счетах — это создает разрыв между логикой продукта и операционной реальностью.
Аудитируемость и контроль: восстановление того, что произошло
Операции по утверждению, приостановке, освобождению и сверке происходят между командами и системами; компании необходима надежная запись о том, кто, когда и зачем что сделал. Это не только требование соответствия нормативным стандартам, но и основа для отслеживания истории транзакций в случае возникновения проблем.
Эти вопросы носят как операционный, так и архитектурный характер.
Самый большой провал в операциях с платежами часто происходит, когда команда не может ответить на простой вопрос: куда исчезли эти деньги?
Отсутствует не еще один поставщик услуг, выполняющий платежи, маршрутизацию транзакций или хранение средств в рамках существующих моделей, а эволюционный PSP, способный координировать все эти функции, отслеживать состояние между поставщиками услуг, управлять рабочими процессами движения средств и поддерживать надежные финансовые записи со временем.
Восьмое: следующая эволюция PSP
The challenge is not in integrating payment infrastructure, but in maintaining a consistent and reliable understanding of how funds flow within it.
Текущее распределение ролей в экосистеме: PSP выполняет платежи, банки хранят средства, системы соблюдения норм оценивают риски, а инструменты оркестрации маршрутизируют транзакции. Однако ни один из поставщиков услуг не отвечает за предоставление полной и согласованной картины денежных потоков на протяжении всего жизненного цикла платежа.
Следующее направление развития PSP — предоставление согласованной видимости по всему технологическому стеку, чтобы каждая платежная операция от инициации до окончательного расчета была понятна, учтена и заслуживала доверия.
Этот уровень должен быть способен:
- Perform payments across banks, traditional rails, and stablecoin networks
- Поддержание согласованной системы учета с помощью внутреннего реестра
- Рабочий процесс управления утверждениями, финансами и обработкой исключений
- Сверка внешних мероприятий с внутренним финансовым состоянием
- С ростом масштабов — встроенные возможности соответствия требованиям, инфраструктура учетных записей и подключение к каналам устойчивого роста
Заключение: С чего начать
Современная платежная инфраструктура больше не определяется одним процессором или одной системой. Это среда, состоящая из нескольких поставщиков услуг, каждый из которых отвечает за разные этапы движения средств: одобрение, расчет и учет.
В рамках этого руководства мы проследили эволюцию этой среды:
Платежные провайдеры вышли за рамки обработки транзакций, количество платежных каналов постоянно растет, системы в реальном времени устранили безопасную сеть отложенного расчета, а новые формы инфраструктуры, такие как стабильные монеты, еще больше расширили всю систему.
Для команд, создающих финансовые продукты или интегрирующих платежи в программное обеспечение, путь к внедрению важнее, чем стратегические обсуждения.
Не начинайте с вопроса «стоит ли полностью принять стабильные монеты», а найдите конкретную боль: слишком медленный расчет по跨境-каналу, чрезмерно много ручных операций в процессе оплаты поставщику, часть свободных средств не приносит дохода во время перевода. Выберите один кейс, откройте счет и произведите реальный платеж. Начните с внутреннего пилотного проекта, сосредоточившись на сценариях управления финансами (treasury), а не сразу изменяя процессы на стороне клиента. Так вы сможете контролировать риски и одновременно сформировать понимание.
На уровне соответствия требованиям правила KYC, AML и проверки на санкции остаются полностью в силе; стабильные монеты — это лишь изменение базовой инфраструктуры. Регуляторная рамка после принятия закона GENIUS стала намного яснее, чем два года назад, и не должна служить препятствием для пилотного проекта.
Настоящий стратегический риск — не в том, используете ли вы стабильные монеты, а в том, что ваши конкуренты перестроили свои затраты на расчеты и эффективность капитала с помощью стабильных монет, в то время как вы ждете идеального момента для входа.
Отсутствие единого координационного уровня приводит к нарастанию сложности с ростом масштаба. С ним компании могут управлять потоками капитала четко, уверенно и с полным контролем.
Часть информации взята из: Modern Treasury — Практическое руководство по PSP в 2026 году