Reaching Trastpay's card, deposit and microloan records

Trastpay carries two card rails on a single screen — Uzcard and HUMO — and shows their balances and transaction history in both soum and foreign currency. That mixed-rail account view, plus card-to-card transfers, deposits, microloans up to 50 million soum, and utility payments with cashback, is the data a third party would want to query or sync. The app is published by Trustbank PJSB (Private joint-stock bank) in Uzbekistan, per its Play Store listing under the package trastpay.uz and on the App Store under id 6443658536. This page lays out what its login exposes, the authorized way to reach it, and the source code we hand back.

The bottom line: there is no formal mandated account-information scheme to plug into here the way Open Banking exists in the UK, so the dependable basis for reaching Trastpay data is the account holder's own authorization, exercised through the app's real session. The route we would actually take is authorized protocol analysis of that authenticated session, captured with a consenting account, then rebuilt as documented endpoints. The rest of this brief explains why that route, and what comes out of it.

Behind the login

Each row below is a surface Trastpay describes in its own listing. Granularity is what an integrator can reasonably expect to read once authenticated, confirmed against the app's stated feature set.

Routes in

Three routes genuinely apply to Trastpay. We name the one we recommend at the end of the section.

Authorized protocol analysis of the app session

We observe the traffic between the Trastpay client and Trustbank's backend using a consenting account, document the auth handshake and the calls that return card, deposit and loan data, and rebuild them as clean endpoints. Reachable: every surface in the table above. Effort: moderate, front-loaded on the session and token work. Durability: good between client releases, with a re-check when the app updates. We set up the capture environment and the consenting test account with you during onboarding.

User-consented credential access

The account holder authorizes access through their own credentials and the app's biometric and OTP login, and the integration acts within that authorized session. Reachable: the same per-user data, scoped to one consenting user at a time. Effort: low once the session model from the route above is in place. Durability: tied to the consent and token lifetime, which we design around.

Native export as a fallback

Where Trastpay or the trastbank.uz portal lets a user save invoices or statements, we ingest those as a backfill or a low-frequency reconciliation feed. It will not match a live pull for freshness, but it is useful for history and as a cross-check.

For Trastpay, protocol analysis under the account holder's authorization is the route we would build on — it is the only one that returns the full mixed-rail picture at the freshness most teams need, and the consented-credential model rides on the same session work, so the two are really one build. Native export sits underneath as history and verification.

A statement pull, sketched

Illustrative, not copied from production traffic — the exact field names are confirmed during the build against the live session. It shows the shape we document: a session token obtained through the app's authenticated login, then a linked-card transaction query tagged by rail.

POST /v1/session/refresh        # within an authorized, biometric+OTP login
Authorization: Bearer <session_token>
{ "device_id": "...", "consent_ref": "uc-2026-..." }

GET /v1/cards/{cardId}/transactions?from=2026-05-01&to=2026-05-31&ccy=UZS
Authorization: Bearer <session_token>

# normalized response we emit
{
  "card_id": "humo:****4821",
  "rail": "HUMO",                  # or "UZCARD" — tagged at ingest
  "currency": "UZS",
  "transactions": [
    { "ts": "2026-05-14T09:21:00+05:00", "amount": -45000,
      "type": "card_transfer", "counter_rail": "UZCARD",
      "commission": 180, "desc": "card-to-card" }
  ],
  "next_cursor": "..."             # paginate until empty
}

# handle: token expiry -> re-auth in session; 429 -> backoff;
# FX cards -> repeat per ccy; reconcile commission against the per-rail rule

What lands at the end of the build

Everything below is tied to Trastpay's real surfaces, not a generic kit.

• An OpenAPI/Swagger specification covering the card-statement, transfer, deposit, microloan and payment endpoints we documented.
• A protocol and auth-flow report: the token and session chain as it works within Trastpay's biometric and OTP login, including refresh and expiry behaviour.
• Runnable source for the key endpoints in Python or Node.js — the statement pull, transfer history and deposit reads, with rail tagging built in.
• Automated tests against the documented responses, including the per-rail commission reconciliation case.
• Interface documentation a developer can hand to their own team, plus data-retention and consent-handling guidance fitted to Uzbek bank-secrecy and personal-data rules.

Where Uzbek banking rules bite

Trustbank is supervised by the Central Bank of the Republic of Uzbekistan, which licenses banking activity and runs the country's open data portal. Two laws shape how we handle Trastpay data. The Law on Personal Data (No. ZRU-547, 2 July 2019) sets consent, security and localization obligations, and keeps biometric and citizens' data on servers inside Uzbekistan; the Bank Secrecy Law (30 August 2003) bars banks from disclosing customer banking information. We treat the account holder's explicit, recorded consent as the basis for access, scope it to the data the integration needs, log every pull, and minimize what we store. From April 2026, Uzbek digital-banking rules require OTP plus liveness-checked facial recognition at login — which is exactly why our design runs inside a real authenticated session rather than around it. NDAs are in place where the engagement calls for them.

