Reading a UPaisa wallet’s data with the account holder’s consent

Every UPaisa wallet is opened against a CNIC and the mobile number it is registered to, and that pairing is what keys the ledger held on U Microfinance Bank’s servers. U Bank is the PTCL-owned microfinance bank behind the service; Ufone is the telco half of the partnership. So when a Pakistani business wants UPaisa transfers, bills and load history flowing into its own books, the question is not which feature to copy — it is how to read one customer’s ledger, with their permission, in a form your code can use.

That read is the work we do. We map the authenticated surfaces a UPaisa account exposes, model the CNIC-and-OTP login, and hand back a typed client plus documentation for the endpoints that matter to you. The client gives us the app name and what they need out of it; access and the consenting account are arranged on our side as the build runs.

What the wallet stores

UPaisa is a payments wallet first, so most of its value is movement: who sent what to whom, which bill cleared, which number got topped up. The table below is the set of surfaces an account actually exposes, named the way the app names them, with what a reader would do with each.

Two notes shape any read of this. The history view is shallow — community reports describe it surfacing only recent transactions, identified by TID — and a single label like “money transfer” covers several different rails underneath. Both are things to design around, not blockers.

Ways into the ledger

Three routes genuinely apply to UPaisa. They differ in what they reach and how much onboarding sits behind them, and we set up whichever fits during the project.

User-consented interface integration

We capture the app’s authenticated traffic against an account whose holder has authorized the work, then model the CNIC-and-OTP login and the transaction, transfer and bill endpoints into a typed client. Reach: the full ledger the holder can see. Effort is moderate; durability tracks the app’s release cadence, so the client carries a re-validation step for when the front end shifts.

Raast rail participation

For projects that are really about moving money rather than reading a wallet, Raast is the regulated path — P2P and P2M, EMVCo QR, governed by SBP’s Raast Participation Criteria introduced in early 2025. This goes through a sponsor bank, EMI or PSO, which we coordinate with you. Reach is payment initiation and settlement, not a specific person’s history; durability is high because it is a central-bank rail.

Native statement as a fallback

Where a consenting holder can pull a statement or export from the app, we parse that as a low-touch supplement. It is the least code but the narrowest window, since the in-app view is limited.

For most requests that land here — read this customer’s UPaisa activity into our system — the consented interface route is the one we would build. Pakistan’s open-banking APIs are still at sandbox stage, so there is no live data-sharing endpoint to call; the dependable basis today is the account holder’s authorization, with Raast kept for the cases that are about sending money, not reading it.

A statement pull, end to end

Here is the shape of the client we deliver for the read route. Field names are illustrative and get confirmed during the build against a consenting account; the flow mirrors what a user sees at sign-in.

# Illustrative UPaisa wallet client — CNIC + OTP auth, the same flow a user follows.
import httpx

BASE = "https://api.upaisa.example"        # captured host, fixed during onboarding

def request_otp(msisdn, cnic, cnic_issue_date):
    # The app posts the wallet's number, CNIC and its issuance date;
    # UPaisa returns a challenge id and SMSes a one-time password.
    r = httpx.post(f"{BASE}/v1/auth/otp", json={
        "msisdn": msisdn,                  # 03XXXXXXXXX, the number the wallet is on
        "cnic": cnic,                      # 13-digit national ID, no dashes
        "cnicIssueDate": cnic_issue_date,
    })
    return r.json()["challengeId"]

def verify_otp(challenge_id, otp):
    # Exchange the OTP for a short-lived session token (the second factor).
    r = httpx.post(f"{BASE}/v1/auth/otp/verify",
                   json={"challengeId": challenge_id, "otp": otp})
    return r.json()["sessionToken"]

def transactions(token, cursor=None):
    # The ledger as the holder sees it — recent items only, so we page on a
    # cursor and persist locally rather than re-querying deep history.
    r = httpx.get(f"{BASE}/v1/wallet/transactions",
                  headers={"Authorization": f"Bearer {token}"},
                  params={"cursor": cursor, "limit": 20})
    r.raise_for_status()
    return r.json()["items"]   # tid, type, amount, counterparty, channel, ts, status
      

Errors get their own handling: an expired session re-runs the OTP step, a Raast transfer that is still pending is polled rather than assumed settled, and the multi-rail transfer types are normalised into one schema so your downstream code does not branch on channel.

What you receive

The handover is built around the surfaces above, not a generic template.

• An OpenAPI / Swagger description of the wallet read endpoints we model — auth, balance, transactions, transfers, bills.
• A protocol and auth-flow report covering the CNIC-OTP challenge, session-token lifetime and the two-factor step.
• Runnable source for the key calls in Python or Node.js — the typed client shown above, fleshed out and tested.
• Automated tests against recorded responses, so a UPaisa app update that breaks a field fails loudly in your CI.
• Interface documentation an in-house engineer can maintain after handover.
• Data-retention and consent guidance: what we capture, what we drop, how a holder’s authorization is recorded and revoked.

Where it plugs in

A few of the shapes this work usually takes, end to end:

• A bookkeeping or SME-accounting tool that ingests a consenting merchant’s UPaisa transfers and bill payments and categorises them automatically.
• A lender pulling a borrower’s wallet activity, with consent, as one input to an affordability view alongside other accounts.
• A payouts platform that confirms wallet-to-CNIC and Raast P2P transfers have settled before marking an order paid.
• A personal-finance app that shows a household its UPaisa spend next to bank and card data in one normalised feed.

