API шлюза — Tranzify

API шлюза: один REST-контракт для карт, локальных методов, Open Banking, крипты и выплат

API шлюза Tranzify: один запрос создаёт платёж через любого провайдера каталога; подписанные вебхуки, размещённая форма оплаты или сервер-сервер, и песочница, в которой мерчант переносит свой поток до переключения.

Один запрос, любой рельс

Мерчант создаёт платёж с суммой, валютой, методом и клиентом; Tranzify выбирает маршрут, вызывает провайдера и сообщает результат. Карты, Apple Pay и Google Pay, Open Banking, PIX, UPI, QRIS, банковские переводы, ваучеры, крипта и выплаты используют один и тот же запрос и одни и те же статусы. Код мерчанта не знает, какой провайдер обработал платёж, и ему это не нужно: когда клиент добавляет эквайера или локальный метод, интеграция мерчанта остаётся прежней.

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

Что даёт API

Размещённая форма оплаты на 29 языках под брендом клиента или режим сервер-сервер для мерчантов с собственным периметром PCI.
Токены для рекуррентных платежей и оплаты в один клик; инициированные мерчантом списания без CVV там, где позволяет провайдер, с индикаторами платёжных систем, которые проставляет платформа.
Выплаты на карты, банковские счета, кошельки и ключи PIX через тот же контракт; по одной или файлом.
Возвраты, частичные и полные, с историей статусов каждого платежа и каждого возврата.
Подписанные вебхуки с повторами, кнопка повторной отправки в бэк-офисе и полная трассировка каждой доставки.
Песочница с тем же контрактом, что у продакшена, для тестов мерчанта до переключения.
Ключи и секреты по мерчанту, отдельные для песочницы и продакшена.

Жизнь платежа

Шаг	Что происходит	Что видит мерчант
Создание	Запрос проверяется, платёж сохраняется со своей ссылкой	Ссылка платежа и действие, которое нужно выполнить
Маршрут	Поток сети выбирает терминал; применяются лимиты и ограничения	Ничего: маршрутизация — настройка клиента
Обработка	Вызывается провайдер; при отказе или таймауте каскад вызывает следующий терминал	Перенаправление, QR-код, реквизиты или немедленный результат
Подтверждение	Колбэк провайдера проверяется и переводится в статус платформы	Подписанный вебхук; статус в ресурсе платежа
Расчёт	Комиссии, балансы и резервы записываются в леджер	Балансы и расчёты в кабинете мерчанта
Изменение	Возврат, чарджбэк, запоздалый колбэк	Вебхук на каждое событие в том же формате

Каждый шаг хранится в журнале платежа пять лет вместе с сырым запросом и ответом каждого вызова провайдера, поэтому поддержка может открыть трассировку любого платежа, о котором спрашивает мерчант.

Интеграция по шагам

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

Перенос мерчантов

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

Один запрос — все события

Мерчант отправляет один запрос; платформа маршрутизирует, каскадирует, пишет журнал и вызывает вебхук. События справа — то, что показывает трассировка этого платежа в кабинете.

POST /v1/payments
Authorization: Bearer sk_live_…
Idempotency-Key: 7f0e7a1c

{
  "amount": 249.00,
  "currency": "BRL",
  "method": "pix",
  "customer": { "country": "BR", "email": "ana@example.com" },
  "return_url": "https://shop.example/thanks",
  "webhook_url": "https://shop.example/hooks/tranzify"
}

События платежаlive

0 msPOST /v1/payments → 201 · id tz_8f3a…c12 · status routing
4 msrouting.matched · flow v14 · group "LATAM · PIX"
322 msprovider.attempt · EBANX · pix-01 · declined · 05 do not honour
324 msrouting.cascade · next terminal by priority and weight
734 msprovider.attempt · dLocal · pix-02 · approved
774 mswebhook.delivered · 200 · signature ok
775 msjournal.written · 5 years · trace tz_8f3a…c12

Частые вопросы

API одинаков для всех методов оплаты?+

Да. Платёж создаётся одним и тем же запросом независимо от метода; ответ говорит мерчанту, что делать: перенаправить плательщика, показать QR-код или ждать банковского перевода.

Что с мерчантами, уже интегрированными с другой платформой?+

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

Как защищены вебхуки?+

Каждый вебхук подписан секретом мерчанта и повторяется по расписанию, пока мерчант не ответит 2xx; каждая попытка в журнале, и её можно отправить заново из бэк-офиса.

Поддерживает ли API рекуррентные платежи?+

Да. Первый платёж с согласием плательщика возвращает токен; последующие списания ссылаются на токен, без номера карты и, где провайдер позволяет, без CVV, по правилам платёжных систем для инициированных мерчантом операций.

Как управляются ключи API?+

По мерчанту, в кабинете мерчанта: ключи для песочницы и продакшена и секрет для подписи вебхуков; каждый запрос лежит в журнале с ключом, которым он сделан.

Для чего песочница?+

Тестовая среда с тем же контрактом, что у продакшена: разработчик мерчанта создаёт в ней платежи, выполняет действия и принимает вебхуки до выдачи ключей продакшена.

Посмотрите платформу на своих потоках

Тридцать минут с инженером, а не презентация: ваши провайдеры, ваши правила маршрутизации, форма оплаты ваших мерчантов.

✓ Не финансовая организация

✓ Деньги через нас не проходят

✓ Построено по требованиям PCI DSS