Overview

Users and cards have been migrated automatically. Re-registration and card re-issuance are not required.

  • Users with cards: external_user_id remains the same (token from external_key)
  • Users without cards: migrated with external_user_id = UUID from the old database
  • Cards with undetermined status (not active/frozen/closed) are skipped and require manual review

What stayed the same

Description
User IDToken from external_key (e.g. LIAjeeoSKRR2LSULK90XiSs) → now field external_user_id, same value
Card numberLast 4 digits (label) — unchanged
CardsMigrated with preserved statuses (active, frozen, closed). Cards with undetermined status were skipped

What changed

Authentication

BeforeAfter
partner_id + secret in request bodyAPI-KEY header + payload encryption via SAYFER_WEB
No encryption (plain JSON)All requests and responses are encrypted
No timestamprequest_timestamp required (microseconds, ±30 sec window)
You will receive: API_KEY, API_SECRET, and the sayfer_web library.

Card IDs

BeforeAfter
UUID (a22aa137-51fd-5f4c-...)ObjectId (69bd4ab7ead3bd5ffc0d18cd)
After migration, retrieve new card_id values via cards/find. Match by external_user_id + label (last 4 digits).

Card status

BeforeAfter
is_active: true / is_frozen: true / is_closed: truestatus: "active" / "frozen" / "closed"
Single string field instead of three booleans.

Balance

BeforeAfter
Included in card responseSeparate endpoint POST /api/v2/cards/balance

Idempotency

Card creation and topup now require an Idempotency-Key header (prevents duplicate operations on retries, key valid for 7 days).

Card products

Card types have been migrated under new codes (product_code). Full list with pricing and limits: POST /api/v2/cards/products.

Endpoint mapping

ActionOld APINew API
Get userPOST /api/v2/users/get
List usersPOST /api/v2/users/find
Create userPOST /api/v2/users/create
List cardsGET /api/v1/cards/listPOST /api/v2/cards/find
Card detailsGET /api/v1/cards/{id}POST /api/v2/cards/get
Card balance(in card response)POST /api/v2/cards/balance
Card data (PAN, CVV)POST /api/v2/cards/details
TopupPOST /api/v1/cards/topupPOST /api/v2/cards/topup
FreezePOST /api/v1/cards/freezePOST /api/v2/cards/freeze
UnfreezePOST /api/v1/cards/unfreezePOST /api/v2/cards/unfreeze
TransactionsPOST /api/v2/cards/txs
Issue cardPOST /api/v1/cards/createPOST /api/v2/cards/create
ProductsPOST /api/v2/cards/products

What is NOT migrated

DataReason
Transaction historyRemains in the old database; new system writes transactions from scratch
BalancesFetched live from the provider
TRON deposit addressesOld addresses are not transferred. Deposit address is tied to the project, not the user