Reaching the Alif Shop instalment ledger from one consented account

What sits behind an Alif Shop login

Each row maps a data domain to where the app surfaces it, how granular it is, and what an integrator typically does with it. The domains follow the app's own labels where it names them.

Three ways into the ledger

Consented interface integration

This is the one we would actually run. With the account holder's authorization we observe and replay the app's own authenticated requests, mapping the auth chain and the calls behind the limit, plans, schedule and history screens. It reaches everything in the table above at full fidelity. Effort is moderate; durability depends on the app's release cadence, which we account for by re-validating the captured schema when a new version ships. Access to a consenting account is arranged with you at onboarding.

Single-account credential read

When the target is one consenting user rather than a fleet, the same approach narrows to a single set of credentials. It is the quickest thing to stand up, useful for a proof of value before a wider rollout, and it produces the same record shapes.

Native history as a seed

Alif Shop already presents purchase and payment history to the user. Where that view can be pulled directly, we ingest it as a low-friction starting point and then enrich it through the interface route so the schedule and plan terms come through in full. Used on its own it is a partial picture; paired with the first route it shortens the initial backfill.

A backfill run against the plan ledger

The shape below is a batch pull: authenticate as the consenting account, read the limit and active plans, then page through history to a cursor you can store for the next delta. Paths and field names are settled during the build against a live consenting account; treat the snippet as the structure, not as fixed constants.

# Illustrative structure; exact paths and fields confirmed during the build.
import httpx

BASE = "https://app.example/api"   # resolved during interface mapping

def login(msisdn, otp):
    # 3D Secure / OTP sign-in as the consenting account holder
    r = httpx.post(f"{BASE}/auth/verify", json={"msisdn": msisdn, "otp": otp})
    r.raise_for_status()
    return r.json()["access_token"]

def backfill(token, since=None):
    h = {"Authorization": f"Bearer {token}"}
    limit = httpx.get(f"{BASE}/account/limit", headers=h).json()
    plans = httpx.get(f"{BASE}/instalments/plans", headers=h,
                      params={"state": "active"}).json()

    history, cursor = [], since
    while True:
        page = httpx.get(f"{BASE}/orders/history", headers=h,
                         params={"cursor": cursor, "size": 100}).json()
        history += page["items"]
        cursor = page.get("next_cursor")
        if not cursor:
            break

    return {"available_limit": limit,
            "active_plans": plans,
            "history": history,
            "next_cursor": cursor}   # store, resume the delta from here

Normalized plan and payment records

Whatever the wire format, the build normalizes plans into one schema so a fashion plan and a partner phone plan line up. Markup lives in its own field, which reads zero for the Shariah-compliant fashion and lifestyle plans.

{
  "plan_id": "pl_8841",
  "source": "alif_shop_fashion",     // or "telemart_mobile"
  "principal_pkr": 84990,
  "markup_pkr": 0,
  "tenor_months": 6,
  "instalments": [
    {"seq": 1, "due": "2026-07-01", "amount_pkr": 14165, "status": "due"},
    {"seq": 2, "due": "2026-08-01", "amount_pkr": 14165, "status": "scheduled"}
  ]
}

What the build hands over

The headline deliverable is code that runs against this app's surfaces, not a document about it.

• Runnable client source in Python and Node.js for the auth flow, the limit and active-plans reads, and cursor-paged history.
• A scheduled delta worker that re-reads the payment schedule and folds changes back in, idempotent on plan plus instalment sequence.
• A pytest suite with recorded fixtures for the auth chain, an empty-limit account, and a multi-plan account spanning fashion and partner-phone plans.
• The normalized plan/payment schema above, with the loaders that map raw responses onto it.
• An OpenAPI description of the mapped surfaces and a short auth-flow report covering the OTP / 3D Secure / token handling, as secondary artefacts.
• Interface documentation and a data-retention note covering what is stored and for how long.

Consent and the Pakistani rulebook

Alif Finance operates as an SECP-licensed NBFC, so the consumer-lending and digital-lending side of Alif Shop falls under the SECP's NBFC regime and its whitelist of digital lending applications. That governs the lender; it does not hand a third party a data tap. A consumer open-banking data-sharing regime is still being shaped: the State Bank of Pakistan ran an open-banking theme in its regulatory sandbox cohort rather than publishing a live data-portability right. So the basis we rely on is the account holder's explicit authorization, captured and logged.

