Reading a self-custodial stablecoin account: Rizon, end to end

Rizon Technologies, UAB issues the app out of Lithuania, its card spend runs through Rain as a Visa principal member, and the wallet is self-custodial — three facts that decide everything about how you reach the data. Custody is the big one. Because the stablecoin balances sit in the user's own on-chain wallet, a meaningful slice of what an integrator wants is already public: USDC and USDT positions are readable straight off the chains Rizon funds from. The rest — card transactions, the multi-currency virtual accounts, cross-border payouts, the invest and futures balances — lives behind Rizon's authenticated backend. So the integration is genuinely two-sided, and the interesting engineering is stitching the two sides into one timeline.

Where Rizon keeps each kind of record

The app spans a wide product surface for something that started as a card. Here is what it actually holds and where each record originates.

Two domains overlap in a way worth flagging early. A single funding event can show up as both an on-chain deposit and an app-side ledger entry, and a card purchase is at once a stablecoin conversion and a Rain processor event. Deduplicating those is part of the build, not an afterthought.

How we reach the data

Three routes apply here. They are not interchangeable — each covers a different part of the table above.

Public-chain reads

Self-custody is a gift to an integrator. The wallet address alone, fed to a node RPC or an indexer per network, returns current and historical USDC/USDT balances and transfer history with no session at all. Durable, cheap, and unaffected by app UI changes. It covers balances and on-chain transfers — nothing more — so it is one leg, not the whole journey. We set up the indexer to cover every network Rizon accepts deposits from so a sync never misses a chain the user funded through.

Authorized app session

Card spend, virtual-account credits, payouts, invest and futures data only exist behind Rizon's login. We map the app's authenticated traffic — the token issue and refresh chain, the request signing, the JSON shapes — and drive it read-only against an account that has consented. Access is arranged with you during onboarding; the build runs against a consenting account or a test profile, never against private keys or the recovery phrase. This is the leg that unlocks the bulk of the product surface.

In-app history export

Where Rizon exposes a transaction-history view or statement, we treat it as a reconciliation fallback — a slower path that backstops the session feed and helps validate it. Useful for one-off pulls and for cross-checking, not for live sync.

For most briefs the honest answer is that you need both of the first two. The chain reads give you trustworthy, key-free balances; the authorized session gives you the card, payout and account detail that no block explorer can see. We would build the chain reader first because it is durable and unblocks balance use cases immediately, then layer the session work for everything Rizon keeps private.

A worked example

Illustrative, with field names confirmed against the live surfaces during the build. The first call needs no credentials; the second runs inside an authorized session.

/ 1. On-chain USDC balance — no session, just the wallet address
GET https://rpc.<network>/  (JSON-RPC, e.g. Base / Solana indexer)
-> token_balance(owner=0xWALLET, mint=USDC) = "1843.20"

/ 2. Card + payout activity — authorized Rizon session
GET /v1/activity?types=card,payout,transfer&cursor=...
Authorization: Bearer <access_token>     # short-lived, refreshed via /v1/auth/refresh

200 OK
{
  "items": [
    { "id": "txn_9f2", "type": "card", "merchant": "Uber",
      "amount": -14.80, "currency": "USD",
      "stable_spent": "14.80 USDC", "fx": 1.0,
      "state": "settled", "ts": "2026-06-18T09:12:04Z" },
    { "id": "pay_4c1", "type": "payout", "dest_country": "MX",
      "dest_currency": "MXN", "amount": -500.00,
      "fx": 17.12, "state": "completed" }
  ],
  "next_cursor": "..."
}

# error handling we wire in: 401 -> refresh once, then re-auth;
# 429 -> respect Retry-After; partial pages -> follow next_cursor to exhaustion

Field names, the exact auth scheme, and pagination are verified against the running app before any code ships. We do not assert an endpoint we have not exercised.

What lands at the end of the build

You receive a working integration, not a report. Concretely, for Rizon:

• An OpenAPI/Swagger spec for a normalized surface — /balances, /accounts, /card/transactions, /payouts, /positions — that folds chain and app data into one model.
• A protocol and auth-flow report: the token issue/refresh chain, request signing, and the per-network RPC/indexer setup, written so your team can maintain it.
• Runnable source in Python or Node.js for both legs — the on-chain reader (multi-network) and the authorized session client.
• Automated tests, including fixtures for the auth-vs-settled card states and the multi-rail credit cases.
• Interface documentation plus data-retention and minimization guidance shaped to GDPR.

Who regulates Rizon, and what we work under

