Назад к блогу

Сравнения

Один платёжный гейтвей против мультипровайдерной платформы

Что меняется для мерчанта, когда маршрутизация, транзакции, чекаут, споры, мониторинг и сверка приходят с одной платформы, а не с дашборда одного гейтвея.

Фото: Maria_Domnina / Pixabay

Что даёт один платёжный гейтвей

Бизнес, который работает через один платёжный гейтвей, подключается к шлюзу одного провайдера и работает в его дашборде. Маршрутизация, список доступных платёжных методов и отчётность, которую видит мерчант, — всё это задаётся именно этим одним подключением, потому что маршрутизировать куда-то ещё или отчитываться по чему-то ещё просто нет возможности.

Маршрутизация между несколькими провайдерами

В omwio провайдеры подключаются как модули, и к каждому из них регистрируются свои MID. У каждой валюты свой набор включённых платёжных методов, и менеджер может заранее проверить, как резолвится маршрут для конкретного мерчанта и метода, ещё до того, как через него пойдёт реальный трафик. При одном гейтвее маршрутизация и список методов — это то, что предлагает именно этот провайдер; в omwio маршрутизация — это решение, которое платформа принимает сразу среди всех подключённых провайдеров и MID.

Единая модель для любого типа транзакции

Платежи, выплаты, обмены, рефанды и чарджбеки в omwio — это всё транзакции в рамках одной модели статусов с одним свёрнутым маппингом статусов, который видит мерчант независимо от того, какой провайдер фактически обработал средства. Мультивалютные кошельки каждого мерчанта хранят историю баланса и видимость резервов, а аналитика конверсии и провайдеров может быть ранжирована по мерчанту, провайдеру и MID, с фильтрами по валюте, статусу и периоду. Отчётность одного гейтвея ограничена тем, что показывает дашборд именно этого провайдера, — ей просто незачем разбивать объём по провайдеру или MID, когда каждого из них по одному.

Чекаут, инвойсы и споры в одном месте

Хостинговый чекаут omwio работает на собственном pay-хосте тенанта, а особенности конкретных провайдеров нормализуются в канонические платёжные инструкции ещё до того, как дойдут до тех, кто интегрируется через Processing API. Мерчанты также могут выставлять инвойсы и отправлять их брендированной почтой, чтобы плательщик мог рассчитаться на публичной странице. Постплатёжный путь — рефанды, обработка чарджбеков и структурированный процесс споров — часть той же базовой функциональности: менеджер может разрешить мерчанту открывать споры по собственным платежам и выплатам, с указанием причины и до пяти файлов-доказательств, а менеджер их разрешает, после чего балансы автоматически откатываются и перепроводятся.

Наблюдение за состоянием провайдеров и сверка того, что реально оседает

Два опциональных модуля расширяют это дальше. Monitoring отслеживает процент успешных транзакций, задержку и микс ошибок отдельно по каждому провайдеру и MID, а не только как одно общее число, и алерты указывают именно на тот маршрут, который деградирует. Accounting & reconciliation ведёт трежери по каждой валюте, дневной P&L, который закрывается и исправляется только датированным реверсом, а также процесс импорта и сверки, который проверяет выписки провайдеров против транзакций платформы по суммам, референсам и временным окнам. Оба модуля включаются в зависимости от тарифного плана, а не встроены в каждого тенанта по умолчанию. Ни один из этих двух вопросов — какой маршрут деградирует и совпадает ли выписка с книгами на самом деле — не имеет аналога при одном гейтвее, потому что оба имеют смысл только когда провайдеров или MID больше одного.