CryptPays

Payments

Create and track payments

Create or reuse a deposit address, configure callback delivery, and reconcile each independent blockchain payment.

Overview

Payment addresses

Supply a callback_url and merchant payout address_out. CryptPays returns an address_in for the customer to pay. The create request is amount-independent: it does not register an invoice amount, and each qualifying blockchain deposit is processed as a separate payment.

Merchantcallback_url + address_out
CryptPaysaddress_in
Customer depositindependent forwarding and callback lifecycle

See address families, minimum transactions, confirmations, priority, and accounting.

Create

Create a payment address

Both route forms accept GET or POST. The route selects the requested network and asset; no ticker is required in the request body.

GET | POST/api/{ticker}/create

Use a canonical ticker such as bep20_usdt.

GET | POST/api/{chain}/{token}/create

Use separate chain and token path segments when preferred.

Request contract

Create parameters

Only callback_url and address_out are required. Optional values apply when a new configuration is created; they do not update a compatible existing configuration.

Complete public /create parameter reference
ParameterRequiredTypeDefaultDescription
callback_urlYesURL, max 2048—Stable callback destination and payment identity. Production URLs must use HTTPS and resolve safely to a public destination. Merchant query parameters such as ?order_id=123 are preserved.
address_outYesString, max 500—Single merchant payout address, valid for the requested network.
pendingNoInteger: 0 or 10Set to 1 for an optional early pending notification after a qualifying deposit is detected.
confirmationsNoInteger ≥ 1Network defaultRequests a numeric-chain threshold. Values below the operator default use the default; values above the configured maximum are rejected. Solana accepts the value for compatibility but retains its 0/1 finality model.
postNoInteger: 0 or 100 delivers GET callbacks; 1 delivers POST callbacks.
jsonNoInteger: 0 or 10With post=1, selects JSON when 1 and form encoding when 0. With post=0, delivery remains GET.
priorityNoStringdefaultSyntactic values are slow, default, and fast; network support differs.
convertNoInteger: 0 or 10Set to 1 to request USDT-denominated conversion snapshot fields when a valid confirmed price exists.

Callback transport

Default: GET

Omit post, or use post=0. The json value does not change GET delivery.

Form POST

Use post=1 and json=0 for application/x-www-form-urlencoded.

JSON POST

Use post=1 and json=1 for application/json. Recommended for new integrations, but not the API default.

Network priority support

Accepted merchant priority by family
Network or familySupported valuesNotes
BTC, LTC, BCH, DOGEslow, default, fastSelected priority affects the actual forwarding fee rate.
SOL and SPLslow, default, fastSelected priority affects Solana compute-unit pricing.
EVM, ZEC, TRONdefault onlyExplicit slow or fast returns 1103 UNSUPPORTED_PRIORITY.

Examples

Create requests

All addresses and identifiers are illustrative. Replace them with values valid for the selected network.

Minimal request — callback delivery remains GET

Shell
curl -X POST 'https://api.cryptpays.com/api/bep20_usdt/create' \
  -H 'Content-Type: application/json' \
  -d '{
    "callback_url": "https://merchant.example/payments/callback?order_id=123",
    "address_out": "0x1111111111111111111111111111111111111111"
  }'

Recommended JSON POST callbacks

Shell
curl -X POST 'https://api.cryptpays.com/api/bep20_usdt/create' \
  -H 'Content-Type: application/json' \
  -d '{
    "callback_url": "https://merchant.example/payments/callback?order_id=124",
    "address_out": "0x1111111111111111111111111111111111111111",
    "post": 1,
    "json": 1
  }'

Optional pending notification

Shell
curl -X POST 'https://api.cryptpays.com/api/bep20_usdt/create' \
  -H 'Content-Type: application/json' \
  -d '{
    "callback_url": "https://merchant.example/payments/callback?order_id=125",
    "address_out": "0x1111111111111111111111111111111111111111",
    "post": 1,
    "json": 1,
    "pending": 1
  }'

Custom confirmations and priority

Shell
curl --get 'https://api.cryptpays.com/api/bitcoin_btc/create' \
  --data-urlencode 'callback_url=https://merchant.example/payments/callback?order_id=126' \
  --data-urlencode 'address_out=bc1qexamplemerchantaddress000000000000000000' \
  --data-urlencode 'confirmations=6' \
  --data-urlencode 'priority=fast'

Success response

Create response

The response contains the effective existing or newly created configuration. Monetary values are decimal strings.

JSON
{
  "address_in": "0x2222222222222222222222222222222222222222",
  "address_out": "0x1111111111111111111111111111111111111111",
  "callback_url": "https://merchant.example/payments/callback?order_id=124",
  "priority": "default",
  "minimum_transaction_coin": "1.250000000000000000",
  "status": "success"
}
Successful create response
FieldTypeMeaning
address_inStringDeposit address to present to the customer.
address_outStringStored merchant payout destination.
callback_urlStringExact stored callback URL identity.
priorityStringStored effective transaction priority.
minimum_transaction_coinDecimal stringMinimum snapshot stored when this address configuration was created.
statusStringsuccess.

For current network economics, consult asset info or the live catalog; an older wallet snapshot can differ from the current minimum.

Identity and reuse

Address reuse is immutable

The exact callback URL and address family identify a configuration. A compatible repeated create returns the existing values; it is not an update operation.

Compatible family

Same callback URL and EVM family—for example BSC then Ethereum—returns the same address_in and original configuration.

Incompatible family

Same callback URL across families—for example EVM then Bitcoin—returns HTTP 409 with 1202 CALLBACK_ADDRESS_FAMILY_CONFLICT.

Keep the callback URL string stable. Do not assume normalization of query ordering, trailing slashes, or host casing. See Address Families.

Customer instructions

Presenting address_in

Show the deposit address together with the intended network and asset. Display or enforce the current minimum from /info or /cryptocurrencies; /create does not register an expected amount.

  • State the intended network and asset clearly.
  • Use current public metadata for the applicable minimum.
  • Treat every incoming blockchain transaction as an independent payment.
  • Reconcile using the stable callback UUID and payment logs.

Processing threshold

Below-minimum deposits

A deposit below the current processing minimum is not forwarded and produces neither a pending nor a confirmed callback. It is not combined with another deposit; a later valid deposit remains independent.

Use the live minimum before presenting payment instructions. See Minimum Transactions and troubleshooting.

Reconciliation

Payment logs

Look up payment and callback-delivery history using the canonical ticker and exact callback URL stored at creation.

GET/api/{ticker}/logs?callback=...

The callback query parameter is required. Encode it as a query value and keep the underlying callback URL string identical to the stored value.

Shell
curl --get 'https://api.cryptpays.com/api/bitcoin_btc/logs' \
  --data-urlencode 'callback=https://merchant.example/payments/callback?order_id=126'

Each item in callbacks includes the same stable uuid sent in merchant callbacks. For UTXO payments, txid_in is the bare transaction hash and vout is a separate integer.

Practical notes

Integration checklist

  • Use a unique, stable callback URL per order and address family.
  • For new integrations, prefer post=1 with json=1, while recognizing that GET remains the API default.
  • Verify callback signatures before trusting payment data.
  • Return exactly HTTP 200 after successful callback processing; the response body is ignored.
  • Use callback UUIDs for idempotency and logs reconciliation.

Continue with Callbacks for delivery details and API Reference for compact endpoint schemas.