Reading a Cryptomus account from your own backend

Cryptomus runs under a Canada-incorporated operator, Xeltox Enterprises Ltd (per FINTRAC's enforcement notice), and holds every balance, spot fill, P2P deal and virtual-card authorization behind a logged-in mobile account — package com.cryptomus.bundle, per its Play listing. The data sits behind a login. The job here is to stand up a typed client — Python or Node.js first — that reads those surfaces with the account holder's authorization and lands them in your own systems on a schedule you set.

The spine is consented interface integration: we work against a consenting account, pin the request-signing scheme the app's traffic uses, and normalize what comes back. Where you run a Cryptomus merchant account, signed payment and payout callbacks ride alongside as the live event feed. What follows is the data, the routes, the client we ship, and the things this build has to get right.

What the account actually holds

The mobile app is an all-in-one crypto account: a multi-coin wallet, a spot order book, a P2P desk, and a virtual card you fund from your balance. Each of those is a distinct record set behind the same login, and each maps to a different table once it is out.

The wallet is the centre of gravity. Balances and on-chain movements are the highest-value feed because they span more than a dozen assets across several networks; the card and P2P ledgers sit on top and reference back to it whenever a top-up or a settlement moves funds.

Reaching it with the holder's say-so

Two or three routes genuinely fit this app, depending on whether you hold a consumer account, a merchant account, or both.

Consented interface integration (the spine)

We work against a consenting account and pin the app's request-signing scheme, then read the wallet, spot, P2P and card surfaces the holder can see. Reach is broad — anything in the account. Effort is medium, and durability depends on the app: when a surface shifts, we re-pin and the contract tests flag the change before it reaches your ledger. Access is arranged with you during onboarding, against a consenting account; nothing about that is on you to clear first.

Signed callback ingestion

If you run a Cryptomus merchant account, payment and payout events arrive as signed callbacks — each carries an md5(base64(payload)+key) signature you verify before trusting it. This is the cheapest path to a live event feed and the most durable, because it is event-driven rather than scraped. It pairs naturally with the SDK-first build.

Native export as backfill

Where the app exposes a transaction history download, we use it for the one-time backfill behind a live feed — it fills the history a fresh consent window cannot reach, then the client takes over for everything current.

For most builds the consented interface route carries the account and the signed callbacks layer on for live payment and payout events; native export is reserved for backfilling history. We will tell you which combination fits once we see what you need out of the account.

What lands in your repository

The deliverable is code that runs, not a binder. In order of what you get first:

• A signed-request client in Python and Node.js (Go on request) that wraps the md5(base64(payload)+key) signing, handles paging and retries, and exposes typed reads for balances, orders, P2P deals, transfers and card events.
• A webhook receiver that verifies each callback signature, dedupes on the payment uuid, and writes idempotently into your ledger.
• A normalization layer that maps Cryptomus coins, networks, order and card events onto one schema so a TRC20 USDT line and an ERC20 USDT line stay distinct but queryable together.
• An automated test suite seeded with per-network fixtures and recorded callbacks, so a change in the upstream shape is caught against the contract rather than in production.
• An OpenAPI / Swagger description of the surfaces the client touches, plus an auth-flow note covering the token, header and signing chain as it actually behaves here.
• Interface documentation and a short data-retention and minimization note for the personal and KYC fields the integration can reach.

The signed-request client, up close

The auth is a single signing rule applied to every request and every inbound callback: an MD5 of the base64-encoded JSON body concatenated with the account's API key. The client below is a trimmed version of what we hand over — field shapes are pinned against a consenting account during the build, so treat the body keys as illustrative.

# cryptomus_client.py — one of the runnable clients we deliver (Python; Node + Go ship alongside)
# Auth: sign = md5( base64(json_body) + api_key ), confirmed during the build.
import base64, hashlib, hmac, json, requests

class CryptomusClient:
    BASE = "https://api.cryptomus.com/v1"

    def __init__(self, account_uuid: str, api_key: str):
        self.account = account_uuid       # supplied by you; identifies the consenting account
        self._key = api_key               # held in your secret store, never logged

    def _sign(self, raw_body: str) -> str:
        encoded = base64.b64encode(raw_body.encode()).decode()
        return hashlib.md5((encoded + self._key).encode()).hexdigest()

    def _post(self, path: str, payload: dict) -> dict:
        raw = json.dumps(payload, separators=(",", ":"))
        headers = {
            "merchant": self.account,
            "sign": self._sign(raw),
            "Content-Type": "application/json",
        }
        r = requests.post(self.BASE + path, data=raw, headers=headers, timeout=20)
        r.raise_for_status()
        return r.json()["result"]

    # normalized read: balances keyed on (asset, network), not ticker alone
    def balances(self) -> list:
        result = self._post("/balance", {})
        return [
            {"asset": b["currency"], "network": b["network"], "amount": b["balance"]}
            for b in result               # field names illustrative; exact shape pinned in build
        ]

    # inbound callback: strip the sign field, re-hash the rest, compare before trusting it
    def verify_callback(self, body: bytes) -> bool:
        data = json.loads(body)
        sent = data.pop("sign", "")
        local = self._sign(json.dumps(data, separators=(",", ":")))
        return hmac.compare_digest(sent, local)

Two details earn their place. The callback verifier removes the sign field before re-hashing, because the signature is computed over the payload without itself; and the balance read returns (asset, network) tuples rather than bare tickers, which is what keeps the three USDT chains from collapsing into one figure.

Three builds this maps onto

The same client underpins very different jobs:

• Treasury sync. Read balances across every asset and network on a short cursor, push them into a finance dashboard, and alert when a network's holdings cross a threshold.
• Trade and PnL export. Pull spot fills with side, price and fee, normalize into your accounting model, and reconcile against deposits and withdrawals.
• Merchant settlement. Verify signed payment callbacks, write them once into a ledger keyed on the payment uuid, and drive payout reconciliation off the same events.

Authorization, AML context and personal data

The dependable basis for this integration is the account holder's own authorization — consented access to an account you or your customer control. There is no open-finance or account-aggregation mandate that reaches a crypto wallet here, so the route does not lean on a regulator-run data feed; it leans on consent, and the page is honest about that.

The regulatory context that does apply sits on the operator, not on data portability. Cryptomus's operator, Xeltox Enterprises Ltd, is a FINTRAC-registered money services business under Canada's Proceeds of Crime (Money Laundering) and Terrorist Financing Act, and in October 2025 FINTRAC imposed an administrative penalty of roughly CAD 177 million for AML reporting failures (per The Tyee's reporting); TRM Labs has separately flagged liquidity ties to the now-sanctioned Garantex exchange. None of that blocks reading an account you are authorized to read, but it sets how we operate: authorized and logged access only, personal and KYC data minimized to the fields the integration needs, consent records kept, and an NDA where the engagement calls for one. We do not touch anything outside the account holder's grant.

What this build has to get right

A few things about Cryptomus specifically shape the work, and we handle each as part of the build rather than handing it back as a checklist:

• Same ticker, different chains. USDT lives on TRC20, ERC20 and BEP20, each with its own address space and fees. We key balances and transfers on the (asset, network) pair, so a TRC20 deposit is never reconciled against an ERC20 balance and fees stay attached to the right rail.
• The card is its own ledger. Virtual-card spend is denominated in USD or EUR and funded by converting crypto at top-up, so card authorizations and fees are a separate account from the on-chain wallet. We model the card distinctly and tie each top-up back to the funding asset, so FX and card fees do not smear across the crypto balance.
• Callbacks repeat. Signed payment callbacks can be resent. We dedupe on the payment uuid, so a callback Cryptomus retries is recorded in your ledger exactly once.
• Visibility differs by account. Card issuance needs KYC and some surfaces are region-gated, so what a consenting account can see varies. We scope the integration to the surfaces that account actually exposes, and arrange the access with you during onboarding.

Inside the app

Store screenshots of the surfaces the integration reads — wallet, trading, P2P and cards. Select one to enlarge.

Other wallet-and-trading apps teams ask about

Cryptomus rarely sits alone in an integration. When a team aggregates several crypto accounts, these come up in the same breath — each holds a comparable mix of balances, trades and movement records, and a single normalized model usually has to cover more than one.

• Binance — large centralized exchange; spot and derivatives orders, balances and deposit/withdrawal history behind an account.
• Coinbase — Nasdaq-listed exchange and wallet; portfolio holdings, trade history and fiat on/off-ramp records.
• Trust Wallet — non-custodial mobile wallet; on-chain balances and transaction history across many chains rather than server-held order books.
• OKX — exchange plus self-custody wallet; trading positions, balances and multi-network token activity.
• Bybit — derivatives-focused exchange; perpetual and margin positions, funding records and balances.
• Gate.io — broad-asset exchange; spot orders, balances and a long list of supported tokens.
• Exodus — multi-asset wallet with in-app exchange; balances, swap history and per-asset movement.
• Zengo Wallet — MPC-secured mobile wallet; balances and transfer history without a traditional seed phrase.

Questions integrators ask

Do the signed payment callbacks stay in step with the wallet balance, or do I have to poll as well?

Both, and they cover different gaps. The callbacks fire on payment and payout events and carry their own md5(base64(payload)+key) signature, so they are the live path; the client also reads balances on a cursor as a backstop, so a missed or delayed callback still gets picked up on the next sync. We dedupe callbacks on the payment uuid, so one that Cryptomus resends lands in your ledger a single time.

Which coins come through, and does USDT separate by network?

Per its Play listing the wallet spans BTC, ETH, USDT, USDC, SOL, TRX, BNB, DOGE, LTC, XMR and a long tail of others. USDT in particular shows up on TRC20, ERC20 and BEP20, and we key every balance and transfer on the (asset, network) pair, so a TRC20 deposit is never reconciled against an ERC20 line. The full coin set is whatever the consenting account can see at build time.

Cryptomus's operator took a large FINTRAC penalty — does that stop an integration?

No, but it sets the posture. FINTRAC penalized the operator, Xeltox Enterprises Ltd, roughly CAD 177 million in October 2025 over AML reporting failures, and TRM Labs has flagged liquidity ties to the sanctioned Garantex exchange. We work only from the account holder's own authorization, log what we touch, minimize the personal and KYC data we pull, and keep nothing outside the grant. We do not interact with anything the consenting account cannot lawfully see.

Do I get a working client, or just a specification?

A working client. The core deliverable is runnable source — a Python and Node.js client that signs requests and verifies callbacks, with a Go build on request — plus a normalization layer, a webhook receiver and an automated test suite seeded with per-network fixtures. The OpenAPI write-up and auth-flow notes come with it, but the code that runs is the point.

What this is based on

Checked on 2026-06-08 against the app's Play listing, Cryptomus's own card pages, and two regulatory and risk sources covering the operator. Where a figure comes from a third party it is attributed inline above; identifiers and body field names in the client are confirmed during the build, not asserted from a listing.

• Google Play — Cryptomus: Wallet & Trading listing
• Cryptomus — virtual crypto card details
• TRM Labs — Cryptomus risk profile
• The Tyee — FINTRAC penalty against the Cryptomus operator

Written up by the OpenFinance Lab protocol team after a hands-on pass on 2026-06-08.

A first client drop, the normalization layer and tests come back inside one to two weeks. Source-code delivery starts at $300 and you pay once it is in your hands and working the way you asked; if you would rather not host anything, the same surfaces are available as a pay-per-call hosted API with no upfront fee. Tell us the app and what you want out of the account at our contact page and we will scope the route from there.

Verified 2026-06-08