Confirmations

The number of blocks recorded on a network since, and including, the block that holds a transfer; every further block makes reversing that transfer harder.

#How it works in CryptoLike

CryptoLike sets a confirmation threshold for every asset in its catalogue. GET /v1/currencies returns it in the confirmations field of each asset, and the supported coins page shows the same value. A payment becomes paid, and the funds are credited to your balance, only when its transfer reaches that threshold on its network.

While the transfer is below the threshold, the payment is pending. The checkout page says "Payment detected. Waiting for confirmation." and shows confirmations.current of confirmations.required, usually with an estimate in minutes. You receive invoice.pending when the transfer is first seen and invoice.paid when it is confirmed. Deposits to a static address follow the same rule: deposit.pending, then deposit.confirmed (or deposit.on_hold if a compliance review holds the funds), with confirmations and required_confirmations in the deposit object.

If a chain reorganisation rolls a confirmed transfer back, CryptoLike recomputes the payment and sends invoice.reverted (deposit.reverted for a static address). Ship on paid, stop fulfilment on reverted and wait for a new invoice.paid; what a reorg does before and after the threshold is explained in block reorganisations explained. Payouts count confirmations too: a withdrawal in broadcast becomes completed when the asset's requirement is met. More detail: how many confirmations a crypto payment needs.

#Example

The CryptoLike public catalogue lists every asset with its network, decimals and confirmation threshold — the same numbers the checkout page shows the customer. Read it before you build an order flow that depends on timing, and do not promise customers an exact time: blocks arrive at the network's pace. The unsigned request returns the public catalogue:

curl -s https://api.cryptolike.net/v1/currencies