Skip to Content
Начало работыВведение

Введение

Форма платежа

Мерчант, интегрирующий InfraIO Pay, имеет дело с четырьмя движущимися частями:

Сессия checkout

Вы создаёте сессию на сервере с позициями и суммами. Ответ несёт session_key (cst_…) и checkout_url. Сессии с TTL (по умолчанию 30 мин) и одноразовые.

Размещённая страница checkout

Вы загружаете наш браузерный SDK и открываете сессию — popup, redirect или встроенный iframe. Покупатель выбирает сеть × актив (USDT на Polygon, ETH на Base, …), видит сгенерированный депозитный адрес + QR и отправляет средства из своего кошелька.

Подтверждение платежа

Payment-service наблюдает за соответствующей сетью на предмет входящих переводов, совпадающих с депозитным адресом сессии. После того как число подтверждений достигает настроенного (например, 12 на Ethereum mainnet, 5 на Polygon — см. Сети и активы), лежащий в основе PaymentIntent переходит в SETTLED, а родительский Order — в PAID.

Webhook

Мы делаем POST подписанного события payment.settled на ваш зарегистрированный webhook URL. Ваш сервер проверяет подпись, сопоставляет с вашим собственным заказом через external_ref и обрабатывает заказ.

Модель данных на одной диаграмме

CheckoutSession  ←  1:1  →  Order  ←  1:N  →  PaymentIntent
   (с TTL)                  (постоянный)      (один на попытку оплаты)

Вы думаете в терминах Order для обработки заказа, создаёте Session, чтобы принять оплату, а система управляет PaymentIntent за кулисами для повторов / выбора сети.

С чем справляемся мы vs с чем справляетесь вы

InfraIO Pay справляетсяВы справляетесь
Размещённый UI checkout (депозитный адрес, QR, селектор актива)Каталог + создание Order в вашей БД
Мониторинг сети + логика подтверждений на 8 EVM-сетяхПриёмник webhook + проверка подписи
Мультиактивный checkout (USDT, USDC, нативные ETH/BNB/POL/MNT на каждой сети)Маппинг нашего order_id ↔ вашего ID заказа через external_ref
Учёт возвратов (state-машина, панель, API)Подписание + трансляция on-chain tx возврата
Test-mode ключи + изолированные test-webhooksПополнение testnet-кошельков из кранов

Мы не храним средства мерчанта. Переводы buyer-to-merchant происходят напрямую on-chain; мы — слой индексации и reconciliation, который сообщает вам, когда перевод прошёл.

Test-mode vs live-mode

Каждый аккаунт начинается в test-mode. Test-ключи имеют префиксы pk_test_ / sk_test_. Live-ключи (pk_live_ / sk_live_) открываются после:

  1. Завершения KYB
  2. Подтверждения treasury-кошелька (вы подписываете сообщение, доказывающее, что вы контролируете адрес назначения на каждой сети, на которой хотите принимать)

Один и тот же базовый URL обслуживает оба — окружение определяется префиксом ключа, а не URL. Test-mode работает против реальных testnet’ов (Sepolia, Base Sepolia, BSC Testnet и т. д.) — мок-сети нет. Чтобы запустить тестовый платёж, вам нужны реальные testnet- средства из крана.

Чем InfraIO Pay не является

  • Не кастодиан. Средства движутся напрямую от покупателя к кошельку мерчанта on-chain. Мы не храним баланс.
  • Не провайдер кошельков. Клиенты используют собственные кошельки; в размещённом checkout есть встроенная опция WalletConnect, но никакого нативного хранения нет.
  • Не фиатный рамп. Покупатели платят тем крипто-активом, что у них есть; мы не конвертируем.
  • Не gateway для Tron или Solana сегодня. Прежде всего EVM. См. Сети и активы для актуальной матрицы.

Что дальше

Добро пожаловатьБыстрый старт