Error Codes

The token-exchange x-client-id / x-api-key is incorrect, the key is disabled or expired, or its rotation overlap window has closed

In order of frequency: ① Incorrect headers. Token exchange uses the two custom headers x-client-id + x-api-key, not Authorization: Bearer or body fields. An empty value and an incorrect secret produce the same response, so having entered a value does not rule out a misspelled header name. ② Using signing_key as api_key. Each key supplies two values: the former for signatures, the latter for token exchange; they appear next to each other in the console. ③ The key is disabled (not active) or expired. ④ Old credentials have passed the rotation overlap window. This is a hard boundary with no grace period in the code. ⑤ x-client-id and x-api-key come from different keys, or the credentials belong to another deployment environment.

Access token missing, malformed, or expired (30-minute validity), or its key is disabled, expired, or reassigned

① Expired token: validity is 30 minutes. Caching a token without refreshing according to expired_at, or arbitrarily refreshing once an hour, is among the most common integration errors. ② Incorrect header: both x-auth-token and Authorization: Bearer <token> are accepted. Sending api_key directly as a bearer token also results in this error. ③ The key was disabled, deleted, or expired before the token expired. The key row is read on every request; revocation does not wait for token expiration. ④ The merchant in the token no longer matches the merchant resolved from the key, because ownership changed or sandbox/live tokens were mixed. The latter generally hits environment_mismatch first.

Signature mismatch, or any of the three headers x-timestamp / x-nonce / x-signature is missing

① Reserialized body: hash the exact raw bytes you send. If your JSON library changes key ordering, whitespace, or escaping, signatures will consistently mismatch and resemble a misconfigured secret. ② Missing query in the second signing component: it is PATH_WITH_QUERY. Signing only /v1/x for /v1/x?a=1 always fails. ③ Any of the three signing headers is missing: x-timestamp / x-nonce / x-signature. Missing headers and incorrect signatures use the same code, so calculating a signature does not prove that all headers were sent. ④ Using api_key instead of signing_key. ⑤ The five components are not joined with newlines, or the method is not uppercase. ⑥ Hashing an empty body as sha256("{}") instead of sha256(""). ⑦ x-timestamp is not numeric. A numeric value in milliseconds produces timestamp_out_of_range instead.

This endpoint requires signing. POST /v1/deposits always requires a signature regardless of key configuration; it is the only entry point that directly creates member balance

Currently has no emission sites. Missing signing headers produce invalid_signature in the validation function; no code path emits this code. It remains in the catalog to avoid documentation and code repeatedly removing each other’s entries. Mandatory signing for POST /v1/deposits is real; only a dedicated code is absent.

x-timestamp (Unix seconds) differs from our clock by more than ±300 seconds

① Milliseconds used for the timestamp (13 digits). The value is numeric, so it bypasses invalid_signature and appears here as a difference of many thousands of years. This is much more common than actual clock issues. ② Clock drift on the signing machine: containers or VMs without NTP can drift beyond 5 minutes after weeks without a restart. ③ Local-timezone “seconds” instead of Unix seconds, producing a whole-hour offset. ④ The request spent over 5 minutes in your own queue or retry system, with a timestamp generated when queued.

This x-nonce has already been used within the 5-minute replay window

① Reusing the previous nonce on retry. The two rules point in opposite directions: change the nonce but retain the idempotency key. Generating them together causes this error on the first retry. ② Deriving the nonce from request contents, such as a body hash or order ID, so every retry of the same transaction has the same value. ③ Multiple processes or containers share a pseudorandom seed and generate the same value in the same millisecond. ④ Your gateway transparently retries and sends the same request twice unchanged. The window is 5 minutes, namespaced by merchant + environment; sandbox and live are independent.

The access token’s environment does not match the current deployment

① The cached access token belongs to another deployment environment. ② The token was issued before an environment-rule update.

This API key lacks the scope required by the endpoint

① A restricted scope was selected: deposits:write / cards:secure. At key creation these only enter the pending-approval list; they may look selected on the key detail page while none are effective. This is easily mistaken for a bug. ② Only read was selected. Write automatically includes read for the same resource, but not vice versa. ③ Misspelled scope key: unrecognized catalog keys are silently discarded during expansion, so the scope is absent without an error. ④ One of our routes lacks a scope declaration; the fallback denies with 403 rather than allowing access. If you are certain all scopes are present, open a ticket with request_id.

The caller’s outbound IP is not on this key’s allowlist

