Pulling wallet, card and payment history out of Click SuperApp

Click reports more than 20 million users in Uzbekistan, and almost every one of them sits on the same small set of server-side records: a Click Wallet balance, one or more linked UzCard and Humo cards, and a running ledger of transfers, payments and loan repayments. That ledger is the thing an integrator wants. The workable way to reach it is to treat an authenticated Click session as an event source — read the per-account history, normalize each operation, and push it onto a queue your own systems can replay later — all under the account holder's own authorization. What follows maps what is inside, the route we would take, and what lands in your repository at the end.

Bottom line: Click is a payments hub, not a single account. The richest target is the operation history that flows across both card systems and the wallet, and the cleanest way to consume it is as a normalized stream you control. We build that stream against a consenting account and hand you the code, the schema, and the tests that prove it reads correctly.

The data Click keeps per user

Every row below maps to a feature Click names in its own product copy. Granularity is what an account holder can already see in the app, which is the practical ceiling for a consented integration.

Routes into Click's data

Three routes genuinely apply here. We would lead with the first and keep the others in reserve for where they fit.

User-consented session integration (protocol analysis)

Reachable: the full set above, exactly what the account holder sees. Click identifies users by phone number with a device-bound session, so we reconstruct the enrolment and token-refresh flow and read history page by page. Effort is moderate and concentrated up front. Durability is good as long as we re-validate when the app ships a major client update. Access is arranged with you during onboarding — a consenting account or a sponsor test profile — and the capture work happens on our side.

Open-data / consent rails as the Uzbek framework matures

Uzbekistan does not yet run a UK-style mandated open-banking scheme, but the Central Bank has been formalizing shared payment infrastructure, including the unified QR rules registered in 2026. Where a bank-side consent channel exists for a given card issuer, we use it. This route is the most durable when available and the narrowest in scope.

Native in-app reports as a fallback

Click's own Reports feature renders payment history and graphical summaries. Where a one-off pull is enough, the export path is the lightest touch and needs the least maintenance, at the cost of cadence and field depth.

For most teams the first route is the one we would actually build, because it returns the live operation history rather than a static summary, and it carries forward as the wallet and card data change.

How a Click integration is wired

The shape below is illustrative; exact field names are pinned during the build, not guessed here. Authentication centers on the phone number and a device binding, after which card and wallet history arrive as paged operations that we fan out onto an ingest queue.

# Illustrative — field names confirmed during the build.
session = click.authorize(
    msisdn   = "+99890XXXXXXX",   # Click keys users by phone number
    device_id= DEVICE_TOKEN,      # bound at enrolment, re-used on refresh
    otp      = sms_code,
)

# Card history (UzCard + Humo) reads as a forward-paged ledger.
cursor = store.last_cursor(account)
for page in click.card_history(card=card_token, after=cursor):
    for op in page.operations:        # credit, POS, cash-out, P2P, bill
        queue.put(normalize(op))      # event_id = dedupe key on replay
    store.save_cursor(account, page.next)

# Wallet side: e-money balance + top-ups / transfers (UZS only)
wallet = click.wallet_state(account=account)
queue.put(normalize_balance(wallet))

Each operation is flattened into one canonical event before it leaves the worker, so a downstream consumer never has to know which rail it came from:

{
  "source": "click",
  "event_id": "native-operation-id",        // stable; used to collapse replays
  "account_ref": "opaque wallet or card token",
  "type": "transfer | payment | topup | cashback | loan_repayment",
  "rail": "uzcard | humo | wallet",
  "amount": { "value": 125000, "currency": "UZS" },
  "counterparty": { "kind": "card | phone | wallet | merchant", "ref": "…" },
  "ts": "2026-06-08T09:14:00+05:00"
}

What you get back

The headline deliverable is code that runs, not a document set:

• Runnable client libraries in Python and Node.js for session auth, card-history paging, and wallet state.
• A queue-fed ingest worker that maps every Click operation to the canonical event above and keeps a replayable log, so a new consumer can rebuild history from the start.
• An automated test harness that runs the client against a consenting account or captured fixtures and asserts the shape of what comes back.
• A poller/webhook handler that picks up new operations from a saved cursor.

Alongside the code you also receive an OpenAPI description of the reconstructed surface, a short protocol and auth-flow write-up covering the token and device-binding chain, interface documentation, and data-retention guidance for the records you hold. Those round out the package; the working integration is the point.

What the Click build has to account for

Two parts of Click shape the engineering, and we plan for both before writing the client.

First, the two-rail split. Click links UzCard and Humo cards, and each processing center describes an operation with its own identifiers and field quirks. We normalize both into a single card-history model with an explicit rail tag, so your downstream code reads one shape and never branches per processor.

