On this page
Platform overview
The Pamodzi e-Services framework (the GSB e-Services platform) is the Government of the Republic of Zambia's platform for delivering public e-services. Citizens and businesses find, apply for, pay for and receive every service through one national portal. The ministries, departments and agencies (MDAs) that own the services design and process them in their back offices.
The platform is one reusable product. The same code is deployed for every MDA, and a new MDA or a new service is set up by configuration, not by writing code.
The platform in numbers
The master test report of 21 October 2026 covers 421 live services owned by 45 MDAs, migrated from the legacy GSB platform. On that date every one of the 421 passed all five checks on the test installation: correct and full form, correct workflow, correct output documents, end-to-end test passed, and documentation with screenshots.
Two points help when you compare figures:
- The legacy portal lists 572 entries. Each local-council service appeared once per council there; on this platform
each council service exists once and the citizen chooses the council. Two legacy entries were events that have ended. That is why the count is 421.
- The five checks were made on a test installation with synthetic data. They show that the migration is complete;
they do not replace each MDA's own sign-off of its services.
The current state of every service is in the service catalogue.
Principles
| Principle | What it means in practice |
|---|---|
| One national portal | There is exactly one public portal, ZamPortal. It reads as one government portal, never as a set of ministry sites: no ministry-specific pages, menus or wording. Service-specific content comes from data |
| Services are configuration | A new service needs a form, a process, fees, required documents and output templates, designed in the back office. Code is written only when a genuinely new capability is missing, and then it is built for every MDA |
| The core is MDA-neutral | Core code, data, screens and wording never name a specific MDA. A check (npm run check:mda) enforces it |
| MDA features are modules | Functions that only one MDA needs live in optional modules, switched on per installation and per ministry |
| Federation | An MDA may run its own back office, API and database (a node). The national portal (the hub) relays applications, payments, status and verification to it |
| Security first | Every request is authorised on the server by one policy decision point. Personal data is minimised, masked and audited under the Data Protection Act No. 3 of 2021 |
| Evidence, not claims | Every service ships with an end-to-end test, and the same test run generates its documentation |
Components
| Component | Repository | Users | What it does |
|---|---|---|---|
| National public portal (ZamPortal) | public-portal-ui | Citizens, businesses, civic organisations | Find a service, sign in, apply, pay, track applications, hold licences and permits, verify a document. Built to work at 375 px width and on slow connections |
| Back office | back-office-ui | MDA officers, supervisors, executives, administrators | Process cases through their workflow, design services, manage registers, finance, modules and users |
| Platform API | zcm-backend | Both front ends, the POS app, other government systems | Node.js and Express with PostgreSQL and PostGIS. Holds the business rules, the policy decision point, the workflow engine, jobs and the federation contract |
| POS app | GSB-POS | Officers at counters and in the field | Android app for counter and field payments and document work |
| Identity | ZamPass today; Pamodzi Pass (being built) | Citizens and staff | OpenID Connect single sign-on. Pamodzi Pass will replace ZamPass; its switch-over is planned, not done |
| Payments | ZamPay integration in zcm-backend | Citizens, finance officers | Invoices, online payment, receipts, part payments, refunds and counter payments, posted to each service's revenue code |
| Documents and verification | zcm-backend signing service and verification | Anyone who must check a document | Output documents are sealed and carry a QR code. Anyone can check a document at the portal's verification page |
| National Data Registers | zcm-backend registers | Officers, partner systems, the public for public registers | Typed registers with field-level sensitivity, access grants, data-sharing agreements and open data |
| Geospatial (NGDR) | zcm-backend geo providers | Services that use areas or parcels | Reads layers from the National Geospatial Data Repository (WFS/WMS), validates geometry fields and draws static maps |
| Federation | zcm-backend /fed/v1 | Hub and MDA nodes | Signed, versioned messages between the national portal and MDA back offices |
| End-to-end kit | e2e | Developers and testers | Playwright journeys for every service, screenshots, generated documentation and the service status list |
| Developer Hub | Pamodzi-HUB | Developers, MDA staff, vendors | This site: guides, API reference, service evidence, training and access requests |
Key capabilities
Services as configuration
Each service has a service passport (who may apply, required documents, fees, processing time, validity and legal basis), an application form, a workflow process of steps assigned to roles, a fee schedule and output templates for the documents it issues. Officers design all of these in the back office. Changes are kept as versions, so an application stays tied to the form version it was made on.
The AI service builder in the back office drafts a service from an uploaded Act, Statutory Instrument or service charter: the form, the process and, optionally, the output-document templates. The draft is always reviewed by an officer before it is used. The AI features are switched off by default and each one is enabled separately.
Modules and extension points
A module is an optional bundle (its own tables, routes, policy rules, jobs and back-office screens) for functions that are not needed by every MDA. Examples are government rentals and leases, forestry licensing and co-operatives. A module is off by default; an administrator switches it on per installation and per ministry, under maker-checker. A switched off module answers 404 MODULE_DISABLED on every route, but its data stays and payments already started still finalise. Modules plug into core only through named extension points such as case.onSubmit or payment.quote.
Where a feature could serve more than one MDA, it is built as a reusable capability instead: the shop for any ministry that sells goods, the allocation and quota ledger, name reservation, inspections and the geometry field.
Federation
The same code runs in one of three roles: combined (hub and node in one installation), hub (the national portal) or node (one MDA's back office). Services are designed on the node that owns them. The hub receives the catalogue by federation sync and relays applications, status, payments and verification. Answers, notes and documents stay on the node. See Architecture.
Payments
Payments go through ZamPay. The platform raises an invoice, the citizen pays online or at a counter, and ZamPay's callback finalises the payment through one path. Part payments, refunds and voided receipts (with a reason) are supported. In a federation each node raises invoices on its own ZamPay merchant; the hub only shows them.
Documents and verification
Issued documents (certificates, licences, permits, letters) are generated from the service's templates, sealed by the platform's signing service and carry a QR code that leads to the verification page. A document is never issued as if it were sealed when sealing failed, and verification never overstates validity: an expired, suspended or revoked document says so. The hub answers verification questions for documents issued on any node.
National Data Registers
Registers hold reference data such as businesses, vehicles, land parcels and permits, typed by register packs that say how sensitive each field is. Access beyond a register's public view is given only through grants, and access for other organisations only through data-sharing agreements. See Registers and data sharing.
Policy decision point
One function in the API answers "may this user do this to this thing?". Every route names the policy action that guards it, and a test fails on any route that does not. See Security and data protection.
End-to-end tests and documentation
Each service has a Playwright journey that finds the service, signs in, applies with documents, pays through a test double, plays every officer step to the decision, and downloads and verifies the output. The same run captures screenshots (desktop, and 375 px for citizen steps) and generates the service's Markdown and Word documentation from one template. The service status list is generated from it and never edited by hand. Tests never call real ZamPay, ZamPass, SMS or signing services.
What is planned rather than built
- Pamodzi Pass as the only sign-in for the platform (the ZamPass bridge and switch-over are next on its roadmap).
- Several data-sharing items are documented but not built, such as register relays between two nodes. The guides say
so where it matters.
Next steps
- Architecture: roles, request paths and where data lives.
- Pamodzi e-Services Foundations: the course that covers this page in depth.