① You changed or added a server, or egress uses a changing NAT pool / serverless runtime with no fixed IP. ② The allowlist uses a prefix length other than /24, /16, or /8, such as /22 or /26. Only those three are recognized; others never match and produce no error. They appear configured but have no effect. ③ Egress uses IPv6. CIDR matching uses dotted-decimal notation; IPv6 requires individual exact addresses. ④ A live key required an allowlist at creation, but you are testing from a local machine or CI.

Merchant entity unavailable. Four internal states share one code: nonexistent / suspended / frozen / closed

① The merchant is suspended: reads still work; all writes are denied. Being able to read but not write usually indicates an accounting or compliance task awaiting resolution; this is the most common of the four cases. ② Frozen / closed: both reads and writes are denied. ③ The merchant entity cannot be found: the sandbox shadow entity has not yet been created lazily during the first sandbox token exchange, or the token is not for your merchant. ④ A newly introduced merchant status is not recognized here. Unknown values are denied conservatively, never allowed by default.

Write endpoint called without x-idempotency-key

① Missing x-idempotency-key on a write endpoint. Every write endpoint has idempotency middleware, without exceptions; do not assume an endpoint does not need it. ② Copying another provider’s header name: Idempotency-Key lacks the x- prefix and is not recognized. ③ Putting the key in the body rather than a request header.

Idempotency key is not UUID-shaped: hexadecimal 8-4-4-4-12

① A key built from an order ID plus a timestamp usually does not match the hexadecimal 8-4-4-4-12 shape. ② UUID enclosed in braces or missing hyphens. ③ A ULID, snowflake ID, or base64 random string. ⚠ Validation checks shape, not version bits. The message says UUID v4, but v1/v7 also pass. Switching to v4 is not the remedy if the shape remains wrong.

This endpoint prices at execution time; supplying a quote ID does not lock the price

You supplied quote_id to an endpoint that does not support price locking. Currently only POST /v1/merchant/conversions, for internal reallocation of the merchant’s own prepaid assets, returns this code. ⚠ Member exchange no longer returns it. Its price lock now works: call POST /v1/exchange/quotes with lock: true to obtain quote_id, then supply it to POST /v1/exchange/orders to execute at that quote. Expired quotes are always rejected, with no fallback to a new price. Receiving this code for member exchange means you are calling an older version.

This key was used before, but the request body or target endpoint now differs

① Generating keys per member, day, or order ID rather than per individual call; the member’s second transaction then conflicts. ② Changing a field after a failed response and resending with the original key, such as altering an amount or adding an optional parameter. The request hash covers only the body, not headers. Changing headers does not count; changing one body byte does. ③ Reusing the key at another endpoint, which is also included in the comparison. ④ Declaring the key variable outside a batch loop, causing all requests to share it. ⚠ After the 24-hour window, the same key is accepted as a new request and no longer produces this code.

The first request using this key is still processing

① Two of your processes or machines sent the same transaction concurrently, for example duplicate queue delivery or a scheduled task overlapping manual action. ② You retried immediately after the first request timed out while our original operation was still running; this is normal for fund-moving endpoints. ③ The first request’s final write failed on our side, which is rare. Its key can remain processing until the 24-hour window expires and a new request is accepted. Open a ticket if this persists for several minutes; do not retry indefinitely.

Member nonexistent, or not yours, or suspended; all three produce the same response

① Unrecognized x-on-behalf-of identifier. Only two forms are accepted: your external_member_id or our public mem_<uuid>. Email, phone number, and a bare UUID without mem_ are not recognized. ② Sandbox and live use two merchant entities and separate member sets. A member created in sandbox does not exist in live. ③ The member belongs to another merchant. ④ You suspended the member using POST /v1/members/{id}/suspend. ⑤ You blocklisted the member in the console. Blocklisting and suspension are independent flags, both returning this response. ⚠ The latter two are restrictions you applied yourself. Check the member’s console status before investigating code.

This endpoint is member-scoped, but x-on-behalf-of is missing

① Missing x-on-behalf-of on a member-scoped endpoint, often after copying code from a merchant-entity endpoint such as GET /v1/merchant/balances. ② The header is present but empty or whitespace-only; its trimmed value must be nonempty. ③ An intermediate gateway or service mesh stripped an unrecognized custom header. Signature validation often also fails in this case.

This member is suspended

Currently has no emission sites. Suspension is checked while resolving x-on-behalf-of and deliberately maps to member_not_found, together with nonexistent, another merchant’s, and blocklisted members. Distinguishing them would expose cross-merchant member discovery. The catalog entry remains to avoid documentation and code repeatedly removing each other’s entries; do not branch on it.

