Getting borrower records out of Paisayaar's loan platform

A Paisayaar borrower who logs in sees one loan at a time: a principal between Rs 1,000 and Rs 50,000, a markup quoted by the month, a due date, and a running outstanding balance. That account — not a marketing page — is the thing an integrator wants. It is held server-side behind a phone-number login, it changes as repayments land through Easypaisa, and it carries the fields a credit team or aggregator needs to reconcile a borrower's position. This brief maps what is in that account and the authorized way to read it.

The honest starting point for Pakistan: a regulated account-information regime is not yet switched on for non-bank lenders. The State Bank published an open banking framework in 2022 and its API guidelines are still being finalized. So the dependable basis for a Paisayaar build today is the borrower's own consent over their own session, run as authorized interface integration. We recommend exactly that, and treat the SBP route as where this work migrates once the guidelines land — covered in the consent section below.

Borrower data Paisayaar keeps server-side

Each row reflects a surface the app actually exposes to a logged-in borrower or to its mandated disclosure flow. Field names are confirmed against a live, consenting session during the build rather than assumed here.

Authorized ways into the loan account

Three routes genuinely apply to Paisayaar. None of them depends on Pakistan's open-banking APIs being live, which they are not yet.

Consented interface integration

We work the borrower's own authenticated session — the OTP login, the loan dashboard, the repayment history — and read the records the borrower can already see. Reachable: the full loan ledger, schedule, status and KFS. Effort is moderate; durability depends on the H5 borrower screens staying put, which we account for. Access is arranged with you during onboarding, against a consenting account, so no scope beyond the borrower's own data is ever touched. This is the route we would actually run for Paisayaar now.

Protocol analysis of the app's traffic

Where a documented, repeatable contract is wanted, we map the request and response shapes the app uses for login, loan lookup and status, then implement them as clean endpoints under the customer's authorization. Reachable: the same domains, expressed as a stable interface rather than a screen scrape. Effort is higher up front; durability is better because the parser keys off documented fields, not page layout.

Native export as a fallback

The app and its SECP-required disclosures push a Key Fact Statement out by screenshot, email and SMS in English and Urdu. That export is narrow — one loan's terms, not a history — but it is a useful corroborating feed for the KFS row and needs no session at all. We treat it as a supplement, not a primary source.

What lands in your repo

The deliverable is a working integration tied to the surfaces above, not a slide deck. For Paisayaar that means:

• An OpenAPI/Swagger specification covering loan lookup, repayment schedule, event history and application status.
• A protocol and auth-flow report documenting the OTP-to-token handshake, token lifetime and refresh, and the cookie or bearer chain as it actually behaves.
• Runnable source for the key endpoints in Python or Node.js — the login handshake, the active-loan read, the history pull — with retry and error handling.
• Automated tests against recorded fixtures so a screen or field change is caught before it reaches your data.
• Interface documentation that normalizes the monthly markup and the annual band into one rate and one outstanding figure.
• Compliance and data-retention guidance written for the SECP data-localization rule and consent logging.

A repayment-status pull, sketched

Illustrative only — the exact paths, field names and token mechanics are confirmed against a live consenting session during the build, not asserted here. The shape mirrors an OTP login followed by a read of the active loan.

# Confirmed against a consenting borrower session during the build.

POST /auth/otp/verify
  { "msisdn": "+9233XXXXXXXX", "otp": "######", "device_id": "..." }
  -> 200 { "access_token": "...", "expires_in": 3600, "borrower_id": "..." }

GET  /loans/active
  Authorization: Bearer <access_token>
  -> 200 {
       "loan_id": "...",
       "principal_pkr": 12000,
       "markup_pct_monthly": 1.0,      # 12%/12 in the app's own example
       "term_days": 90,
       "outstanding_pkr": 8240,
       "next_due": { "date": "2026-07-05", "amount_pkr": 4120 },
       "status": "DISBURSED"
     }

# Python read with refresh + backoff
import requests, time

def active_loan(session, token):
    for attempt in range(3):
        r = session.get(f"{BASE}/loans/active",
                        headers={"Authorization": f"Bearer {token}"})
        if r.status_code == 401:
            token = refresh(session)            # OTP session expired
            continue
        if r.status_code == 429:
            time.sleep(2 ** attempt)            # respect throttle
            continue
        r.raise_for_status()
        loan = r.json()
        loan["effective_outstanding"] = loan["outstanding_pkr"]
        return loan
    raise RuntimeError("active-loan read failed after retries")
      

Consent and the Pakistani regulatory picture

Two regulators frame this. The SECP licenses Paisayaar's operator as an NBFC and governs digital lending conduct: its 2024 circulars require a Key Fact Statement in English and Urdu, bar lenders from reaching a borrower's phonebook, contacts or gallery, and require borrower data to stay on infrastructure inside Pakistan. The State Bank owns the payment and open-banking side — its 2022 open banking framework and the API guidelines still in progress are the route a regulated account-information feed will eventually take.

