cards:issue, cards:read, cards:topup, cards:freeze (or cards:*).
Cards are issued for your end customers. You pass KYC in cardholder. One create = one card. Correlate with your ext_id, then card_id.
List responses expose only metadata and number_masked. PAN / CVV / card_encrypted are available only on GET /partner/cards/{card_id}.
Catalog
/availability or /quote. Unknown / foreign card_product → 409 / product_unavailable (no leak of other tenants’ catalogs).
quantity (1..20) on POST /partner/cards issues multiple cards with ext_id, ext_id#2, … Response 202 includes items[]. Mixed cart: POST /partner/batch.
Issue a card
Flat aliases
address_line1 / city / region / postal_code on cardholder are accepted and normalized into nested address.*. Prefer nested address.
ban_rus products (non-RU risk): phone must not be +7…, country ≠ RU, and names must be Latin. Russian phone/country are rejected for those products.
Response 202
Issue statuses
Other intermediate status strings may appear while the order is open — treat anything other than
card_issued / failed as in progress. Prefer webhook card_issue.status_changed and document polling.
Synchronous create failures return a JSON error body (error + message) — not an empty HTTP 500. Examples include invalid_customer_data, kyc_rejected, insufficient_balance, product_unavailable, cardholder_create_failed.
Stuck issue → failed / issue_timeout
If a card_issue document stays in processing with no card / charge progress for too long (default about 15 minutes), IMBA closes it as failed with error=issue_timeout (HTTP 504 recorded in the document response). You receive webhook card_issue.status_changed and a terminal GET /partner/documents/{ext_id}. Funds were not charged.
- Retry with a new
ext_id. Replaying the sameext_idreturns the storedfaileddocument. - Documents are not deleted on timeout.
- A late provider callback after
faileddoes not issue a second card.
email+phone with matching KYC under your tenant, IMBA may reuse that cardholder (anti-fraud). A different person with the same email+phone gets a new cardholder.
List cards
cards:read. Keyset pagination by opaque cursor — no offset, no total / count.
- Stable order: ascending internal link id. Next page:
id > cursor. - Issuing stub (link exists, card not ready):
issue_status=card_issuing;card_id/status/number_masked/currencymay benull. - No PAN / CVV /
card_encryptedon the list — use Get card below. next_cursor: null— last page.
Get card (secrets)
card_encrypted). See Card encryption.
issuing, active, frozen, closed, failed.There is no separate activation step after issue.
Do not log PAN/CVV/JWE plaintext.
card_id is IMBA’s hex id. It is not a payment-network token. PAN, expiry (expiration, typically MM/YYYY), and CVV are inside card_encrypted / card after you decrypt — see Card encryption.
Only cards linked to your tenant are returned (404 otherwise). Webhooks carry status and ids — fetch secrets via this GET, not from webhooks or the list endpoint.
3-D Secure codes
cardholder.email is a working address: the 3-D Secure code for a payment is mailed there. The same code is also delivered to you as webhook card.otp in the otp field, so your support can read it out to the buyer. There is no pull endpoint for the code, and it lives about 2 minutes — handle the webhook immediately.
Card balance
Top up
Debit is in USDT from your settlement balance (amount + fee).
card_topup.status_changed or document poll. Card must be active.
Freeze
202. Result via webhook card_freeze.status_changed / documents.Unfreeze is not available in v1 of Partner API (contact support / ops).
Not in v1 (cards)
Automated delivery of PAN/CVV after
card_issued: yes, via this GET (not webhook). You show credentials in your UI. See FAQ.