Quick KYC is not available for this merchant

Quick KYC is not enabled for this merchant. quick_kyc_enabled on the merchant’s platform-admin record defaults to off.

The member has reached the Quick KYC profile limit

The member already has 5 Quick KYC profiles assigned. This per-member limit is strict.

No matching unassigned Quick KYC profile

The profile pool contains no unassigned profile matching the card product’s country and document type.

Insufficient funds for the Quick KYC usage fee

The first assignment costs 10 USDT. Platform-direct operation debits the member’s available balance; downstream merchant_hosted debits your prepaid balance. Insufficient funds fail the entire operation without reserving a profile.

The member’s KYC level is below this product line’s requirement

① The member is at level 0. Members created through the Open API have no KYC, while most product lines require L1. This accounts for almost all cases during integration. ② Cumulative thresholds triggered: earlier transactions succeeded, then one suddenly requires KYC. This is easily mistaken for a bug but is a trigger in the requirements table; remittance and QR payments each have one. ③ The product requires L2, such as personal remittance or some card products, but the member only has L1. ④ For internal transfers, the recipient may lack KYC. The sender can receive this code with complete documentation; the other person needs to act. ⑤ Cardholder information is incomplete: missing fields rather than an insufficient level.

The member’s available balance in this asset is insufficient

① The member’s available balance in the asset is genuinely insufficient. Available excludes locked, withdrawal-in-transit, Earn, and card balances; using the total can misleadingly suggest sufficient funds. ② Fees were omitted: principal is covered, but principal plus fees is not. ③ An Earn redemption exceeds holdings; it debits the Earn bucket, not the available balance. ④ QR payment cannot find any debit asset with sufficient funds after trying every asset in payment-preference order. ⑤ The balance no longer covers the new total at remittance reconfirmation, despite covering the original order. ⑥ The branch in POST /v1/deposits is a defensive fallback: reports only increase balance and normally cannot reach it. Open a ticket if it occurs there.

Your prepaid account has insufficient available funds

Currently has no emission sites. Insufficient prepaid funds never produce this code: asynchronous order lines, remittance and card issuance, queue without an immediate error; instant-execution lines, QR payments, exchange, Earn, and withdrawals, return service_unavailable. The entry remains to avoid documentation and code repeatedly removing each other’s entries. Follow the action instructions to investigate funding instead of waiting for this code.

Confirming this withdrawal would make your custody declaration for this asset negative; you are confirming funds you never declared

The only emission site is POST /v1/withdrawals/{id}/confirm, the confirmation step of two-phase withdrawals. ① An on-chain deposit was never reported through POST /v1/deposits. The member balance came from another source, such as migrated history or an operations adjustment, without a corresponding custody declaration. ② The report used the wrong asset, placing the custody declaration under another asset. Each asset is accounted for separately; assets do not offset each other. A sufficient aggregate reported amount is not evidence against this error. ③ One of our product lines omitted the merchant custody leg. Our side will have an invariant alert; open a ticket with request_id.

This product is not authorized for you, is no longer on sale, or its activation prerequisites are unmet

① The product record itself is unavailable: an Earn product is delisted, ended, paused, or not yet on sale, all sharing one code; this exchange direction is disabled (USDT→USD and USD→USDT are independent records); internal transfers are globally disabled; or the withdrawal asset × network has no channel. ② Card issuance: BIN capacity exhausted, inventory empty, unsupported country, product not authorized for you, quick applications disabled, or unavailable provider. ③ This remittance line, express / personal, or this asset is not available to you. ④ The personal remittance line requires an upstream subaccount for the member, which is absent. ⚠ A disabled merchant product-line switch returns service_unavailable, not this code. Both require your account manager, but investigation starts in different places.

This card does not currently support this operation

The current card product does not enable the requested operation.

A limit was reached. Inspect limit_type (single per transaction / daily daily cumulative) and limit_scope (merchant yours / member the member’s)

① Member daily cumulative amount or transaction count, with separate limits for six lines. This is the most common case: orders work in the morning but not in the afternoon. ② Single-transaction limit (limit_type: single). ③ Merchant-side checks on POST /v1/deposits: per-transaction and daily cumulative limits with limit_scope: merchant. They prevent a compromised key from creating unlimited balance; normal activity should not reach them. Investigate possible abuse first, then consider an increase. ④ Record count rather than amount limits, such as withdrawal and deposit address books. Splitting amounts does not help. ⑤ Cards: cardholder count, quick-application count, or card limits. ⚠ Both additional fields may be omitted. Do not assume a member limit when limit_scope is absent.

