Getting structured data out of a NayaPay account

More than three million users sit behind a single NayaPay wallet credential, as the app describes it, and each wallet carries the same shape of server-side record: a running balance, a timestamped statement, a stack of digital receipts, and a Visa debit card whose limits and freeze state live on the backend. That is the material an integrator actually wants. This brief maps where each piece originates inside the app, the authorized way to reach it, and what we hand back at the end.

NayaPay is regulated as an Electronic Money Institution by the State Bank of Pakistan, and its money movement runs over Raast — the central bank's instant payment rail — alongside Visa and the 1Link network. That regulatory shape matters for how we phrase consent, and it shapes the route we recommend below.

What sits behind the wallet

Each row below is a surface NayaPay shows its own users; the value is in pulling it as structured records rather than reading it off a screen.

How we reach it

Two or three routes genuinely apply to NayaPay; the right mix depends on whether you want data today or want to sit on the regulated rail as it lands.

Authorized session integration

The account holder authorizes us, and we work from the authenticated session the app builds after MPIN or biometric sign-in. Everything the wallet displays is reachable this way — balance, statements, card state, transfers. Effort is moderate; durability depends on the app front end, which we account for in maintenance. This is what gets a working integration in front of you fastest.

SBP / Raast open-banking consent

The State Bank has published an open banking framework and stood up a sandbox, with consent management and standardized APIs as named pillars. The participant rails are still maturing, so we design the consent flow in now and switch to it as it becomes available, rather than waiting on it. Durability here is the strongest once live, because it is the sanctioned data-sharing channel.

Native statement export

NayaPay lets a user export statements from My Wallet. It is coarse next to a live pull, but it is a clean way to backfill history at the start of a build and to cross-check the session route.

For a NayaPay build right now, the consenting account's own session is the path we would take — the wallet, statements and card controls are all reachable there, and it does not hinge on the open-banking rollout finishing. We keep the Raast and SBP consent route in the design so the integration moves onto it cleanly when participants light up, and use the in-app export to seed history.

What lands in your repo

The output is a working integration, not a report. For NayaPay that means:

• An OpenAPI/Swagger spec describing the normalized endpoints — balance, statement, card status, transfer history — with the request and response fields documented.
• A protocol and auth-flow write-up covering the MPIN / biometric sign-in, the session token, and how it refreshes.
• Runnable source for the key calls in Python or Node.js, including the statement pull and the three-way identifier normalization (IBAN / Raast ID / mobile number).
• Automated tests against a consenting account, plus fixtures for the statement and receipt shapes.
• Interface documentation and data-retention guidance fitted to SBP expectations.

A statement pull, in practice

Illustrative shape of the normalized call we ship — field names confirmed against the consenting account during the build, not guessed:

# Authorize against the wallet session (MPIN / biometric -> short-lived token)
POST /session/auth
  { "device_id": "...", "mpin_proof": "...", "biometric": true }
  -> 200 { "access_token": "...", "expires_in": 900 }

# Pull a statement window for the consenting account
GET /wallet/statements?from=2026-05-01&to=2026-05-31
  Authorization: Bearer <access_token>

  -> 200 {
       "account": { "iban": "PK..", "raast_id": "+92..", "currency": "PKR" },
       "balance": { "available": 41250.00, "ledger": 41250.00 },
       "transactions": [
         { "id": "txn_...", "ts": "2026-05-18T09:14:22+05:00",
           "type": "raast_credit", "amount": 18000.00,
           "counterparty": { "raast_id": "+92..", "name": "..." },
           "receipt": { "ref": "...", "channel": "raast" } }
       ]
     }

# Token expiry and over-limit declines are real responses, not failures:
#   401 -> refresh via /session/auth
#   403 limit_exceeded -> annual card ceiling reached (see engineering notes)
      

Consent and the SBP frame

NayaPay operates under State Bank of Pakistan EMI regulation, and the country's open banking framework puts customer consent and data ownership at its centre. We work only with the account holder's explicit authorization, scoped to the data domains a project actually needs and time-boxed so consent can expire or be revoked. Access is logged, consent records are kept, and we minimize what is pulled to the fields in scope. Where a client requires it, the work runs under an NDA. NayaPay states it holds PCI DSS and ISO 27001 certification; we treat card-adjacent data accordingly and keep PAN-level detail out of scope unless a project has a documented reason and the consent to match.