Second, the wallet-versus-card distinction. The Click Wallet is e-money, which under Uzbek rules is issued only in soums and settles separately from the bank cards behind it. We keep wallet events and card-rail events in separate streams and reconcile their balances independently, because mixing them would misstate both. We also leave room in the schema for the unified-QR payment events that become mandatory market-wide in mid-2026, so newly appearing operation types do not fall on the floor.

Where teams plug Click in

• A personal-finance app that wants a unified Uzbek spending feed pulls the normalized card and wallet stream and categorizes it.
• A lender repaying through Click reconciles its own loan ledger against the in-app loan-repayment events to confirm settlement.
• An accounting tool ingests a small business owner's service-payment and transfer history for bookkeeping.
• A loyalty product reads cashback accruals and Premium state to mirror rewards outside the app.

Where this sits with Uzbek payment rules

Click operates under the Central Bank of the Republic of Uzbekistan. The governing instruments are the 2019 Law on payments and payment systems and the Central Bank's e-money rules adopted in 2020, under which electronic money is issued only in national currency and only by licensed banks — the basis for treating the Click Wallet as a distinct, soum-denominated balance (per Uzbek legal commentary we reviewed). There is no mandated consumer-data-sharing scheme of the UK or Brazilian kind in force here, so the dependable basis for an integration is the account holder's own consent. We work against authorized or user-consented access, keep an access log and consent record, minimize the fields retained, and sign an NDA where the engagement needs one. The unified QR-code framework the Central Bank approved in 2026 is the nearest thing to shared infrastructure, and we track how it reshapes the operation stream.

Working with us on this

A Click engagement ends with runnable client code and a documented event schema in your hands. Source-code delivery starts at $300: you receive the integration and its documentation, and you pay after delivery, once it works for you. If you would rather not run anything yourself, call our hosted endpoints and pay per call, with no upfront fee. Either way the cycle is one to two weeks from the point we have the app name and a sense of which data you need. Tell us those two things and we arrange access and compliance from there. Start a Click integration

Screens we mapped against

Other Uzbek payment apps in the same orbit

A real integration rarely stops at one app. These neighbours hold comparable per-user records and often turn up in the same unified-feed request:

• Payme — mobile payments and P2P transfers, with linked-card and transaction records per user.
• Uzum Bank — banking plus marketplace ecosystem holding accounts, cards and order history.
• Alif — wallet, installment and transfer activity across its Alif Mobi product.
• Xazna — a payments super app with cashback and bill-payment history.
• Oson — payment service with wallet balances and service-payment records.
• Paynet — long-running payment network with merchant and service-payment data, now also the owner of the Humo system.
• Beepul — Beeline Uzbekistan's payment app covering top-ups and bill payments.
• Apelsin — Kapital Bank's app with card accounts and transaction history.
• Soliq — the government tax and payments app holding per-taxpayer obligations and payment records.

How this brief was put together

Compiled on 8 June 2026 from Click's own product pages on click.uz, the app's Google Play and App Store listings, the Central Bank of Uzbekistan's payment-organization and e-money material, and Uzbek payments market coverage. Sources opened directly:

• click.uz — Click Wallet product page
• Central Bank of Uzbekistan — payment organizations
• kun.uz — Central Bank approves unified QR-code rules
• Humo — National Interbank Processing Centre

Engineering notes by OpenFinance Lab, 2026-06-08.

Questions integrators ask about Click

Do you ingest Click history as a batch pull or as a live stream?

Both shapes are on the table. Click's per-account history reads cleanly as paged operations, so the common build is a worker that pulls forward from a saved cursor on a schedule and emits each operation onto a queue. Where near-real-time matters, the same worker runs on a tight poll and the event log stays replayable, so a fresh consumer can rebuild state from the beginning.

How do you handle the split between UzCard and Humo cards?

Click links both, and the two national processing systems describe a transaction slightly differently. We map each into one card-history model with a rail field, so your code reads a single shape whether the operation came over UzCard or Humo.

Is the Click Wallet balance treated the same as a card balance?

No. The Click Wallet is e-money, which under Uzbek rules is issued in soums and reconciles separately from the linked bank cards. We keep wallet events and card-rail events in distinct streams so balances do not get mixed.

What is the legal basis for reaching a user's Click data?

The account holder's own authorization. We work against a consenting account or a sponsor-provided test profile, log what was accessed, minimize the fields we keep, and sign an NDA where the engagement calls for it. Click sits under the Central Bank of Uzbekistan's payment and e-money rules, and the integration is built to respect them.