The amount is outside the product’s permitted range: below its minimum subscription/remittance amount, above its single-transaction maximum, or below the minimum ledger unit after fees.

① Below the product’s minimum subscription, top-up, or remittance amount. Small one-unit integration test requests commonly hit this. ② Above the product’s maximum transaction amount. This differs from the single-transaction allowance in limit_exceeded: a product range can be satisfied by changing the amount, whereas an allowance may require waiting or an increase. ③ Fees consume the principal, or the conversion yields less than one minimum ledger unit; small exchange and remittance tests often hit this. ④ Earn, internal transfers, and QR payments each have min/max ranges configured separately from allowances. Increasing an allowance does not make this transaction valid.

Risk-control rejection. This is the only public risk-control code: no reason, rule name, threshold, or score

① The member is restricted: account frozen, closed, restricted, or blocklisted. This is currently the most common cause because all risk rules default to disabled and cannot match until enabled. ② The upstream explicitly rejected this transaction, such as card top-up, card withdrawal, freeze/unfreeze, or binding. The upstream is reachable and has made a decision; retrying does not change it. ③ A risk rule matched block, which is only possible after the corresponding rule is enabled in our administration console. ④ The recipient is blocklisted: a remittance payee or internal-transfer recipient member. ⑤ A document number is already used elsewhere. Cross-merchant existence information is collapsed into this code without identifying the conflict. ⚠ The decision criteria are never exposed, so the response cannot distinguish these cases. First inspect the member’s restriction status in your merchant console; that is the part visible to you.

This action requires the end user to complete strong authentication. The response includes challenge_id, hosted_url, and expires_at

① The endpoint inherently requires strong authentication, such as adding a withdrawal address, activating a card, or obtaining a card-secret viewing ticket. The first call always receives this code; it is a workflow step, not an error. ② The ticket expired after 5 minutes or has already been used once, while the retry supplied the old challenge_id. ③ The ticket’s member or action does not match the request: a freeze-card ticket cannot reveal card secrets. ④ The end user did not actually finish factor verification on the hosted screen; the ticket’s passed flag remains 0. ⑤ The exchange direction is configured to require step-up. The current Open API rejects this case and does not return challenge_id / hosted_url, because there is no hosted flow for it. A step_up_required without those fields identifies this case. Ask us to disable step-up for that direction before using it.

The order has passed the point at which it can be cancelled

Only two emission sites: POST /v1/withdrawals/{id}/confirm and /fail. ① The transaction has already reached the other terminal state: confirming then marking failed, or vice versa. ② Concurrent processes issue confirm and fail for the same transaction; the losing one receives this code. ③ The transaction never entered a state eligible for advancement. ⚠ Repeating the same terminal state returns an idempotent replay with replayed: true, not this code. ⚠ A remittance past its cancellation point returns state_invalid, not this code.

The asset is not on your allowlist, is disabled on the platform, or has no available channel for this asset × network

① The asset is outside your deposit allowlist. ⚠ Allowlists restrict access: no entries means all enabled assets are usable; after the first entry is added, every unlisted asset is denied. This transition is a common trap: previously available assets can suddenly become unavailable. ② The platform has not enabled the asset. ③ The asset × network has no available channel, commonly during deposit-address creation when network does not match our channel table. ④ The asset code includes a suffix or alias, such as USDT.BSC. Case is ignored because we uppercase it. ⑤ Card top-ups or internal transfers are separately disabled for this asset.

The request itself is invalid: malformed JSON, missing or empty required fields, unknown enums, or incorrect amount format/decimal precision

In order of frequency: ① Amount format: fixed-point strings are mandatory, with decimal places equal to the asset’s ledger_scale. "12.5" is invalid for a 6-decimal asset; use "12.500000". JSON numbers also produce this code. ② A required field is missing or empty, such as external_member_id, asset, reference, or payee_id. ③ Incorrect ID shape: after removing its prefix, it must match our identifier format; invented values fail. ④ Invalid JSON body: an empty write body or form-encoded content. ⑤ Unrecognized enum values, such as renewal mode, recipient type, or sandbox upstream/behavior names. ⑥ Both or neither of two mutually exclusive parameters are supplied, such as payout_amount and source_amount in quotes. ⑦ Email already belongs to another merchant’s member. To conceal cross-merchant existence, this also uses the generic code, without saying “already registered”. If member creation repeatedly returns invalid_request despite correct fields, this is a likely cause. ⚠ The response does not identify the field. During integration, check each endpoint’s parameter table rather than guessing.

