Reaching ePay Punjab's PSID and government-receipt records

Every payment in ePay Punjab hangs off one object: a 17-digit PSID, unique to each transaction, that ties a citizen's tax or challan due to the channel that finally settles it. The app, which PITB describes as Pakistan's first public-to-government and business-to-government payment aggregator, generates that slip and then lets it be paid through a bank app, an ATM, an agent counter, or a mobile wallet. For an integrator the interesting data is not the payment button — it is the lifecycle around that PSID: what it is for, which department raised it, how much is owed, whether it is still valid, and whether it cleared. We integrate that lifecycle under the account holder's authorization and hand you working code or a hosted endpoint.

The bottom line first. The data worth integrating here is structured and per-transaction, and it sits behind a citizen or business account and the PITB portal rather than any open feed. The route we actually run on this app is authorized protocol analysis of the PSID generation and status calls, carried out against a consenting account, with the per-department receipt records normalized for you. The paragraphs below name the surfaces, the route choices, and what we plan for when PITB changes the portal.

What ePay Punjab holds, surface by surface

These are the surfaces the app and its companion portal expose to a logged-in user. Granularity is given the way ePay Punjab itself frames the records, drawn from the department list in its store description.

Authorized ways into the PSID and receipt records

Three routes genuinely apply to this app, and a fourth is worth watching but not yet usable. None of them depends on the citizen sharing a banking password — the PSID and its status sit in the payment portal, not inside a bank.

Protocol analysis of the PSID and status calls

We observe how the app and the epay.punjab.gov.pk portal generate a PSID and query its state, document the auth and token chain that guards those calls, and rebuild them as a clean client. This reaches the PSID lifecycle, the per-department amounts, and the cleared/uncleared flag. Effort is moderate; durability is good as long as we account for portal changes. Onboarding — a consenting account to test against — is arranged with you during the build.

User-consented account access

For a full history rather than a single slip, a citizen or business signs in to their own account and authorizes the pull. This is how we reach the payment-history surface and anything scoped to one taxpayer. It is the dependable legal basis in Pakistan today, because the consent is the account holder's own.

Native receipt capture

ePay Punjab produces printable PSID slips and paid-receipt documents. Where a structured query is not warranted, we parse those artifacts into records. It is the lightest option and a useful backstop when a department surface is read-only.

Regulated open-banking consent — forward-looking

The State Bank of Pakistan launched a regulatory sandbox in 2025 with open banking as one theme, and a few firms are testing inside it. There is no mandatory account-information rail to consume yet, so we do not build on this today; the design simply stays ready to re-point if one is finalized.

Which route leads is an easy call here. The records most teams want — what a PSID covers, how much is owed, whether it cleared — are transaction-scoped and resolve without anyone signing in, so analysing the status calls earns most of the value by itself. A consenting account matters only when someone needs a full per-taxpayer history, and reading printed receipts covers the occasional department screen that stays view-only. That order follows the data on ePay Punjab: the highest-value records are tied to the transaction, not the account.

A PSID status lookup, sketched

The shape below is illustrative — field names are confirmed during the build, not guessed here — but it shows how a status query reads once the auth chain is mapped. A PSID is the only required input; everything else comes back resolved.

# Resolve a single 17-digit PSID. Token comes from the app
# login/refresh chain mapped during protocol analysis.
POST /epay/psid/status
Authorization: Bearer <session-token>
Content-Type: application/json

{ "psid": "12345678901234567" }

# 200 OK  (field names illustrative, normalized on delivery)
{
  "psid":        "12345678901234567",
  "department":  "Excise & Taxation",
  "service":     "Token Tax",
  "amount_due":  "9650.00",
  "currency":    "PKR",
  "status":      "UNPAID",          # UNPAID | PAID | EXPIRED
  "generated_at":"2026-06-12T09:14:00+05:00",
  "expires_at":  "2026-06-26T23:59:59+05:00",
  "paid_channel": null              # set once SBP/1Link reports clearing
}

# Handling we wire in:
#  - EXPIRED  -> re-generate before showing "pay now"
#  - 429      -> backoff; the portal rate-limits status polling
#  - PAID but paid_channel null -> hold, reconcile before ledger write
      

What lands in your repository

The handoff is built around the surfaces above, not a generic template. For ePay Punjab that means:

• An OpenAPI specification covering PSID generation, status resolution, and the normalized receipt record.
• A protocol and auth-flow report: the login, token issue and refresh chain that fronts the status calls, written so your engineers can maintain it.
• Runnable source for the key endpoints in Python and Node.js — PSID lookup, history pull under consent, and the reconciliation check against the settling channel.
• A normalizer that folds Excise, Police-challan and Board-of-Revenue fields into one record with a department tag.
• Automated tests against recorded fixtures, so a portal change shows up as a red test rather than a silent gap.
• Interface documentation and data-retention notes covering consent records and what is kept versus discarded.

Where teams wire this in

• A fleet operator polls outstanding token tax and traffic challans across its registered vehicles and shows them in one screen instead of checking each plate by hand.
• An accounting tool reconciles a business's government payments — sales tax on services, business registration fees — against their PSIDs and the channel that cleared them.
• A bank or wallet embeds PSID generation and status so customers settle dues in-app and the institution confirms clearing without a manual check.
• A property firm automates e-Stamping and mutation-fee lookups through the Board of Revenue surface during a transfer.

