Skip to Content
Get startedIntroduction

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 TTL’d (default 30 min) 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 deposit address + QR, and sends funds from their wallet.

Payment confirmation

The payment-service watches the relevant chain 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.

Webhook

We POST a signed payment.settled event to your registered webhook URL. Your server verifies the signature, joins back to your own order via external_ref, and fulfils.

The data model in one diagram

CheckoutSession  ←  1:1  →  Order  ←  1:N  →  PaymentIntent
   (TTL'd)                  (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 / chain 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 chainsWebhook receiver + signature verification
Multi-asset checkout (USDT, USDC, native ETH/BNB/POL/MNT per chain)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 gated on:

  1. KYB completion
  2. Treasury wallet attestation (you sign a message proving you control the destination wallet on each chain you want to receive on)

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.

What InfraIO Pay is not

  • Not a custodian. Funds move buyer → merchant wallet on-chain directly. We never hold balance.
  • Not a wallet provider. Customers bring their own wallet; the hosted checkout has a built-in WalletConnect option but no native custody.
  • Not a fiat ramp. Buyers pay in the crypto asset they have; we don’t convert.
  • Not a Tron or Solana gateway today. EVM-first. See Chains & assets for the live matrix.

What’s next

WelcomeQuickstart