Unsupported uploaded file type

The KYC file is empty or its magic bytes do not identify JPEG, PNG, WebP, or PDF. The declared Content-Type does not determine acceptance.

KYC file exceeds the per-file size limit

A single KYC file exceeds 8 MB.

Per-field validation failed; the response includes a fields array with key and reason for each item

① Field validation for payee creation, POST /v1/remit/payees: IBAN, routing code, account-holder name, purpose code, or address. Only this endpoint includes a fields array. ② Mistyped withdrawal address: invalid format, EIP-55 checksum, zero address, or chain/asset mismatch. These deliberately do not use address_not_allowed: a typing error should not tell users their address is prohibited or suggest they are blocked. ③ Invalid amount fields, such as amount in exchange / transfers / Earn, are syntax errors like ②. ④ Three card-limit checks: incorrect hierarchy, above the product maximum, or too small to be meaningful. ⑤ Cards: missing or invalid shipping address, mismatched activation details, or incorrect card number/expiry/CVV during binding. ⑥ The chosen payee does not match this order’s corridor. The payee selection is wrong; the corridor itself may work, so this is not corridor_not_supported. ⚠ All cases except ① omit fields; your parser must handle its absence.

We cannot send through this remittance corridor: it is disabled, the jurisdiction is restricted, or this currency/country has no available routing-code type

① We have not enabled the corridor, or its destination jurisdiction is restricted. ② This currency × country has no available routing-code type, such as supplying a local clearing code for an IBAN-only country. ③ No funding channel is currently available for the corridor. ④ For QR payments, the upstream says the corridor is unavailable. Ten different codes would have the same result. This deliberately differs from qr_code_invalid: repeatedly asking the user to rescan is the most common incorrect handling.

The referenced object does not belong to this member or does not exist; both produce the same response

① An object referenced in the body does not belong to the member in x-on-behalf-of. Payees, orders, cards, and Earn positions are queried by member ownership. If the member is wrong, the object appears absent; the incorrect value is the member, not the object. ② The ID belongs to another resource type or has a missing/extra prefix: pye_ payee / rmt_ remittance / crd_ card / ern_ Earn. ③ An internal-transfer recipient belongs to another merchant. The response always says not found, exactly as if nonexistent. ④ The object genuinely does not exist, such as a deleted payee or an order never created. ⚠ Missing objects referenced through path parameters usually return not_found, not this code. Handle both.

The action is invalid in the object’s current state: closed card, terminal order, fixed-term Earn without early redemption, non-redeliverable webhook delivery, and similar cases

① Acting on an object already in a terminal state, such as cancelling a settled remittance, redeeming ended Earn, or redelivering a delivered webhook. Retries and concurrency are common causes. ② Expired quote: exchange quotes last just over a minute; a user lingering on confirmation can exceed that time. This frequently recurs during integration. ③ Remittance reconfirmation: the confirmation window expired, the quote changed again, the order is not awaiting confirmation, or reconfirmation rounds are exhausted. ④ Clients cannot redeem fixed-term Earn early. This is a product rule, not temporary unavailability; do not retry. ⑤ Card state disallows the action: closed, transitioning through freeze/unfreeze, under fund protection, unpaid penalty debt, expired application, or activation before shipment. ⑥ Withdrawal/remittance state claiming failed: not in transit, never dispatched, no locking journal, too recent to act, or already has a settlement journal. ⚠ The response does not expose internal status names. First GET the object, then decide the next step.

An identical record already exists, such as the same withdrawal address added twice by one member

① The same member adds the same withdrawal address twice. A database unique index enforces this, so concurrent “check then insert” implementations can both attempt insertion, with one receiving this code. ② The member already has a card application in progress and starts another. ⚠ Unlike idempotency_key_reused, this is a business duplicate. Changing the idempotency key still fails.

This address cannot be used for withdrawal. Three cases share one response: our own deposit address, blocklisted address, or invalid format/chain

① The address is one of our own deposit addresses, commonly caused by confusing deposit and withdrawal directions or using an address retrieved from our API as a withdrawal destination. ② The address is blocklisted. ⚠ Both produce the same response; distinguishing them would reveal an oracle for discovering our addresses. ⚠ Mistyped addresses—format, checksum, zero address, or chain mismatch—produce invalid_fields, not this code. Asking users to check for a mistyped character after this code is unhelpful; that is not the cause.