What we plan for on this build

A few things about ePay Punjab shape the work, and we handle each as part of the engagement rather than handing you a checklist.

• PSID validity windows. A slip expires, and a stale status reads as payable when it is not. We design the sync to re-resolve a PSID before it is shown as actionable, so an expired slip is regenerated instead of presented.
• Twenty-plus department schemas. An Excise token-tax record, a Safe City challan and a Board-of-Revenue stamp fee do not share fields. We map each onto one normalized record up front so your consumers never branch per department.
• Settlement across mixed channels. The same PSID can clear through a bank, an ATM, an agent, or JazzCash and Easypaisa. We reconcile the reported settlement against the channel before flipping status, which keeps a ledger from marking a due paid early.
• Portal front-end churn. PITB updates the portal and adds departments over time. When it does, we re-run the capture against the changed screens as routine upkeep, and the test suite flags what moved.

Access needed for any of this — a consenting account, a test environment — is arranged with you during onboarding. Compliance runs through the whole job: authorized and documented access only, logged consent, data minimized to what the integration needs, and an NDA where the engagement calls for one.

Authorization and Pakistan's payment rules

Pakistan does not yet have a mandatory account-information regime to consume, so the dependable basis here is the consenting account holder's own authorization, paired with documented protocol analysis. The State Bank of Pakistan supervises payment systems under the Payment Systems and Electronic Fund Transfers Act of 2007, and in 2025 it opened a regulatory sandbox whose themes include open banking; per Open Banking Expo, the first cohort named only a few open-banking participants, testing under controlled conditions. That is a pilot, not a rail you can integrate against, which is why we build on consent today and keep the design ready to move if a formal data-sharing standard lands. On the data side, we operate to data minimization and logged consent as a matter of practice; Pakistan's general personal-data-protection statute remains in draft and is not asserted here as settled law.

The screens we worked from

Store screenshots used while mapping the flows. Select one to enlarge.

Other Pakistani government and wallet apps nearby

Teams integrating ePay Punjab usually touch the wider Pakistani payment and government-services ecosystem. These are named for context, not ranked.

• ePay Sindh — Sindh's government payment aggregator, built with PITB as technology partner; the same P2G and B2G receipt model in another province.
• Tax Asaan — the Federal Board of Revenue's app for filing returns and federal tax payments; complementary federal data alongside Punjab's provincial dues.
• JazzCash — a mobile wallet that settles ePay Punjab PSIDs; holds wallet balances and a transaction history of its own.
• Easypaisa — a wallet and digital bank widely used to clear government dues; per-user balances and payment records.
• Zindigi — the JS Bank digital app whose account holders can pay tax through ePay Punjab; account and transaction data behind login.
• NADRA e-Sahulat — a branchless-banking and bill-payment network handling fees and remittances at agent counters.
• Passport Fee Asaan — the Immigration and Passports directorate's fee calculation and payment app; another government receipt flow.
• 1Bill — the 1Link bill-aggregation service embedded in most Pakistani bank apps, carrying voucher and invoice records.

How this brief came together

Checked in June 2026 against the app's own store listing and the operators' pages, plus current reporting on Pakistan's open-banking status. The PSID model, the department list, the package identifier com.pitb.ePayGateway and the SBP/1Link backend are taken from those sources rather than asserted; figures and identifiers are attributed where they appear.

• ePay Punjab on Google Play
• epay.punjab.gov.pk — official payment portal
• PITB — e-Payment Gateway
• Open Banking Expo — SBP regulatory sandbox first cohort

Mapping by the OpenBanking Studio integration desk, June 2026.

Questions integrators ask about ePay Punjab

Is the 17-digit PSID enough to query a payment, or do you need the citizen account too?

The PSID identifies one transaction, so amount, department, validity and paid/unpaid status all resolve from it on their own. You only need a consenting account when you want a whole citizen or business history — every receipt that person has generated — rather than a single slip.

Can receipts from Excise, Punjab Police challans and the Board of Revenue come back in one shape?

Yes. Each department names its fields differently — token tax is not shaped like an e-Stamping fee or a Safe City challan — so we map all of them onto one normalized record with a department tag. Your code reads one schema instead of branching per department.

Does Pakistan's open-banking sandbox change how this gets built?

Not yet in a way you have to wait on. The State Bank of Pakistan opened a regulatory sandbox with open banking as one theme, but it is still a pilot with a handful of named participants. Today the dependable basis is the consenting account holder's own authorization plus documented protocol analysis; if a mandatory data-sharing rail is finalized later, we re-point the same integration onto it.

How do you confirm a due actually settled when it could clear through 1Link, a bank, or a wallet?

A PSID can be paid through several channels — bank app, ATM, over the counter, JazzCash or Easypaisa — so we reconcile the settlement event reported against the channel back to the PSID and flip its status only once they agree, which keeps your ledger from marking a due paid early.

Working with us

Source for ePay Punjab lands in your repository, and you pay only after you have run it and you are satisfied — from $300 for that delivery. If you would rather not host anything, our pay-per-call endpoints bill per request with nothing upfront. Either way the build runs one to two weeks. Tell us the app and what you want out of its data, and we arrange the access and the compliance side with you — start at our contact page.