Skip to Content
Get startedIntroduction
View as Markdown

Introduction

The shape of a payment

A merchant integrating InfraIO Pay deals with four moving parts:

Checkout session

You create a session server-side with line items and totals. The response carries a session_key (cst_…) and a checkout_url. Sessions are time-limited (default 30 minutes) and single-use.

Hosted checkout page

You load our browser SDK and open the session — popup, redirect, or embedded iframe. The buyer picks a chain × asset (USDT on Polygon, ETH on Base, …), sees a generated per-order deposit address (CREATE2) + QR, and sends funds from their wallet.

Payment confirmation

InfraIO Pay watches the relevant network for inbound transfers matching the session’s deposit address. Once cleared for the configured confirmation count (e.g. 12 on Ethereum mainnet, 5 on Polygon — see Chains & assets), the underlying PaymentIntent moves to SETTLED and the parent Order moves to PAID.

On TRON, Solana and TON there is no deposit address. The buyer’s wallet pays your treasury wallet directly (TronLink, a Solana Pay QR, or TON Connect) and InfraIO Pay recognizes that payment. See Chains & assets.

Payments go straight to your treasury wallets — InfraIO Pay never holds your funds.

Webhook

We POST a signed payment.settled event to your registered webhook URL. Your server verifies the signature, looks up the order, and fulfills it.

The data model in one diagram

CheckoutSession  ←  1:1  →  Order  ←  1:N  →  PaymentIntent
   (time-limited)                (permanent)        (one per pay attempt)

You think about Orders for fulfillment, you create Sessions to take payment, and the system manages PaymentIntents behind the scenes for retries and network selection.

What we handle vs. what you handle

InfraIO Pay handlesYou handle
Hosted checkout UI (deposit address, QR, asset picker)Catalog + Order creation in your DB
Chain monitoring + confirmation logic across 8 EVM chains plus TRON, Solana and TON (coming soon)Webhook receiver + signature verification
Multi-asset stablecoin checkout (USDT, USDC per network)Mapping our order_id ↔ your order ID via external_ref
Refund accounting (state machine, dashboard, API)Signing + broadcasting the on-chain refund tx
Test-mode keys + isolated test webhooksFunding testnet wallets from faucets

We don’t hold custody of merchant funds. Buyer-to-merchant transfers happen directly on-chain; we’re the indexer + reconciliation layer that tells you when the transfer cleared.

Test mode vs live mode

Every account starts in test mode. Test keys are prefixed pk_test_ / sk_test_. Live keys (pk_live_ / sk_live_) are available after you complete account verification and add a treasury wallet for each network you want to receive on (you sign a message to prove you control it).

The same API base URL serves both — environment is determined by the key prefix, not the URL. Test mode runs against real testnets (Sepolia, Base Sepolia, BSC Testnet, etc.) — there is no mock chain. To trigger a test payment you need actual testnet funds from a faucet.

Contact / support

Questions or need help? Email [email protected].

What InfraIO Pay is not

  • Not a custodian. Funds move from the buyer to your treasury wallet on-chain directly. We never hold your balance.
  • Not a wallet requirement. Customers pay from their own wallet (the hosted checkout has a built-in WalletConnect option). InfraIO Wallet is a separate, non-custodial passkey wallet and is not required.
  • Not a fiat ramp. Buyers pay in the crypto asset they have; we don’t convert.
  • Not a Bitcoin gateway. Stablecoins on 8 EVM networks plus TRON, Solana and TON (coming soon); no Bitcoin or Lightning. See Chains & assets for the live matrix.

What’s next

WelcomeQuickstart