This payment QR code cannot be decoded: unrecognized format, unsupported code standard, or upstream rejection

The sole cause is that the QR payload cannot be decoded: unrecognized format, unsupported code standard, or upstream rejection. ① The scanned payment code is of an unsupported type. ② The payload changed in transit: truncation, added newlines/spaces, or an extra URL-decoding pass. ③ A decoder misread characters from a code displayed on a screen. ⚠ If the upstream reports an unavailable corridor, the code is corridor_not_supported, not this one. Rescanning cannot resolve that case.

Path nonexistent, or object nonexistent/not yours. Sandbox-only endpoints also always return this code in live mode

① Misspelled path or missing /v1 prefix; unmatched /v1/* paths map here. ② Object not found through a path parameter: card, card application, remittance, withdrawal, Earn order, payee, or address-book entry. These endpoints use this code rather than resource_not_found. Usually the ID does not belong to the member in x-on-behalf-of or to your merchant. ③ A sandbox-only endpoint was called in live mode. 404, not 403: it should not exist in production, and 403 would acknowledge its existence. ④ Wrong ID prefix: crd_ / rmt_ / wdr_ / ern_, etc.

Quota exceeded. Includes retry_after in seconds and the Retry-After response header

① Exchanging tokens too frequently, over 20 requests/minute. Requesting a token for every API call triggers this yourself. Cache and reuse it until expired_at; this dominates integration-time cases. ② Polling read-only endpoints, over 1200 requests/minute. This generally means treating us like a database to poll; consume webhook events instead. More threads only hit the limit faster. ③ Order operations allow 120 requests/minute, member writes 300/minute, and POST /v1/deposits 60/minute. Bulk member imports and historical deposit backfills can hit the latter two. ④ Exhausted card-binding attempts also return 429. This is a brute-force protection gate; backoff does not resolve it, and a different action is required. ⚠ Quotas apply per merchant, not per key. More keys do not increase capacity.

Internal error on our side

① We omitted an internal error-code registration. Unregistered codes map here, misrepresenting a valid business rejection as an internal error. It is recognizable: the same parameters always produce 500, regardless of retry count. Consistently reproducible 500s on the same endpoint and parameter category are almost always this case; a support ticket helps more than retries. ② An unhandled exception in our business path: unavailable dependency, SQL error, or unexpected upstream response shape. ③ Genuine transient instability, which is less common.

Upstream service provider unavailable

① Our issuing provider is busy or an outbound call temporarily failed, during issuance, activation, or card top-up. This is the one category where retrying unchanged may succeed. ② QR payment upstream 5xx, network failure, or failure to obtain a quote. ③ Remittance payee creation failed upstream. ⚠ This is an upstream issue, not incorrect payee data. We deliberately avoid invalid_fields so you are not directed to edit correct information. ⚠ Upstream identities are never exposed. If the issue persists for several minutes, open a ticket.

Upstream timeout. Outcome unknown; we may already have completed the operation

No current code path emits this code. An actual 504 comes from the gateway in front of us, such as an edge timeout or interrupted connection, rather than a business-path decision. It therefore conveys only one fact: the outcome is unknown. The catalog retains it to avoid documentation and code repeatedly removing each other’s entries, and because its action rule—retry with the same idempotency key—also applies to gateway timeouts. Violating that rule is the most costly mistake described in this documentation.

This line is temporarily unavailable. The cause may be funding, configuration, or upstream availability; deliberately not distinguished

① Your product line is not enabled. A missing line-switch record means unavailable; contact your account manager. Funding does not resolve this. ② Automatic low-funding pause: instant-execution lines, QR payments, exchange, Earn, and withdrawals, immediately return this code and automatically resume on the next cron run after funding. The same condition queues asynchronous remittance and card issuance orders without an error, so the observed behavior differs entirely. ③ Your prepaid balance in the asset is insufficient; instant-execution lines fail immediately as above. ④ Your prepaid account for the asset is restricted, with status other than normal. ⑤ Missing platform configuration or market data: settlement or fee configuration absent, rates temporarily unavailable, or QR provider unconfigured. ⑥ A new deposit address is not ready yet, with retry_after. This means “not ready”, not “failed”. ⚠ For the first four cases, members only see “temporarily unavailable”. Only your side of the integration can explain why a transaction failed despite sufficient member balance.