On data protection, Pakistan's Personal Data Protection Bill was cabinet-approved in 2023 but is not yet enacted, with a national commission proposed under it; we therefore work to documented consent, data minimization, and NDA cover rather than to a statute that has not landed. The 0% markup terms are disclosed in-app before a purchase is confirmed, and we capture that disclosed schedule rather than inferring numbers, so stored records match what the customer actually agreed to. Settlement runs over the country's bank rails, including the State Bank's Raast instant system, which matters when plan due-dates are reconciled against the money side.

What we plan around in this build

Two things about Alif Shop shape the work, and we handle both rather than passing them back as conditions.

First, plan types diverge. The in-app 0% fashion and lifestyle plans and the Telemart partner phone-instalment plans run on different terms and different decisioning, so we model plan type per source and keep the markup and tenor fields honest for each, instead of flattening them into one average plan.

Second, the schedule moves. Upcoming payments shift as instalments clear or get rescheduled, so the sync is a bulk history backfill plus a scheduled re-read of the forward schedule, keyed on plan and instalment sequence so a repeat run updates a row instead of adding a duplicate. The OTP and 3D Secure step-up at sign-in is mapped during onboarding against the consenting account, and consent and access are recorded with the project.

Screens we worked from

Store screenshots used while sketching the data surfaces. Select one to enlarge.

Sources, and who put this together

Checked in June 2026 against the app's store listing, the SECP's licensing release, and the State Bank's payments and sandbox material. Where a fact about endpoints or fields is not publicly documented, this brief says so rather than guessing; the runnable specifics are settled during the build against a consenting account. Primary sources opened: the Google Play listing, the SECP press release on Alif Finance's NBFC licence, the State Bank's Raast page, and reporting on the SBP open-banking sandbox cohort.

— OpenFinance Lab, interface engineering notes, 15 June 2026.

Other Pakistani instalment apps next door

Same market, related ledgers. Anyone unifying BNPL data across Pakistan tends to meet these names, listed for context rather than ranked.

• QisstPay — interest-free instalment splitting at checkout; reported as the first to hold a BNPL licence from the SECP.
• Qist Bazaar — Shariah-compliant BNPL marketplace, holding plan and instalment records much like Alif Shop's.
• KalPay — interest-free plans run with partner merchants, with a comparable schedule and limit structure.
• BaadMay — deferred-payment plans from MG Financial Services, with per-user repayment ledgers.
• Neem — financial services including earned-wage access, holding payroll-linked balance and advance data.
• PostEx — a fintech-and-logistics model giving merchants upfront payment against cash-on-delivery orders.
• Finja — MSME lending, payments and collections, with transaction and credit records on the business side.
• Alfa BNPL — Bank Alfalah's instalment option for card holders, sitting on the bank's own account data.

Questions integrators ask first

Is the upcoming-payment schedule a one-time pull, or can you keep it in sync?

We treat it as both. A first run backfills purchase history and the active plans, then a scheduled delta job re-reads the schedule so cleared or rescheduled instalments show up. Each instalment is keyed on its plan and sequence number, so re-running the job does not duplicate rows.

The fashion plans are 0% markup. Does that markup come through as a field, or is it folded into the price?

The plan terms Alif Shop shows before you confirm a purchase carry the breakdown, so we read the disclosed schedule rather than back-calculating it. In the normalized records the markup sits in its own field, which reads zero for the Shariah-compliant fashion and lifestyle plans and non-zero where a partner plan differs.

Alif Finance is an SECP-licensed NBFC. Does that change how its data can be reached?

It sets the legal frame, not the technical route. Pakistan's consumer open-banking data-sharing rules are still in the State Bank's sandbox stage, so the dependable basis for reaching account data is the account holder's own authorization. We build against a consenting account and keep consent and access records with the project.

Can you keep the Telemart phone-instalment flow separate from the in-app fashion plans?

Yes. The two run on different terms and decisioning, so we tag each plan by its source, in-app fashion and lifestyle versus the partner mobile flow, and normalize them into one schema without flattening the differences. Exposure and schedule reporting can then be split or combined.

Getting a build started

A first build covers the authenticated read path — limit, active plans, the upcoming-payment schedule, and purchase history — and lands in one to two weeks. Take it as runnable source you own outright, billed from $300 and paid only after delivery, once it is in your hands and working. Or skip the code entirely and call our hosted endpoints, paying per call with nothing up front. Either way you give us the app name and what you want out of its data; access and the compliance paperwork are arranged with you as part of the work. Tell us what you are after at /contact.html and we will scope it.