Create New Payment Address

Generates a new unique cryptocurrency address for your customer. All funds sent to this address will be forwarded to your wallet(s). This endpoint behaves similarly to CryptAPI’s /{ticker}/create/.

GET https://api.kingpay.online/{ticker}/create/

Replace {ticker} with the target cryptocurrency/network (e.g. btc, eth, trc20/usdt).

Notices

The full request URL must not exceed 8192 characters.
Always check the minimum transaction amount for the selected coin/network. Payments below the limit will be ignored by the network.
The same callback URL will always generate the same address_in. Use GET parameters (e.g. ?invoice_id=123) to generate different addresses.
It is recommended to URL-encode the callback value to avoid issues with GET parameters.

Path parameters

ticker string • required

Cryptocurrency + network identifier.

btc — Bitcoin mainnet
eth or erc20/eth — native Ethereum
bnb or bep20/bnb — native BNB
trx or trc20/trx — native TRX
solana or sol/sol — native SOL; sol alone is not a route
trc20/usdt — USDT on TRON TRC-20

Example: https://api.kingpay.online/trc20/usdt/create/

Query parameters (required)

callback string • required

Public URL where we will send IPN callbacks (payment status updates).

Must be a valid and reachable HTTP/HTTPS URL.
All GET parameters you append (e.g. ?invoice_id=123) will be included in every callback.
GET parameters are preserved even when using post=1 or json=1.

Example: https://example.com/ipn/cryptapi?invoice_id=123

address string • required

Your own forwarding address (or multiple addresses using distribution shares).

Multiple addresses format: 0.7@addr1|0.3@addr2

Shares must sum to 1.0 and addresses must match the selected ticker.

Query parameters (optional)

pending integer • optional

Legacy notification option, retained for compatibility. Payment lifecycle notifications use payment_status. UTXO, EVM and TRON report confirmation progress; Solana sends confirmed and completed without pending depth updates. Detection is not a mempool notification.

confirmations integer • optional

Incoming confirmation threshold for UTXO, EVM and TRON (minimum 1). Defaults to 1 when omitted or invalid: zero, negative values, fractions, non-digit text and integers above 9007199254740991 fall back to 1. A confirmed callback also requires successful execution checks. TRON distribution waits separately for at least 23 confirmations for TRX or 20 for TRC20 and a successful solidified receipt; a higher requested threshold is respected. Solana does not enforce custom numeric depth: both callback confirmation fields are 1, representing the accepted network stage (finalized for SOL discovery, confirmed for SPL).

post integer • optional

post=1 — send form-encoded HTTP POST callbacks (default is GET). Can be combined with json=1; JSON takes precedence.

json integer • optional

json=1 — send HTTP POST callbacks with an application/json body. Takes precedence over post, including when post=0.

priority string • optional

Transaction fee priority for forwarded payments. Supported only on BTC/ETH/LTC networks.

multi_token integer • optional

multi_token=1 allows accepting any supported token on the same chain (e.g. any TRC20 token when using TRON). Use only if your system handles multi-token payments.

min_split_amount float • optional

Defines the minimum received amount (in USDT-equivalent) required to apply the split distribution defined in address. If the incoming payment is smaller than this threshold, the entire amount will be forwarded to the address that has the largest percentage in your split configuration.

When the received amount is >= min_split_amount → normal percentage split applies.
When the received amount is < min_split_amount → all funds go to the address with the highest percent.
The value must be provided as a float representing USDT equivalent.

Example: &min_split_amount=25

convert integer • optional

convert=1 — expand available USD conversion values into fiat maps in value_coin_convert and value_forwarded_coin_convert. Each map is a JSON-encoded string in every transport, including JSON POST. Missing or nonpositive conversion values produce the string "{}".

Request example (cURL)

curl -G \
  'https://api.kingpay.online/btc/create/' \
  --data-urlencode 'address=YOUR_BTC_FORWARDING_ADDRESS' \
  --data-urlencode 'pending=1' \
  --data-urlencode 'confirmations=3' \
  --data-urlencode 'callback=https://example.com/ipn?invoice_id=123'

Replace YOUR_BTC_FORWARDING_ADDRESS with your Bitcoin receiving address. When the callback URL contains query parameters, put callback last in the request query. Use the same callback URL when requesting payment logs.

Response (200 • application/json)

{
  "status": "success",
  "address_in": "14PqCsA7KMgseZMPwg6mJy754MtQkrgszu",
  "address_out": "1H6ZZpRmMnrw8ytepV3BYwMjYYnEkWDqVP",
  "callback_url": "https://example.com/ipn?invoice_id=123",
  "priority": "default",
  "minimum_transaction_coin": 0.008
}

Response fields

status — always "success" on successful address creation.
address_in — the generated payment address shown to the customer.
address_out — your forwarding address(es).
callback_url — the exact callback URL saved for this address.
priority — forwarding fee priority (if supported).
minimum_transaction_coin — minimum accepted transaction amount.