The issuer, Rizon Technologies, UAB, is Lithuanian, which places the app inside the EU MiCA framework under Bank of Lithuania supervision; Circle's USDC is the settlement asset and Rain handles card issuance as a Visa principal member. For an integration, the binding regime over the data itself is GDPR. We operate read-only, on authorized or user-consented access, with consent and access logs kept, data pulled minimized to what the use case needs, and an NDA in place where the work calls for one. The self-custodial design draws a hard line we respect by construction: we read public-chain state and drive a consenting authenticated session, and we never ask for keys or the recovery phrase. Consent is revocable, and we build the session sync to fail cleanly when it is withdrawn rather than retry blindly.

Engineering details we plan around

Two things about Rizon shape the build more than anything else, and a few smaller ones follow.

• Funding can arrive on any of eight chains. We design the on-chain reader to watch all of them and to handle reorgs, so a balance sync does not silently miss a deposit made from, say, Solana when the rest came over Base.
• A card purchase converts stablecoin at the point of sale, so the same event has an authorization moment and a later settlement, sometimes a reversal. We map Rain's processor states onto Rizon's app-side view so the three are never collapsed into one ambiguous row.
• The authorized session runs on short-lived tokens. We build the sync around the refresh cycle so it renews ahead of expiry instead of dropping mid-pull; access is arranged with you during onboarding against a consenting account or test profile.
• Mobile front ends shift. We add a re-validation pass to maintenance so a changed screen or response shape is caught and patched before it breaks your feed.

What we checked

This mapping was put together from Rizon's own product pages, its store listings, and its named infrastructure partners, cross-read against independent card reviews, in June 2026. The custody model, supported deposit networks, and the Rain and Circle relationships are drawn from the sources below.

• Circle Alliance directory — Rizon
• Rain — Rizon stablecoin card launch
• Rizon — virtual USD and EUR accounts
• App Store — issuer and app listing

Mapped by the OpenBanking Studio integration desk · 2026-06-19.

Peer apps in the same integration class

Anyone aggregating Rizon usually wants its neighbours too. These hold comparable data — self-custodial or hybrid stablecoin balances, card spend, and rewards ledgers — and normalize into the same unified model.

• Gnosis Pay — links a Safe smart-contract wallet to a Visa debit card; balances and card spend are both on-chain readable.
• Deblock — pairs a self-custodial wallet with a EU current account, so it mixes on-chain and bank-rail records.
• Cypher — non-custodial card spending stablecoins across several chains, with an app-side transaction ledger.
• Holyheld — USDC card with cashback; holdings sit in a self-custody wallet alongside app reward data.
• Oobit — tap-to-pay stablecoin spending with an account-level activity history.
• Bleap — non-custodial debit card with USDC cashback and yield, blending chain balances and card events.
• COCA — self-custody card pairing USDC vault yield with spend records.
• ether.fi Cash — card spending against on-chain collateral, with a backend spend feed.
• Wirex — multi-asset card and account with a hosted transaction history.

Interface evidence

Store screenshots of the surfaces named above. Select to enlarge.

Questions integrators ask about Rizon

Rizon is self-custodial — can you read balances without the user's keys?

Yes. Wallet balances sit on public chains, so a read-only indexer keyed to the user's wallet address returns USDC and USDT positions across the networks Rizon funds from — Solana, Ethereum, Base, Polygon, BNB Smart Chain, Arbitrum, Avalanche and Optimism. No private keys or recovery phrase are ever requested. The app-side records — card spend, virtual accounts, payouts — come from an authorized session against a consenting account, not from the chain.

How do you tell on-chain transfers apart from the ACH, SEPA and Rizon-to-Rizon flows?

We normalize every movement into one ledger and tag its rail: on-chain deposit, ACH or FedWire credit, SEPA, SWIFT, RTP, a Rizon-to-Rizon send, or a card settlement. Each row carries the source network or scheme, the FX rate Rizon applied, and a settlement status, so an integrator sees a single reconciled timeline instead of six disconnected feeds.

Which regulator sits behind Rizon, and does it change the build?

The app is issued by Rizon Technologies, UAB, a Lithuanian entity, so it falls under the EU MiCA regime with Bank of Lithuania oversight; the Visa card is run through Rain as a principal member, and Circle's USDC is the settlement asset. Personal data is governed by GDPR, which is why we minimize what we pull, keep consent and access logs, and sign an NDA where the engagement needs one.

Can card-transaction and futures positions stay close to real time?

Yes. The on-chain side updates as blocks confirm, and the app-side feed is built on a short polling cycle or a webhook bridge so card authorizations, payouts and open perpetual-futures positions refresh within the freshness window you specify. A working integration of this shape is delivered in one to two weeks.

To start, we need only the app name and what you want out of its data; access and compliance are arranged with you. A one-off source-code delivery of the Rizon integration starts at $300 — you receive the runnable code, the OpenAPI spec, tests and docs, and pay only once it is delivered and you are satisfied. Prefer no build of your own? Call our hosted endpoints instead and pay per call, nothing upfront. Either way the working integration arrives inside one to two weeks. Tell us what you are building at our contact page and we will scope the Rizon route with you.