SBP, Raast & consent

UPaisa sits inside the State Bank of Pakistan’s perimeter as branchless banking run by U Microfinance Bank. Two things follow. First, the account is protected by genuine two-factor auth — CNIC plus a one-time password, with biometric checks on some channels — so any read has to come through a real, authorizing holder, never around the login. Second, Pakistan does not yet have a live consumer data-sharing regime: SBP has published an open-banking framework and runs a regulatory sandbox, but that is a forward path, not an endpoint you can call today. We treat it as where the rules may go, and we lean on the holder’s own consent as the present-day basis.

On the rail side, Raast is the SBP-operated instant-payment system; institutional participation in it follows the Raast Participation Criteria. Pakistan’s broader personal-data law is still pending rather than enacted, so we do not lean on it; instead we operate the way regulated work expects — access authorized and logged, data minimised to the fields a use case needs, consent recorded with an expiry and a revocation path, and an NDA where the engagement calls for one.

What we plan around

Specifics of this app that we account for, rather than hand to you as conditions:

• A shallow history window. Because the in-app ledger surfaces only recent items by TID, we design the sync to capture incrementally on a schedule and persist a fuller record on your side, so deep history accrues even though it is not queryable in one call.
• One label, several rails. A UPaisa transfer can be wallet-to-wallet, wallet-to-bank, wallet-to-CNIC, wallet-to-other-wallet or Raast P2P. We map each to a typed transfer with its rail and counterparty fields so your code reads one consistent schema.
• Session and second-factor handling. We model the OTP challenge and the session-token lifetime so the client re-authenticates cleanly, and we keep the CNIC issuance date and the OTP out of storage beyond the session.
• Front-end churn. When the app ships an update, we re-run the capture against a consenting account and patch any field changes before they reach your code; the test suite is what flags them.

Access itself is arranged with you during onboarding — the build runs against a consenting account, set up as part of the work.

Pricing & handover

Source for a UPaisa read client usually comes back inside one to two weeks. From there you can take it one of these directions. Buy the source outright from $300: you get the runnable client, the OpenAPI description, tests and docs, and you pay once it is delivered and you are satisfied with it. Or skip owning code and call our hosted endpoints for the UPaisa surfaces you need, paying per call with nothing upfront. Either way the deliverable is the same set of wallet reads; the choice is whether you run it or we host it. Tell us the app and what you want out of it on the contact page and we will scope it back to you.

Screens we mapped

The store screenshots we worked from while tracing the wallet, transfer and payment flows. Tap to enlarge.

How this came together

Checked in June 2026 against UPaisa’s store listing and U Bank’s own pages for the feature set and the operator structure, and against the State Bank of Pakistan’s Raast and e-money material plus reporting on Pakistan’s open-banking framework for the regulatory picture. The package id pk.upaisa.com and the iOS and Android availability are per the app’s listings. User counts and agent-network figures cited around the web are third-party estimates, so they are not asserted here as official numbers.

• UPaisa – Digital Wallet on Google Play
• State Bank of Pakistan — Raast instant payment system
• SBP — Regulations for Electronic Money Institutions (PDF)
• The Express Tribune — Pakistan and the open-banking framework

Mapped by the OpenBanking Studio integration desk, June 2026.

Other Pakistani wallets in the same picture

If a UPaisa integration is part of a wider Pakistani-wallet effort, these are the names that usually sit alongside it. Listed for context, not ranked.

• JazzCash — Jazz’s wallet, widely reported as the country’s largest, holding balances, transfers, bill payments and QR pay.
• Easypaisa — Telenor Microfinance Bank’s wallet and digital account, with transfers, bills and savings products.
• SadaPay — an EMI-licensed digital account known for free Raast transfers and a Mastercard debit card.
• NayaPay — an EMI wallet with a debit card, P2P transfers and merchant payments.
• Zindigi — JS Bank’s app-first wallet and account, covering transfers, cards and savings.
• HBL Konnect — HBL’s branchless-banking wallet with an agent network, transfers and bill payments.
• UBL Omni — one of the older branchless-banking services, handling agent-assisted transfers and bills.
• Keenu Wallet — a payments wallet with broad QR acceptance and merchant tools.

Questions integrators ask about UPaisa

Can you read a full UPaisa statement, or only the recent transactions the app shows?

The in-app history is short — community reports describe only recent transactions, listed by transaction ID. We read what a consenting account can see, capture it incrementally on a schedule, and persist a fuller ledger on your side, so you are not limited to whatever the app keeps on screen.

Which Pakistani regulator and payment rails matter for a UPaisa integration?

The State Bank of Pakistan is the regulator. UPaisa runs as branchless banking under U Microfinance Bank, a PTCL subsidiary, and its instant transfers ride Raast, the SBP-operated rail. SBP open-banking work is still at framework and sandbox stage, so we anchor a read integration on the account holder’s own authorization rather than a live data-sharing API.

How do you handle UPaisa’s CNIC and OTP login inside the client you build?

We model the same two steps a user goes through: the app posts the mobile number, CNIC and CNIC issuance date to request a one-time password, then exchanges that code for a short-lived session token. The client re-authenticates when the token expires and never stores the OTP or issuance date beyond the session.

Does reading a UPaisa wallet require us to join Raast?

No. Raast participation is for institutions initiating or settling payments, and is arranged through a sponsor bank or EMI when a project actually needs it. Reading one customer’s wallet — balances, transfers, bills — runs through the consented interface route and does not depend on rail membership.