Business / Static Address ▓ PER-USER · DERIVED One address · forever

One address.
Forever.

Permanent per-customer deposit addresses, derived on your own BIP-44 branch. Every payment to that address is attributed to the customer automatically. For exchanges, custom wallets, fan deposits, recurring top-ups.

Start building → Read the docs

Per-user · Derived · Attributed

§ Part I / V · Who it's for

Any flow
that needs attribution.

Five canonical shapes
All live today

SymUse caseWhy Static AddressStatus

EXExchange depositsEach user gets their own deposit address; incoming transfers land on the right account without memos or tags.LIVE

WALCustom wallet top-upsUsers top up their balance in your product by sending crypto to their personal deposit address.LIVE

FANCreator / fan depositsEach fan sees a permanent address on the creator's page; all payments attributed automatically.LIVE

B2BRecurring B2B settlementOne address per counterparty. Every invoice they pay lands on the same address, makes reconciliation trivial.LIVE

GMGame-economy top-upsEach player gets a unique address; crypto deposits bump in-game balance via your webhook handler.LIVE

§ Part II / V · Mechanism

Derived once,
used forever.

BIP-44
Your branch · never pooled

#StepWhat happensState

01RequestMerchant calls POST /v1/payment/static-address with external_user_id and coin.INIT

02DeriveOrbChain computes m/44'/coinType'/merchantIndex'/0/userIndex. First call for that user mints a new index.DERIVED

03ReturnAddress + QR payload returned. Subsequent calls for the same user + coin return the SAME address — idempotent by construction.STABLE

04WatchChain monitor watches the address permanently. Every payment credits the merchant balance and fires a V1 deposit webhook with the external_user_id.LIVE

05SweepUser-address balance sweeps to your hot-wallet whenever a deposit credits. TRC20 drips TRX for energy first.AUTO

§ Part III / V · Integration

One call in,
one address out.

Idempotent
Call 1,000× · same result

POST /v1/payment/static-addresscurl · 200 OK

// Mint-or-return the USDT-TRC20 deposit address for customer "user_12345".
curl https://orbchain.io/v1/payment/static-address \
  -H "merchant_api_key: mk_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "external_user_id":  "user_12345",
    "coin":              "USDT_TRC20",
    "callback_url":      "https://shop.example/webhooks/deposits"
  }'

// → 200 OK  (same response for every subsequent call, same user, same coin)
{
  "address":           "TXN7…9qF",
  "coin":              "USDT_TRC20",
  "external_user_id":  "user_12345",
  "qr_payload":        "tron:TXN7…9qF",
  "derivation_path":   "m/44'/195'/42'/0/7"
}

§ Part IV / V · Attribution

Every deposit
carries the user id.

V1 deposit webhook
HMAC-SHA256 signed

POST your /webhooks/depositspayload · HMAC-SHA256

// When a customer pays their static address, YOU receive this:
{
  "event":             "deposit.confirmed",
  "event_id":          "01H8KP9M3FRA8YTVKX6ZBN4AX2",
  "external_user_id":  "user_12345",
  "coin":              "USDT_TRC20",
  "tx_hash":           "0xabc…def",
  "amount":            "120.000000",
  "amount_usd":        "120.00",
  "net_usd":           "119.52",
  "confirmations":     3,
  "confirmed_at":      "2026-04-20T18:45:12Z"
}

// Verify: HMAC-SHA256(webhook_secret, raw_body) == X-Signature header

§ Part V / V · Questions

Things exchanges
ask about attribution.

Answered
Links to docs

Q.01Does the same user get the same address for every coin?

No — one address per (user, coin) pair. user_12345 gets a dedicated USDT_TRC20 address, a dedicated BTC address, a dedicated ETH address, etc. Each derives on its coin's BIP-44 path.

Q.02What about coins that need memos (XRP, TON)?

OrbChain handles memo-based coins by returning a shared address + a unique memo/tag in the response. Every deposit to that address+memo is attributed to the right user.

Q.03How is XMR handled?

Monero uses sub-addresses — one primary wallet per merchant, one sub-address per user. Same API contract, same attribution.

Q.04Can I pre-mint addresses without a user visiting?

Yes — call the endpoint at signup time with your internal user id; OrbChain mints + returns the address immediately. You can display it on the user's dashboard before any deposit lands.

Q.05What's the difference between V1 and V2 webhooks here?

Static Address deposits fire both a V1 deposit webhook (HMAC-SHA256, includes external_user_id) and a V2 payment.paid webhook (HMAC-SHA512, deterministic event_id). Listen to whichever matches your stack.

One address.
Every payment attributed.

Idempotent API. Derived on your branch. No KYC, no custody, 0.4% flat on settled volume.

Create account → Read the spec

§ Feature stack · static address

Static addresses ride
the full feature stack.

Per-seller
Webhook-idempotent

SymFeatureMechanismStatus

LNInstant LightningAccept and pay out Bitcoin over Lightning. Atomic settlement, zero confirmations, sub-cent fees. On-chain fallback is one parameter.LIVE

ASAuto SettleCustomer pays any accepted coin. You always receive the settlement coin you configured — pay-with-BTC, get-USDT. Swap runs at checkout, no extra setup.LIVE

APAuto PayoutSet a balance threshold. We sweep to your cold wallet the moment you hit it. 30-minute cooldown on failure. No manual clicks, no scheduled cron.LIVE

SRSigned ReceiptsEvery PAID payment gets an Ed25519-signed receipt. Verify offline with our public key. No other gateway in our category ships this.LIVE

NKNo-KYC ForeverEmail + password, that's it. No documents, no verification wall, no volume gates. We don't touch your customers' identity — your gateway, your rules.LIVE

DWDeterministic WebhooksEvery webhook carries a SHA-256 event_id derived from (event_type, entity_id). Retry 1,000×, same id. True idempotency without an extra DB column.LIVE

One address. Forever.

Any flowthat needs attribution.

Derived once,used forever.

One call in,one address out.

Every depositcarries the user id.

Things exchangesask about attribution.

One address.Every payment attributed.

Static addresses ridethe full feature stack.