Reaching the data behind a QUICK PAY recharge account

Every top-up a user makes in QUICK PAY lands as a dated, operator-tagged row on the server, and that ledger — plus the live package catalog it pulls from — is what an integrator almost always wants. The app, listed on Google Play under the package com.digitalloadtelecom.user, sells one job: instant prepaid recharge and data-pack activation for the major Bangladeshi networks. Behind that simple front end sits structured per-account state worth syncing.

Bottom line: the recharge ledger and the offer catalog are the high-value surfaces, both are reachable from a consenting account, and the cleanest way to get them is to document the handful of JSON calls the app already makes. The rest of this brief walks the data, the route, and what you would actually receive.

What a QUICK PAY account actually stores

The surfaces below come straight from the app's own feature set as it describes itself on the store listing — recharge, packages, special deals, and history. Each maps to a server-side record an integrator can read.

Authorized routes into the recharge ledger

Three routes genuinely apply to an app shaped like this. None of them touch authentication you do not own; all of them run inside a consenting account.

Protocol analysis of the app's traffic

Capture the HTTPS/JSON calls the QUICK PAY client makes — the OTP login, the history fetch, the package list — document the token chain, and rebuild them as a tidy, versioned API. This reaches everything the app itself can see. It needs a re-validation pass when the backend rotates auth or reshapes the offer feed, which we plan for rather than bolt on later.

User-consented session access

Operate within an account holder's authenticated session to read their own ledger and saved numbers. Lower effort than full traffic mapping, and the natural way to validate that captured fields match what a real user sees on screen.

Native history readout

The in-app history view is itself an export surface. Where any share or download exists we use it; where it does not, we read the rendered ledger within consent as a fallback for fields the JSON calls do not return.

For QUICK PAY the protocol-analysis route is the one we would build on. The app's surface is a small, stable set of calls — sign in, list history, list packages — so documenting them once gives you the entire ledger without leaning on a fragile screen layout, and we keep a consenting session alongside it purely to check every field against the live app.

A recharge-history pull, step by step

Login is phone number plus OTP; the session is a bearer token; history pages. Sketch below is illustrative — exact paths and field names are confirmed during the build, not lifted from any published document.

# Illustrative shape of the calls the QUICK PAY client makes.

POST /api/v1/auth/verify-otp
Content-Type: application/json
  { "msisdn": "8801XXXXXXXXX", "otp": "452190", "device_id": "..." }
-> 200 { "access_token": "eyJ...", "expires_in": 3600, "customer_id": "..." }

# The recharge ledger, paged:
GET /api/v1/recharge/history?page=1&limit=50
Authorization: Bearer eyJ...
-> 200 {
     "items": [
       { "txn_id": "...", "msisdn": "8801712345678", "operator": "GP",
         "amount": 50.00, "currency": "BDT", "type": "AIRTIME",
         "status": "SUCCESS", "created_at": "2026-06-18T09:14:22+06:00" }
     ],
     "page": 1, "total": 137
   }

Around that we wrap the unglamorous parts: refresh the token before it lapses, back off and retry on a 429 or a 5xx, and treat a mid-page 401 as a re-auth event, not a crash.

def fetch_history(session, token):
    page, out = 1, []
    while True:
        r = session.get(f"{BASE}/api/v1/recharge/history",
                         params={"page": page, "limit": 50},
                         headers={"Authorization": f"Bearer {token}"})
        if r.status_code == 401:          # session lapsed -> re-auth, resume
            token = reauth(session)
            continue
        r.raise_for_status()
        body = r.json()
        out += body["items"]
        if page * 50 >= body["total"]:
            break
        page += 1
    return out

Normalizing across the operators

Raw rows arrive with operator codes and pack labels that differ by screen and by network. We flatten them to one shape so a consumer never has to special-case Grameenphone against Teletalk.

{
  "transaction_id": "qp_8f3a...",
  "subscriber_msisdn": "+8801712345678",
  "operator": { "code": "GP", "name": "Grameenphone" },
  "product": { "kind": "data_pack", "label": "5GB / 30 days", "price_bdt": 398 },
  "status": "success",
  "occurred_at": "2026-06-18T09:14:22+06:00",
  "source_app": "QUICK PAY"
}

What lands in your repo

The deliverable is concrete and tied to the surfaces above, not a generic kit:

• An OpenAPI/Swagger spec covering the login, recharge-history and package-catalog endpoints, with the normalized schema as response models.
• A protocol and auth-flow report: the OTP exchange, token lifetime and refresh behaviour, and how the package feed is requested.
• Runnable source for those endpoints in Python or Node.js — pagination, token refresh and retry already wired, as in the sketch above.
• Automated tests against recorded responses so a field rename in the app surfaces as a failing test, not silent data loss.
• Interface documentation plus a short data-retention and consent-logging note for how the recharge data is stored downstream.

Where teams plug this in

• A personal-finance app shows users their telecom spend by pulling the QUICK PAY ledger and rolling it up per number, per month.
• A cashback or loyalty platform diffs activation records to award points the moment a qualifying pack is bought.
• A reseller or agent dashboard aggregates the recharge ledger across many numbers for end-of-day reconciliation against operator settlements.
• A price-watch service tracks the package catalog and alerts when an operator repackages or repriced a popular data pack.

