Pulling a unified ledger out of Cashinout.io's crypto, card and ruble rails

Six asset tickers, four payout currencies and one of Russia's busiest payment rails all post to the same Cashinout.io account history. The app turns held crypto into everyday money: pay a merchant by scanning an SBP QR code, withdraw to rubles, issue a virtual USD card for an overseas subscription, or send funds to another user — and every one of those movements lands in a single statement with its fee and status attached. For a third party that wants to reconcile, sync or report on that activity, the value is exactly that convergence: several rails behind one login.

The practical bottom line: the richest target here is the unified transaction history, because it already joins on-chain crypto, card authorizations, ruble payouts and SBP payments that would otherwise live in four places. We map the authenticated client the app itself uses, then hand back a typed client that reads the same data your users see in-app.

What sits behind a Cashinout.io login

Each surface below corresponds to something the app exposes to a signed-in account. Granularity is described as the data is presented to the user, not promised to a field name we have not yet captured.

Authorized routes to that data

Three routes apply to this app. Access, onboarding and any compliance paperwork are arranged with you as part of the engagement; none of it is something you have to assemble before we begin.

Protocol analysis of the authenticated client

We observe the traffic between the mobile client and the Cashinout.io backend under your authorization, document the token-based auth and the calls behind balances, history, cards, SBP status and transfers, then build a typed client against them. This route reaches the most — the full transaction history included — and it is the one we would lead with. The trade-off is durability: mobile clients ship updates often, so the mapping needs light upkeep when a response shape shifts.

User-consented session access

The account holder authenticates and consents, and we drive that authorized session to read their own data. It is straightforward, it leaves a clean consent trail, and it pairs naturally with the first route — the consent record is what makes the protocol work durable and defensible.

Native export as a baseline

Where the history view supports an export, we use it as a low-effort seed and a cross-check against the live pull. It is a fallback rather than a primary feed, useful mainly for backfilling and for reconciling that the mapped client agrees with what the app itself produces.

Crypto status, SBP and personal data in Russia

There is no Open Banking consent regime in Russia of the kind that exists in the UK or Brazil, so the dependable basis for this work is the account holder's own authorization — the consenting user, logged and minimized. Three frameworks shape how we treat the data. Russia's Federal Law No. 259-FZ on Digital Financial Assets and Digital Currencies, in force since the start of 2021 per the Library of Congress summary, sets the legal status of digital currency and, by default, bars it as a means of payment — useful context for why the app routes value through rubles and cards rather than paying merchants directly in crypto; reporting in early 2026 pointed to penalties tightening around that. The SBP rail is operated by the Bank of Russia with NSPK as its clearing centre, and its dynamic C2B QR codes are one-time with no peer-to-peer chargeback, which is why we treat payment finality as a status to confirm, not assume. Personal data falls under Russia's data-protection law, commonly cited as 152-FZ; we store only the fields an integration needs, keep consent records, and work under an NDA where the data is sensitive.

Engineering details we plan around

These are things we account for so the delivered client behaves, not hurdles for you to clear.

• Multi-rail normalization. One history row might be an on-chain USDT withdrawal, the next an SBP QR payment in rubles funded by crypto, the next a USD card authorization. We map each event type to a common shape with asset, fiat currency, fee and direction, so accounting never reads a card auth as a coin transfer.
• Token refresh and verification gating. The app gates access behind KYC, Liveness and 2FA, with token-based sessions. We design around token refresh and the verification state, so a session that needs re-verification is detected and surfaced rather than failing silently mid-sync.
• SBP QR lifecycle. A dynamic QR has a short default validity and moves through created, paid, settled or expired. We model those transitions explicitly so a pending scan is never booked as money received.
• Client drift. The store listing shows frequent version bumps, so we ship a small contract-test suite that flags when a response field changes — maintenance stays a quick diff, not a re-discovery.

What lands at the end of the build

Everything below is tied to the surfaces above, for this app specifically.

• An OpenAPI / Swagger spec for the mapped calls: auth, balances, transaction history, cards, SBP QR status and transfers.
• A protocol and auth-flow report covering token issuance and refresh, the 2FA / KYC gating, and the header chain.
• Runnable source in Python and Node.js for the core operations — sign in and refresh, list balances, page the transaction history, list cards, poll an SBP QR payment.
• A normalized transaction schema joining crypto, card, ruble and peer-transfer events into one model.
• Contract tests that run the client against captured fixtures, plus interface documentation.
• Data-retention and compliance notes: what to keep, what to drop, how consent and logging are recorded.

A history pull, sketched

Illustrative only — the exact paths and field names are confirmed during the build, not lifted from any vendor document. Auth is a bearer token over HTTPS, and the history call does most of the work.

POST /api/v2/auth/login        { "phone": "...", "otp": "..." }
       -> { "access": "<jwt>", "refresh": "<jwt>" }

