Skip to Content
КонцепцииСети и активы

Сети и активы

InfraIO Pay прежде всего работает с EVM-сетями и со стейблкоинами. Каждая поддерживаемая сеть настраивается в реестре networks.json в payment-service; матрица ниже отражает то, что сегодня живо в test и mainnet.

Mainnet

СетьChain IDNativeUSDCUSDTПодтвержденияМин. заказ
Ethereum1ETH✓ (ERC-20)✓ (ERC-20)12$5.00
Base8453ETH✓ (ERC-20)—10$1.00
Polygon137POL✓ (ERC-20)✓ (ERC-20)5$1.00
BSC56BNB✓ (18-decimal)✓ (18-decimal)5$1.00
Arbitrum42161ETH✓ (ERC-20)✓ (ERC-20)5$1.00
Optimism10ETH✓ (ERC-20)✓ (ERC-20)5$1.00
ZKsync Era324ETH——5$1.00
Mantle5000MNT——5$1.00

USDC + USDT на BSC используют 18 десятичных знаков, а не 6, как везде. Если вы по какой-то причине вычисляете суммы на стороне клиента, учтите это — иначе поля сумм SDK справятся сами.

«Мин. заказ» — это порог в долларах, проверяемый при создании payment-intent. Сегодня по умолчанию $1.00 mainnet / $0.50 testnet, с поднятием для Ethereum до $5, потому что gas на L1 перекрывает мелкие заказы. Admin ops может переопределить per-network — заказы ниже порога отклоняются с AMOUNT_BELOW_MINIMUM (HTTP 400), а details.floor_usd несёт реальное настроенное значение, чтобы ваш FE мог показать его.

Testnet

СетьChain IDNativeПодтвержденияМин. заказ
Ethereum Sepolia11155111ETH1$0.50
Base Sepolia84532ETH1$0.50
Polygon Amoy80002POL1$0.50
BNB Smart Chain Testnet97tBNB1$0.50
Arbitrum Sepolia421614ETH1$0.50
OP Sepolia11155420ETH1$0.50
Mantle Sepolia5003MNT1$0.50
ZKsync Sepolia300ETH1$0.50

Тестовый режим использует реальные testnet’ы, а не мок-сеть. Чтобы запустить тестовый платёж, вам нужны реальные testnet-средства — возьмите их из крана (например, sepoliafaucet.com , coinbase.com/faucets ) и отправьте на депозитный адрес, который сгенерирует страница checkout.

Коды валют, используемые в API

currency (на верхнем уровне тела и в каждой позиции) — это валюта отображения заказа, то, что покупатель видит как сумму. Сегодня платформа принимает один код при создании:

  • "USD" — единственное значение, для которого IsSupportedCurrency возвращает true в payment-service. И POST /v1/orders, и POST /b2b/v1/checkout-sessions/quick отклоняют любое другое значение с INVALID_INPUT («unsupported currency»). Объявленный список живёт по адресу GET /v1/supported/currencies, чтобы enum сервера и ваш клиент никогда не расходились.

On-chain актив, в котором покупатель проводит расчёт (USDC, USDT, …), это не поле currency. Он выбирается покупателем на странице checkout из комбинаций сеть × токен, включённых в вашей мерчантской конфигурации, и возвращается вам на PaymentIntent + webhook payload как settlement_token (символ + сеть). Нативные gas-токены (ETH, BNB, POL, MNT) — это только метаданные сети, не валидные платёжные валюты.

Сама сеть тоже не указывается при создании по той же причине: покупатель выбирает комбинацию на странице checkout.

Подтверждения vs окончательность

Колонка «Подтверждения» выше — число блоков, которое chain watcher ждёт, прежде чем перевести PaymentIntent в SETTLED и отправить payment.settled. Значения по умолчанию подобраны так, чтобы дать вероятностную окончательность на каждой сети при типичной глубине реорга:

  • Mainnet Ethereum: значение 12, которое большинство бирж использует после Merge.
  • L2 рассчитываются быстрее, но в конечном итоге наследуют окончательность Ethereum — per-chain счётчик отражает риск реорга на самом L2, а не на L1.
  • Testnet’ы стоят на 1 confirmation, чтобы держать dev-цикл быстрым; не экстраполируйте безопасность mainnet-уровня на ваше dev-окружение.

Если вам нужны более строгие (или более мягкие) подтверждения для конкретной сети, per-chain счётчик настраивается на аккаунте мерчанта — обратитесь к вашему контактному лицу по аккаунту.

Включение сетей для вашего мерчанта

По умолчанию у нового мерчанта разрешён широкий набор сетей на testnet и более узкий на mainnet. Набор mainnet’а зависит от:

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

Включите дополнительные сети из Settings → Networks в панели мерчанта.

Детерминированные депозитные адреса

EVM-депозитные адреса детерминированы per checkout: платформа выводит их заранее из внутренних параметров, привязанных к мерчанту, заказу и intent’у. Вам не нужно ничего предсоздавать или фондировать — вы просто получаете адрес на PaymentIntent и передаёте его покупателю.

  • Два intent’а для одного мерчанта получают разные адреса — никаких коллизий между покупателями.
  • Адрес появляется на странице checkout до любой on-chain настройки, поэтому покупатель сразу видит, куда переводить.
  • Покупатели никогда не платят setup gas. Средства поступают прямо в treasury мерчанта без отдельного шага sweep, который мерчанту нужно отслеживать.

Практические следствия для интеграторов:

  • deposit_address, возвращаемый на PaymentIntent, — обычный EVM-адрес — его можно показать как QR-код, отсканировать, отправить на него с любого кошелька. Никакой особой клиентской поддержки не нужно.
  • Отправка на адрес до истечения intent’а проводит расчёт по заказу. Отправка после истечения восстанавливается по best-effort — платформа может пере-sweep’ить поздние депозиты в некоторых случаях, но никогда не предполагайте, что поздние средства в безопасности.
  • Каждый адрес одноразовый per intent. Если покупателю нужна вторая попытка, создайте новую сессию checkout — вы получите свежий адрес.

Что НЕ поддерживается сегодня

  • Tron / TRC-20. Часто запрашивается для USDT-TRC20; в roadmap, не запущено.
  • Solana / SPL. В roadmap.
  • Bitcoin / Lightning. Не в roadmap.
  • Layer-1 native стейблкоины (USDe, FDUSD, …). Добавляются через запрос в панели; нужно только включить базовую сеть.

Что дальше

ВозвратыОбзор