Consent and the rules that apply in Bangladesh

Recharge and top-up sit in Bangladesh's payments space, supervised by Bangladesh Bank, with the telecom networks themselves under the BTRC. Bangladesh Bank's Mobile Financial Services Regulations (2022) frame how MFS and payment flows operate, and the central bank has since circulated draft rules to open e-money issuance to non-bank players — a moving target rather than a settled portability mandate. There is no open-banking AIS scheme in force here that would hand a third party programmatic access by right.

So the work rests on the account holder's own authorization to reach data they already hold. Bangladesh's Personal Data Protection Act remained a draft with in-principle cabinet approval in November 2023 and was not enacted as this was written, so we treat it as the direction of travel, not current law. In practice that means consent on record, access logged, only the fields you need retained, and an NDA where the engagement calls for one.

What we account for so the sync keeps working

Two things in particular bite a naive scraper of this app, and we handle both up front.

First, operator fragmentation. QUICK PAY spans Grameenphone, Robi, Banglalink, Airtel and Teletalk, and each network names its packs and validity windows differently. We map every in-app SKU to its underlying operator offer and expose one operator field, so a five-network ledger reads as a single clean stream.

Second, the OTP-and-token lifecycle. The login is phone plus one-time code and the session expires, so we design the pull around token refresh — it will not silently 401 halfway through a long history — and we wire a re-validation step for when the backend rotates its auth or the offer feed shifts. MSISDN formatting gets normalized to a consistent +880 form on the way out, since the app stores numbers a few different ways. Access and any test number are arranged with you during onboarding; the build runs against a consenting account.

Pricing and how delivery works

Source for the recharge-history and package endpoints, with tests, usually lands within one to two weeks of a confirmed scope. You can take it as a one-off code drop — runnable source plus interface documentation from $300, billed only after delivery once it runs for you — or skip hosting it and call our managed endpoints instead, paying per call with nothing upfront. Tell us the app and what you want out of its data and we size it from there: start a brief with the studio.

Screens we mapped

The store screenshots below are what we work from when tracing which surface a given record comes from. Tap any to enlarge.

The Bangladesh recharge and wallet neighbourhood

QUICK PAY sits among a dense field of Bangladeshi recharge and mobile-money apps. A unified integration across them mostly comes down to reconciling each one's ledger and offer catalog into a shared shape.

• bKash — the dominant MFS wallet, holding balances, send-money and mobile-recharge records behind a PIN login.
• Nagad — the Bangladesh Post Office digital financial service, with wallet balances, transaction history and recharge.
• Rocket — Dutch-Bangla Bank's bank-led MFS, keeping account-linked transaction and top-up records.
• Upay — the UCB-backed MFS wallet, with payment and recharge histories per account.
• MyGP — Grameenphone's self-care app, exposing balance, data-pack and recharge activity for a number.
• My Robi — Robi's self-care app, with usage, pack purchases and recharge logs.
• Tap — Trust Axiata Pay's MFS wallet, carrying payment and recharge transaction logs.
• iPay — a payments app bundling mobile recharge across operators with stored transaction history.

How this brief was put together

Drawn in June 2026 from the app's own Google Play listing and feature description, the airtime-operator coverage for Bangladesh's networks, Bangladesh Bank's mobile-financial-services framing, and a reading of where the country's data-protection law stands. Primary sources:

• QUICK PAY on Google Play (com.digitalloadtelecom.user)
• Bangladesh airtime operator coverage — Grameenphone, Robi, Banglalink, Teletalk
• Bangladesh Bank — Mobile Financial Services Regulations, 2022 (PSD circular)
• Overview of Bangladesh's Data Protection Act 2023 (draft status)

Mapped by the OpenBanking Studio integration desk · June 2026.

Questions integrators ask about QUICK PAY

Can you separate Grameenphone, Robi and Banglalink recharges in the exported history?

Yes. Each row in the recharge ledger carries an operator tag, so the export keeps Grameenphone, Robi, Banglalink, Airtel and Teletalk transactions distinct. We normalize those tags into one operator field with a stable code, since the in-app labels are not always spelled the same way across screens.

Does the package and offer catalog come through as live data or a one-time dump?

Either. Operator data and minute packs change often, so we usually deliver the catalog as a scheduled snapshot that diffs against the previous pull, so a downstream consumer sees when an offer is added, repriced or withdrawn rather than treating it as static.

Bangladesh has no open-banking mandate yet, so what is the legal basis for pulling this?

The dependable basis is the consenting account holder's own authorization to access data they already own in the app. Bangladesh's Personal Data Protection Act was a draft with in-principle cabinet approval in November 2023 and was not enacted at the time of writing, so we do not rely on a statutory portability right; consent, logging and data minimization carry the work.

We only have the QUICK PAY consumer app, not a backend login. Can you still map it?

Yes. The work runs from the app's own HTTPS traffic inside a consenting account: we capture the login, history and package calls, document the auth chain, and rebuild them as a clean API. Access and any test number are arranged with you during onboarding.