What we plan around for this build

Two things specific to Trastpay shape the work, and we handle both as part of the build.

• Two rails, two fee regimes. HUMO clears through the National Interbank Processing Centre and Uzcard through its own processor, and Trastpay lists different commissions per pairing — 0% HUMO-to-HUMO, 0.25% across HUMO/Uzcard, up to 0.4% Uzcard-to-Uzcard. We tag every card and movement with its rail at ingest and reconcile fees against the right rule, so transfers and balances stay correct across the mixed view.
• Consent and session lifetime. Because login leans on biometric and OTP verification with liveness checks, sessions are short and tied to a present user. We design the sync cadence around the token-refresh and consent window so it renews inside the authorized session and does not quietly expire mid-pull, and we wire a re-check into maintenance for when the app's front end shifts between releases.
• FX and soum side by side. Cards and deposits exist in soum and foreign currency, and conversion history carries its own rate and pair. We keep currency explicit on every record rather than collapsing it, so FX cost analysis and reconciliation hold up.

Access — a consenting account, the capture environment, any sandbox — is arranged with you during onboarding. None of it is something you need to clear before we start.

Where teams point a Trastpay integration

• A bookkeeping or PFM tool syncing a user's Uzcard and HUMO statements into one categorized ledger.
• A lender or marketplace reading microloan and installment status (Lendo, inTend) to time follow-on offers.
• A treasury view across soum and FX deposits for a business that banks with Trustbank.
• A payments dashboard reconciling card-to-card transfer fees against the correct per-rail commission.

Screens we mapped

The store screenshots we reviewed while scoping the surfaces above. Tap to enlarge.

The Uzbek payments apps in the same orbit

A unified integration usually spans several of these, since users hold cards and wallets across more than one. Names are listed for context, not ranked.

• Click — one of Uzbekistan's two largest payment apps, holding wallet balances, transfers and bill-payment history.
• Payme — the other leading payment platform, with P2P transfers, card links and merchant payments.
• Uzum Bank — a digital bank and marketplace wallet with accounts, BNPL and payment records.
• Paynet — a long-standing payments company, now also operator of the HUMO processing centre, with bill and transfer data.
• Oson — an electronic-money wallet operated by Brio Group, holding balances and payment history.
• Beepul — Beeline Uzbekistan's payment app, with wallet and utility-payment records.
• Apelsin — Kapital Bank's mobile app, carrying card accounts, transfers and payments.
• Anorbank — a digital-first Uzbek bank with card, deposit and transfer data behind its app.

Questions integrators ask us about Trastpay

Which records can a Trastpay integration actually reach?

The per-user surfaces the app shows after login: linked Uzcard and HUMO card balances and transaction history in soum and foreign currency, card-to-card transfer records with their per-rail commissions, deposit accounts and movements, microloan and installment (Lendo, inTend) status, currency-conversion history, utility and budget payments, and saved templates. We map each to a normalized record and pull on a consented schedule.

Trastpay mixes HUMO and Uzcard cards on one screen. How does that affect the build?

The two rails clear through different processors (the National Interbank Processing Centre for HUMO, Uzcard for Uzcard), and the app shows different commission rules per pairing. We tag every card and transaction with its rail at ingest so transfers, fees and reconciliation stay correct across both, rather than flattening them into one undated stream.

Does Uzbekistan's April 2026 biometric login rule change the integration?

It does, and we account for it. Digital-banking access now leans on OTP plus liveness-checked facial recognition during authentication, so a silent headless login is not the design. We build the session and consent flow around a real authenticated user and refresh tokens within that authorized session, keeping consent records alongside.

What we checked

Scoping for this write-up drew on the Trastpay store listings, Trustbank's own site, and primary material on Uzbekistan's payment systems and data law, reviewed in June 2026. Sources we opened:

• Trastpay on Google Play — feature set, package ID, rails.
• Trustbank PJSB — Trastpay service page.
• HUMO / National Interbank Processing Centre — rail operator and scale.
• Personal-data compliance in Uzbekistan — Law ZRU-547 and localization.

OpenBanking Studio integration desk · mapping reviewed 2026-06-06.

One way to engage is source-code delivery: we build and hand over the runnable Trastpay endpoints, the OpenAPI spec, tests and interface docs, and you pay from $300 only after delivery, once the result satisfies you. The other is our pay-per-call hosted API — you call our endpoints and pay per call, with nothing upfront. Either way the cycle runs one to two weeks. Tell us the app name and what you want from its data, and we handle the access and compliance with you — start at /contact.html.