Because that SBP route is not live for lenders, the build rests on the borrower's own authorization, scoped to their own loan records, with a consent record kept and an expiry that the borrower can revoke. We log access, minimize what we store, keep that store in-region to match the SECP localization rule, and sign an NDA where the engagement needs one. None of this requests scopes the app itself is forbidden from collecting.

What we plan for in a Paisayaar build

Concrete things this app forces, all handled on our side:

• Short-lived OTP sessions. Login is keyed to the borrower's MSISDN and the token expires; we design the sync around token refresh so a long-running pull does not silently drop mid-history.
• Data localization. SECP requires borrower data stay inside Pakistan, so we keep the integration's storage and logs in-region and data-minimized from the first commit, rather than retrofitting it.
• Rate math that does not match itself. The app quotes markup by the month (1% in its worked example) while the listing shows a 2–12% annual band; we normalize both to one effective rate and one outstanding figure so reports reconcile.
• H5 front-end churn. The borrower screens are web views that get updated; we keep a field-level check that flags when a response shifts, so the parser is patched before stale data ships.

Where integrators put this

• A multi-lender dashboard pulling a consenting borrower's outstanding balance and next due date from Paisayaar alongside other NBFCs into one position.
• A credit-decisioning step that ingests a returning borrower's repayment history, with their consent, to size a renewal.
• A bookkeeping sync that maps Easypaisa repayment events against the loan ledger into accounting software.
• A reminder service that reads the repayment schedule and nudges before each installment falls due.

Screens we mapped

The store screenshots we worked from while sketching the surfaces above. Tap to enlarge.

Sources and review

We read Paisayaar's Play Store listing and its own description for the loan terms, operator and Easypaisa repayment flow; the SECP digital-lending circular for the KFS, contacts and data-localization rules; an SECP whitelist report to confirm its licensed standing; and an open-finance tracker for the State Bank's open banking status. Checked June 2026.

• Paisayaar on Google Play (listing and loan terms)
• SECP Circular 12 of 2024 — requirements for NBFCs in digital lending
• SECP whitelist of digital lending applications (Business Recorder)
• Pakistan open banking status — SBP framework tracker

Mapping compiled at the OpenBanking Studio integration desk, 19 June 2026.

Other Pakistani lending and wallet apps in the same orbit

Plain context for keyword reach and for anyone scoping a unified loan view; these are peers, not rankings.

• JazzCash (JazzCash Advance) — wallet whose advance feature holds short-term credit balances scored off transaction history.
• Easypaisa (EasyCash) — the wallet Paisayaar repays through; its EasyCash facility records its own loan balances and repayment events.
• SmartQarza — SECP-licensed advance app holding salary-advance records through employer links.
• Aitemaad — small personal loans with KYC and transfer records held per borrower.
• Fauri Cash — nano-lending app run by an SECP-approved microfinance company, with instant microloan and repayment records.
• Daira — digital lending app holding loan applications, schedules and repayment status.
• PakCredit — personal loan app with borrower profiles and installment ledgers.
• MoneyTap — credit-line style app holding limit, drawdown and repayment data.
• UdharPaisa — short-term loan app with application status and repayment schedules.

Questions integrators ask about Paisayaar

Can you separate Paisayaar's monthly markup from the annual rate band on its listing?

Yes. Its own example quotes markup per month (1% a month on a three-month loan) while the listing shows a 2% to 12% annual band. We normalize both into one outstanding-balance and effective-rate figure so downstream numbers reconcile.

Does the SECP rule against accessing contacts limit what an integration can read?

That rule limits what the app may collect from a device. It does not limit reading the borrower's own loan and repayment records under their consent. Our integration stays inside the loan account and never requests phonebook or gallery scopes.

Pakistan's open-banking APIs are not fully live yet — what does that mean for a Paisayaar build?

The State Bank's open banking framework was published in 2022 and its API guidelines are still being finalized, per the open-finance tracker we checked. That is where a regulated account-information route lands later. Today the build runs on the borrower's own consented session.

Repayment runs through Easypaisa — so where does the repayment data actually come from?

Easypaisa is the rail the borrower repays on, via the Easypaisa app or USSD as the listing describes. The disbursement and repayment events are recorded against the loan account on Paisayaar's side, and that loan account is what the integration reads.

On price: source-code delivery starts at $300, billed only after we hand it over and you have confirmed it runs against your own data; or skip the build fee entirely and call our hosted endpoints, paying per call. Either way the cycle is one to two weeks. Tell us the app and what you want from its loan records on the contact page and we will scope it.