GET  /api/v2/wallet/balances   Authorization: Bearer <access>
       -> [ { "asset": "USDT", "available": "182.40", "pending": "0" }, ... ]

GET  /api/v2/transactions?limit=50&cursor=<id>
       -> { "items": [
            { "id":"tx_a1", "kind":"sbp_qr",      "fiat":"RUB", "amount":"-1450.00",
              "asset":"USDT", "spent":"15.97", "status":"settled",    "ts":"..." },
            { "id":"tx_a2", "kind":"card_auth",   "currency":"USD", "amount":"-12.00",
              "card":"** 4417",                   "status":"approved", "ts":"..." },
            { "id":"tx_a3", "kind":"withdraw_rub","fiat":"RUB", "amount":"-30000.00",
              "fee":"90.00",                       "status":"processing","ts":"..." }
          ], "next": "<cursor>" }

# On 401, refresh and retry once. If a response carries a
# re-verification flag, surface it — do not loop the request.
      

One shape across four rails

Downstream code should not care which rail an event came from. We collapse the lot into a single record so a card charge, a coin withdrawal and an SBP payment reconcile against the same fields.

{
  "event_id":      "string",
  "rail":          "sbp_qr | card | crypto | p2p | withdrawal",
  "direction":     "debit | credit",
  "asset":         "BTC | LTC | USDT | BNB | ETH | TRX | null",
  "fiat_currency": "RUB | USD | EUR | KZT | null",
  "amount":        "decimal string",
  "fee":           "decimal string",
  "status":        "pending | settled | failed | expired",
  "counterparty":  "user handle | merchant ref | null",
  "occurred_at":   "ISO-8601"
}
      

Screens we mapped

The public store screenshots informed the surface map above. Select one to enlarge.

Nearby apps in crypto-to-spend

These sit in the same category and come up when teams think about a unified view across crypto and everyday money. Named for context, not ranked — each is a separate product with its own data behind its own login.

• Wirex — crypto-and-fiat wallet with a payment card that converts at the point of spend; holds balances, card transactions and transfer history.
• Mercuryo (Spend) — a virtual card funded from a wallet; the data of interest is card issuance and per-authorization spend.
• PST.NET — virtual USD and EUR cards funded by crypto, with team spend controls and per-card statements.
• Moon Virtual Cards — prepaid cards bought with crypto for online checkout; per-card load and spend records.
• Cardtoshi — instant virtual cards issued against crypto; card metadata and transaction lists.
• Satsrefill — debit cards funded with cryptocurrency for global merchants; load and spend events.
• Privacy.com — generates a fresh card number per merchant; spend events and merchant locks per card.
• Meta Pay — wallet and payment layer across Meta's surfaces; stored instruments and payment history.

How this brief was put together

The surface map comes from the app's own Google Play and App Store listings and the Cashinout.io site, read in June 2026; the SBP and crypto-status detail comes from primary regulatory and reporting sources, all opened directly:

• Cashinout.io on Google Play — features, assets, verification and version detail.
• ForkLog — on the crypto-funded SBP QR payment launch.
• Bank of Russia — Faster Payments System (SBP) — operator and clearing structure.
• Library of Congress — on Law 259-FZ and digital-currency status.

Mapping compiled by the OpenBanking Studio integration desk, 11 June 2026.

Questions integrators ask about Cashinout.io

Can crypto balances and ruble cash-outs land in one reconciled ledger?

Yes. The six assets the app shows — BTC, LTC, USDT, BNB, ETH and TRX per its store listing — and the ruble payouts both surface in the transaction history, so we normalize them into a single event stream that carries asset, fiat amount, fee and status on every row.

How do the virtual USD card records come through?

Card data sits in the cards area: masked card number, status and limits, plus a spend event per authorization. We map those as their own rail, so a USD card charge is never conflated with a crypto withdrawal or an SBP payment.

Is the SBP QR side reliable enough to treat a payment as final?

We read finality from status, not from assumption. SBP dynamic QR codes are one-time with a short default validity, and the rail carries no peer-to-peer chargeback, so we model the created-to-settled-or-expired transitions and book a payment only once its status confirms it.

Our company account is already KYC-verified — is that enough to map the surfaces?

That works well. The starting point is the app name and what you want from its data; access and compliance are arranged with you, and the build runs against a consenting, verified account so the mapped flows match what your users actually see.

Commissioning the integration

Delivery on a Cashinout.io mapping runs on a one-to-two-week cycle. Source-code delivery starts at $300, paid only after the runnable client and documentation are in your hands and you are satisfied; if you would rather not commission a build at all, the same flows are available as hosted endpoints you pay for per call, with no upfront fee. Tell us what you want out of Cashinout.io at our contact page and we will scope it.