Crypto Payment Gateway API: 12 Things to Check Before You Integrate
Every crypto payment API can create an invoice. The differences show up under retries, partial payments and failed webhooks. A 12-point checklist for developers, with how the mistKET API handles each point.
Every crypto payment gateway API promises the same thing: create an invoice, get paid, receive a callback. The differences only show up later — when two requests race, when a customer sends a little less than the invoice, when your server is down for an hour, or when an attacker replays a captured request. Choosing the API carefully saves far more time than integrating it quickly.
This is a checklist for developers and CTOs comparing crypto payment APIs before they write any code. For each point you will see what to look for, why it matters and how the mistKET API handles it. If you have already chosen and want the step-by-step code, jump to our crypto payment API integration guide.
The minimum endpoint surface
A usable crypto payment API needs more than "create payment". At a minimum, look for:
| Capability | Why you need it | mistKET endpoint |
|---|---|---|
| Create invoice | One payment request per order, with expiry | POST /invoices |
| Fetch invoice | Reconcile when a webhook is missed | GET /invoices/{uuid} |
| List and filter invoices | Back-office views and nightly reconciliation | GET /invoices |
| Cancel invoice | Release stock when an order is abandoned | POST /invoices/{uuid}/cancel |
| Supported assets | Show only networks that can be paid right now | GET /assets |
| Rate quote | Display the crypto amount before creating an invoice | GET /rate |
| Health check | Monitoring and graceful fallbacks | GET /health |
If a provider cannot fetch or list invoices, you are forced to trust webhooks blindly — a bad position the first time a delivery fails.
1. Authentication: is every request signed?
An API key sent in a header is the weakest option: anyone who intercepts or leaks it can create and cancel invoices. Prefer an API where each request is signed with a secret that never travels over the wire. mistKET requests carry X-Api-Key, X-Api-Timestamp and an HMAC-SHA256 signature of the timestamp and raw body. The secret is shown only once in the merchant panel.
2. Replay protection
A signature alone does not stop someone from resending a captured request. Look for a timestamp window and nonce support. mistKET rejects timestamps more than ±300 seconds from server time and refuses the same signature twice for state-changing requests. Its signature version 2 adds a per-request nonce and signs the method and path as well, so a signature cannot be reused on a different endpoint.
3. Idempotency on invoice creation
Networks time out. If your checkout retries a "create invoice" call, you must not end up with two invoices for one order. A good API offers an idempotency key. In mistKET your own order_id plays that role: calling again with the same order ID returns the existing invoice with "idempotent": true instead of creating a new one.
4. A status model that covers real payments
"Paid / not paid" is not enough. Customers send slightly too little because an exchange deducted a fee, or too much, or pay after expiry. Check that the API exposes these cases explicitly. mistKET invoices move through new, pending, underpaid, paid, confirmed, overpaid, expired and cancelled, with fields such as paid_amount, remaining_amount, can_pay_remaining and under_review so your code never has to guess.
paid means the transfer was detected and is waiting for confirmations; fulfil orders only on confirmed or overpaid.5. Confirmations you can see
The API should tell you how many block confirmations a payment has and how many are required, plus the transaction hash and an explorer link. That turns payment support tickets into quick lookups. mistKET returns confirmations, required_confirmations and a transactions[] array with hash, amount, status and explorer URL for every invoice.
6. Rate locking and pricing currencies
You price in fiat; the customer pays in crypto. Ask which fiat currencies are accepted and how long the quoted rate is held. mistKET accepts prices in USD, EUR, TRY, RUB, GBP and AED (or directly in the crypto symbol), locks the rate for the invoice lifetime and lets you set the lifetime between 5 and 1,440 minutes per invoice.
7. Network selection
Can you fix the network in the API call, or let the customer choose on the hosted page? Both are useful: fixing it suits bots and automated flows, letting the customer choose reduces wrong-network payments. mistKET supports both via pay_currency + network or asset_id, and GET /assets reports available: false when a network has no free address. USDT on TRON (TRC-20) is enabled today; further assets and networks are enabled per merchant on request. See USDT TRC20 vs ERC20 for why TRON is the common default.
8. Signed, retried and traceable webhooks
Webhooks are where most integrations break. Check four things: the payload is signed, there is a timestamp to reject stale deliveries, failed deliveries are retried for hours (not seconds), and each delivery has an ID you can use for deduplication. mistKET signs webhooks with a separate webhook secret, sends X-Mistket-Delivery and X-Mistket-Event headers, and retries non-2xx responses at 10 s, 30 s, 2 min, 10 min, 30 min, 1 h, 2 h and 3 h, with the delivery history visible in the dashboard. Our article on crypto payment webhooks covers handler design in depth.
9. Errors and rate limits that are documented
You should know in advance what a bad signature, a blocked IP or a validation error looks like. mistKET returns a consistent { "success": false, "error": … } body with per-field details for validation errors, uses standard codes (401, 403, 404, 422, 429, 503) and documents its limit: 120 requests per minute per API key.
10. Network-level controls
An IP allow-list means a leaked key is useless from anywhere except your servers. mistKET lets you set one in the dashboard; requests from other addresses get 403. Combined with signed requests and short timestamp windows, this closes the most common attack paths.
11. No SDK lock-in
SDKs are convenient until they lag behind your language version. An API built on plain HTTPS and JSON, where signing is a single HMAC call, works from PHP, Node.js, Python, Go or a shell script. mistKET publishes copy-paste clients for PHP, Node.js and Python in its API documentation, but none of them is required.
12. A manual path for non-developers
Even API-first businesses need to bill a one-off client. Check that invoices can also be created in a panel and shared as a link, so sales and support do not have to call developers. In mistKET, the same invoices are available in the merchant panel, and every hosted checkout page works as a payment link.
GET /invoices/{uuid} and compare. It verifies your signing, your webhook handler and your reconciliation in a single pass.Red flags when evaluating a crypto payment API
- Unsigned webhooks or webhooks "secured" only by a secret URL.
- No way to fetch an invoice after creation.
- No underpaid or overpaid status — edge cases end up in support chat.
- Retries for a few minutes only, or no delivery log.
- Undocumented rate limits and error formats.
- Pricing that is unclear per transaction — compare with our guide to crypto payment gateway fees.
Getting API access to mistKET
Merchants are onboarded by the mistKET team: message @mistnetwork on Telegram with your website, business type and expected volume. Once approved you create your API key, secret and webhook settings in the merchant panel. A typical integration takes an afternoon.
Review the developer section, the pricing and the full API reference before you start.
