🇬🇧 EN → Login
Welcome

Build on NxtGateW

Crypto deposit wallets with on-chain split, NFT / SBT lifecycle, and custodial wallet spend accounts — one merchant Key + Secret.

Base URL https://nxtgatew.com · Interactive testing in the API Console.

Authentication

Every merchant API call requires:

X-API-Key: YOUR_KEY
X-API-Secret: YOUR_SECRET
Content-Type: application/json

NFT mutating routes also accept optional X-Timestamp + X-Nonce + X-Signature (HMAC-SHA256). Key + Secret alone is enough.

Create keys in the merchant portal after registration.

Deposit wallets

POST /api/v1/wallets/create allocates a deposit address for Cash App / crypto payments with optional affiliate split.

Ephemeral mode

{
  "address": "0xYourSettlement…",
  "callback": "https://your-site.com/webhooks/nxtgatew",
  "network": "polygon",
  "mode": "ephemeral"
}

A new address is returned on every call. Ideal for one payment ≈ one address. After deposit detection, the platform auto-splits on-chain.

Client mode (unique / reusable)

Get-or-create by (merchant, network, client_id). Two payout patterns:

Business merchant (Paygate / API)

{
  "address": "0xPartnerSettlement…",
  "callback": "https://your-site.com/webhooks/nxtgatew",
  "network": "polygon",
  "mode": "client",
  "client_id": "user@email.com",
  "transaction_id": "183"
}

address = partner settlement wallet. Response data.address = new deposit (must be ≠ address). After split, the merchant share goes to that settlement wallet.

Self-custody (widget / end-user keeps funds)

{
  "self_custody": true,
  "callback": "https://your-site.com/webhooks/nxtgatew",
  "network": "ethereum",
  "mode": "client",
  "client_id": "cust_42",
  "transaction_id": "183",
  "subaff_address": "0x…",
  "subaff_percent": 5
}

Omit address or pass self_custody: true. NxtGateW creates the deposit and sets payout merchant = deposit in one call (no bootstrap / rebind). Response includes self_custody: true and merchant_address (= deposit). After fees, the remainder stays on the client wallet.

  • First call → 201 + new deposit address (may include private_key).
  • Same client_id + same network again → 200 + "reused": true — same address, never a second wallet. Reuse with self_custody rebinds payout to deposit; reuse with a settlement address sets business merchant payout.
  • Pass a new transaction_id on each payment. If the wallet is mid-cycle, the intent is queued (payment_queued: true) until the previous cycle finishes.

Same optional affiliate_* / subaff_* fields as ephemeral. Client-mode deposits are not auto-split — ask the end-user for consent, then call authorize split (queues the job; cron executes like ephemeral).

When the end-user can re-click the widget (multiple transaction_id on the same deposit), declare the live provider order with funding-intent before / when the on-ramp session is locked.

Verify wiring with GET /api/v1/wallets/check-config?wallet_address=…&network=polygon.

Supported chains: see Networks & tokens.

Funding intent (which transaction_id is paid)

POST /api/v1/wallets/funding-intent — tell NxtGateW which transaction_id is the live on-ramp order for a reusable client wallet. Required when the widget can create several tids (re-clicks) but only one provider payment will land.

POST /api/v1/wallets/funding-intent
{
  "client_id": "alectate2006@gmail.com",
  "transaction_id": "MUQLB102BFE4FC4F0B3A000000",
  "network": "ethereum",
  "expected_amount": "91"
}

When to call: as soon as the provider session is locked / payment is in flight (not after a random re-click). Prefer creating the tid before sending the deposit address to the provider, then call funding-intent with that same tid.

  • Marks this intent with funding_confirmed_at (exclusive on the wallet — clears the flag on other open intents).
  • Next indexed ERC-20 IN binds to this transaction_id (priority over FIFO).
  • If an unsplitted IN is already indexed under another tid, Nxt reattaches it by default (reattach: true), optional expected_amount to pick the right movement.
{
  "success": true,
  "status": "funding_confirmed",
  "transaction_id": "MUQLB102…",
  "deposit_bound": true,
  "reattached_movement_id": 2358236,
  "previous_transaction_id": "MUQKY1RL…",
  "active_transaction_id": "MUQLB102…"
}

Then call POST /wallets/split with the same transaction_id after user consent.

Authorize split (client wallets)

POST /api/v1/wallets/split records the customer’s consent to split one payment. It does not run the on-chain split in the HTTP request — it places work in the same queue as ephemeral wallets; cron executes shortly after.

Send both client_id and transaction_id so the payment cannot be applied to the wrong customer.

POST /api/v1/wallets/split
{
  "client_id": "user@email.com",
  "transaction_id": "183"
}

The API checks that this transaction_id is registered on that client’s wallet. Mismatch → 409.

Success responses

  • status: "queued" — funds already indexed; job enqueued for cron.
  • status: "authorized" — consent saved; deposit not indexed yet. When the IN arrives, NxtGateW enqueues automatically (no second click).
{
  "success": true,
  "status": "queued",
  "accepted": true,
  "authorized": true,
  "queued": true,
  "enqueued": 1,
  "wallet_mode": "client",
  "client_id": "user@email.com",
  "transaction_id": "183"
}

Treat authorized and queued as success. Do not wait for status: "split" on this call — completion arrives later via webhook (wallet.payment_complete / balance events).

Use "dry_run": true (or "action": "check") to read status without authorizing. wait: true is debug-only (runs the worker in-request).

Try it in the API Console · Split.

Payment webhooks

Set callback on create. NxtGateW POSTs deposit / movement / split progress to your URL. Verify HMAC with your API secret when applicable. Always respond 200.

NFT / SBT

Prefix /api/v1/nft. Create a managed wallet per external_user_id, then collections, then mint or import.

Mode A — platform mint

POST /api/v1/nft/nfts with Idempotency-Key → HTTP 202. Cron confirms on-chain → nft.minted webhook. Do not also import the same purchase.

Mode B — import

POST /api/v1/nft/nfts/import with tx_hash when a third party already minted on your contract.

Custodial wallets

Prefix /api/v1/wallet. Isolated from deposit / split wallets — do not use payment deposit addresses as end-user spend wallets.

POST /api/v1/wallet/accounts
{
  "external_user_id": "app_user_42",
  "network": "polygon",
  "label": "Main"
}

201 first create includes private_key once. Reuse returns 200 without the key — call POST …/export-key.

Balances & send

  • GET …/balances — live RPC
  • POST …/sync then GET …/transactions
  • POST …/estimate then POST …/send — NxtGateW signs; requires Idempotency-Key
  • GET …/sends/{id} — send status
  • POST …/export-key — private key on demand

Try it in the API Console · Custodial wallets or see OpenAPI.