Things we handle on this app specifically

• Three identifiers, one payee. A NayaPay account answers to an IBAN, a Raast ID, and the mobile number that is also the account number. We normalize all three onto one counterparty during extraction so transfers don't fragment into duplicate payees.
• The annual card ceiling is stateful. Card-based international spend is capped at USD 30,000 per year per the SBP directive, as NayaPay's help centre states. We model that running counter so a sync reads an over-limit decline as a limit event, not a transport error.
• Re-auth windows. The session token is short-lived and tied to MPIN or biometric re-auth. We build the sync around that window so it refreshes cleanly instead of silently dropping mid-pull, and front-end updates get a re-check pass as part of ongoing maintenance.

Interface evidence

Public store screenshots of the surfaces referenced above. Tap to enlarge.

How fresh the data runs

NayaPay pushes an instant alert on every send, receive and spend, so the transaction feed is close to real time on the session route. Balance reads track that. Statements are the periodic, settled view — good for reconciliation, lagging the live feed by design. We surface both so a consumer of the data knows which it is looking at.

What we checked

This mapping draws on NayaPay's Play Store listing and help centre, its EMI licence announcement, and the State Bank of Pakistan's open banking and Raast material, reviewed June 2026. Primary sources:

• NayaPay — EMI licence approval from the State Bank of Pakistan
• NayaPay Help Center — annual international card limit (USD 30,000)
• NayaPay Help Center — Raast / bank transfer details
• Pakistan open banking — SBP framework summary

Mapped by the OpenBanking Studio integration desk · 2026-06-17

Peer wallets in the same data picture

Same-category Pakistani apps an integrator often needs to unify alongside NayaPay. Named for ecosystem context only.

• SadaPay — EMI wallet with IBAN and a Visa debit card; very close data shape to NayaPay.
• Easypaisa — large mobile wallet and microfinance bank with balances, transfers and bill payments.
• JazzCash — wallet and payments app with QR, bills and transfers across a wide merchant base.
• Zindigi — digital banking app from JS Bank with accounts and card features.
• UBL Omni — branchless banking wallet from a major commercial bank.
• HBL Konnect — HBL's branchless wallet with transfers and bill payment.
• PayPak — domestic card scheme used as a low-cost payment rail by several apps.

Questions integrators ask

Can you reach NayaPay balances and statements without re-scraping the app screen every time?

Yes. We study the authenticated session the app already uses after MPIN or biometric sign-in, then drive the same statement and balance calls directly. The output is a stable JSON contract rather than screen captures, so a balance read or a statement pull behaves the same way each run instead of breaking when a layout shifts.

Pakistan's open banking framework is still rolling out — what does a NayaPay build rely on in the meantime?

The State Bank of Pakistan published an open banking framework and a regulatory sandbox, but the consent-API rails are still maturing across participants. So a build today rests on the account holder's own authorization over their NayaPay session, with the SBP and Raast consent route designed in as it firms up. The dependable basis is the consenting user, not a framework milestone.

How do you keep Raast IDs, IBANs and the NayaPay mobile-number ID from fragmenting a counterparty?

A NayaPay account is addressable three ways — its IBAN, a linked Raast ID, and the mobile number that doubles as the account number. We normalize all three onto one counterparty record during extraction, so a transfer keyed on a Raast ID and one keyed on an IBAN resolve to the same payee instead of looking like two people.

We only have one freelancer's NayaPay account with remittance inflows — is that enough to map the integration?

It is. A single consenting account that receives IBAN remittances through the partner network is enough to map the inflow records, the statement format and the receipt fields. We build and test against that account, and the resulting source generalizes to other consenting users.

Engagement runs against the working code itself: source-code delivery starts at $300 and is paid only after delivery once you are satisfied with what runs, or you can skip the build fee entirely and call our hosted NayaPay endpoints on a pay-per-call basis. Either way the cycle is one to two weeks. Tell us the app and what you want from its data — access and the consent paperwork are arranged with you as part of the work. Start a NayaPay integration.