Permanent deposit addresses

For deposit-driven businesses (casinos, brokers, prop firms), each customer gets a permanent deposit address they reuse for every deposit. Your platform calls the API to mint that address the moment a customer starts a deposit, shows it natively in your own UI, and funds sweep into your account (treasury) wallet automatically — with a callback on every payment so you can credit the user. A returning customer reuses the same address, so repeat deposits are never lost. The deposit loop:

The customer starts a deposit in your platform

picks a method and confirms.

Your backend creates (or returns) that user's client wallet via the API

on-demand — the address is minted at this moment.

Your platform shows the returned address + QR

natively, no redirect.

The customer sends funds

they land at the address.

Funds sweep to your account wallet, and a callback fires

you credit the user in your system.

Static client wallet vs checkout charge — critical. A client wallet assigned to a customer is permanent: repeat deposits to the same address are always credited. A checkout charge mints a single-use wallet — re-sending to a previous charge address is not tracked. “Same address every time” applies to client wallets only.

1. Set the callback URL, then generate API keys

Order matters: set the Callback Url first, Submit, and only then generate keys. In Settings → Account Data, enter your callback endpoint, Submit, then click Generate new API keys — you get a Public key and Private key.

Account settings showing Public/Private API keys and the Callback Url field — Callback URL set, then API keys generated.

The Private key is server-side only — never ship it to the browser. Treat the keys and the passphrase below as secrets.

2. Get your account wallet’s Wallet ID + passphrase

Wallet operations (and withdrawals) need the account wallet’s Wallet ID + passphrase for the network you settle on — here the EVM / Ethereum account wallet. In Wallets → Account wallets, open the wallet’s menu → Passphrase → Send code (passes 2FA) → the Wallet ID and Passphrase are revealed.

Merchant wallet menu with Passphrase tab and Send code button — Account wallet menu → Passphrase → Send code (2FA).

Revealed Wallet ID and Passphrase — Wallet ID + passphrase for the EVM account wallet.

This is the account wallet’s ID. You never fetch a client wallet’s ID — client wallets are created by the API, on demand, in the next step.

3. The customer starts a deposit — and the wallet is minted

In your platform’s deposit screen, the customer picks the method and clicks Confirm.

Platform deposit screen, USDT ERC20 method selected, Confirm button — Deposit method selection in your platform. Confirm triggers the wallet creation.

That Confirm is what triggers your backend to call the API. API base: https://napi.crypto-now.io. Authenticate with the keys, look up the currencyId for the network, then create the client wallet (typeWallet: user) — the response’s address is what you display.

# 1. Authenticate → JWT
curl -X POST https://napi.crypto-now.io/api/public/auth \
  -H "Content-Type: application/json" \
  -d '{ "publicKey": "<PUBLIC_KEY>", "privateKey": "<PRIVATE_KEY>" }'
# → { "token": "<JWT>" }

# 2. Find the currencyId (e.g. USDT-ERC20)
curl https://napi.crypto-now.io/api/public/currency \
  -H "Authorization: Bearer <JWT>"

# 3. Create the user's client wallet → returns its address
curl -X POST https://napi.crypto-now.io/api/public/wallet/<CURRENCY_ID> \
  -H "Authorization: Bearer <JWT>" \
  -H "Content-Type: application/json" \
  -d '{ "typeWallet": "user" }'
# → { "data": { "id": "<walletId>", "address": "0x...", "passphrase": "..." } }

Your platform shows the returned address + QR:

Deposit screen showing address and QR, status Waiting for money — The minted address + QR, shown natively, awaiting payment.

Store user → { walletId, address } and reuse it for that user. The wallet you just minted now appears in CryptoNow under Client wallets at $0.00 — it didn’t exist before the customer confirmed:

Client wallets list showing the newly created EVM USDT wallet at $0.00 — The wallet now exists in CryptoNow — created by the Confirm above.

There’s also a Node SDK — crypto-now-node-api-sdk (npm) — wrapping these calls.

4. Repeat deposits reuse the same address

Because you stored and reuse the wallet, a returning customer gets the same address. Below, a second, separate deposit (different deposit ID) resolves to the identical address — so a customer who re-uses an old address is still credited.

A second deposit request showing the same destination address — A later deposit (new ID) → the same address.

5. The customer pays

Once the payment lands, your platform shows it as deposited:

Deposit status Deposited — Deposit confirmed in-platform.

6. Receive the callback

CryptoNow fires a callback to your URL on each client-wallet replenishment. The body is encrypted; the JWT carries the walletId and an encrypted salt, so the decrypt is self-contained (decrypt code for Node / PHP / Python is in the API docs). Decrypted, it carries the transaction details you use to credit the user.

import CryptoJS from 'crypto-js';

const decrypt = (encrypted, salt) =>
  CryptoJS.AES.decrypt(encrypted, salt).toString(CryptoJS.enc.Utf8);

// req.headers.authorization = "Bearer <jwt>"; req.body.data = encrypted payload
const { id: walletId, salt } = decodeJwt(req.headers.authorization.slice(7));
const finalSalt = decrypt(salt, walletId);
const payload = JSON.parse(decrypt(req.body.data, finalSalt));
// → { typeTransaction: "Replenishment", currency: "USDT", amount: "10",
//     wallet: { id }, payer, incomingTxHash, ... }

Confirm deliveries under Settings → Outgoing Webhooks — an InitialReplenishmentDetect then a Replenishment, both delivered (Status True):

Outgoing Webhooks list with Replenishment entries and the JSON payload — Webhooks delivered, with the decrypted payload.

If you passed a clickId when creating the charge/wallet, it comes back as outsideOrderId — use it to map the payment to your order/user.

7. Settlement: throughput vs. actual balance

The client wallet doesn’t hold funds — it sweeps everything to your account wallet — so the figure it shows is cumulative throughput, not a live balance. Here it reads 10 USDT (the amount that passed through):

Client wallet showing 10 USDT throughput — Client wallet — 10 USDT throughput (not a current balance).

The account wallet holds the actual funds: 9.95 USDT — the 10 USDT deposit minus the 0.5% system fee (0.05 USDT) on replenishment. The swept replenishment transaction shows the client → account hop, the miner fee (paid in ETH from the account wallet) and the on-chain hashes.

Account wallet balance 9.95 USDT with the replenishment transaction details — Account wallet — 9.95 USDT actual, after the 0.5% replenishment fee and sweep.

This whole flow relies on auto-sign being ON (the default). It fronts gas for the sweep and lets the callback complete — disabling it breaks deposits. See Secure your account.

Getting Started

Get paid

Pay out

Manage your crypto

Fix problems

Permanent deposit addresses

1. Set the callback URL, then generate API keys

2. Get your account wallet’s Wallet ID + passphrase

3. The customer starts a deposit — and the wallet is minted

4. Repeat deposits reuse the same address

5. The customer pays

6. Receive the callback

7. Settlement: throughput vs. actual balance

​1. Set the callback URL, then generate API keys

​2. Get your account wallet’s Wallet ID + passphrase

​3. The customer starts a deposit — and the wallet is minted

​4. Repeat deposits reuse the same address

​5. The customer pays

​6. Receive the callback

​7. Settlement: throughput vs. actual balance

1. Set the callback URL, then generate API keys

2. Get your account wallet’s Wallet ID + passphrase

3. The customer starts a deposit — and the wallet is minted

4. Repeat deposits reuse the same address

5. The customer pays

6. Receive the callback

7. Settlement: throughput vs. actual balance