N-BOSS logo N-BOSS

NBOSS White Paper

eBOSS platform architecture, transaction lifecycle, and operational controls

A unified operating layer for LGU permits, taxes, violations, collections, and reporting

This white paper describes NBOSS as an operational platform for application intake, office review, payment collection, transaction posting, and management visibility. It is informed by the current Laravel implementation, database schema, route structure, and payment integration patterns in production code.

Documentation for LGU stakeholders, implementers, and technical reviewers

Platform role eBOSS operations
Portals Staff + citizen
Collection model Onsite + online
Ledger Centralized history

1. Platform overview

Role in local government digital service delivery

NBOSS (Novulutions Business One Stop Shop) operates as an eBOSS-style application platform that connects citizen-facing submissions, back-office processing, approval checkpoints, payment modules, and operational reporting. The system is implemented as a Laravel application with web routes for full workflows and API routes for dashboards, lookups, and authenticated JSON access.

Unlike a standalone form portal or a payment-only widget, NBOSS maintains service-specific application records, per-service payment tables, approval queues, and a centralized transaction ledger used for reconciliation and dashboard metrics.

Core platform functions

  • Multi-service application intake for permits, taxes, clearances, violations, and inspections.
  • Role-based staff and citizen portals with module-level read/write permissions.
  • Application approval workflows with pending, returned, declined, and approved states.
  • Onsite cashiering and optional online payment via NovuPay (redirect + webhook).
  • Transaction history posting with fee breakdown lines for reporting and audit.

2. System participants

Distinct roles in service and payment processing

Citizens and applicants

Submit applications through the citizen portal, track status, pay approved services (walk-in or online when enabled), and view transaction history.

LGU staff and administrators

Encode and validate applications, manage approvals, process payments at counters, and access dashboards and reports based on assigned permissions.

Reviewers and inspectors

Perform technical or compliance review for applicable services before final approval, including checklist-driven approval actions.

Finance and treasury teams

Post collections, validate amounts, manage payment breakdowns, and reconcile against centralized transaction history.

Payment gateway partner

When configured, NovuPay hosts checkout, returns redirect status, and sends signed webhooks that update payment records in NBOSS.

External reporting systems

Optional eBT-style payload uploads can transmit completed transaction data to upstream receivers per deployment contract.

3. Service transaction lifecycle

From application intake to posted ledger entry

The end-to-end service lifecycle mirrors operational reality in LGU offices: intake, validation, approval, collection, posting, and reporting. Application approval routes and payment modules implement this pattern across all enabled services.

Citizen / staff entry
Service submission
Pending queue
Review / inspector
Final approval
Payment
Ledger posting
Dashboards & reports
Step 1

Application initiation

A citizen or staff user creates a service record through the appropriate module (cedula, RPT, permits, clearances, violations, FSI, etc.).

Step 2

Validation and queueing

The application enters a pending state for encoding, document checks, and routing to the responsible office or reviewer.

Step 3

Approval action

Authorized users action applications (approve, decline, return) through the application approval module, including checklist capture where required.

Step 4

Payment readiness

Approved applications become eligible for payment. Amounts and application codes are exposed to cashiering or online checkout flows.

Step 5

Collection

Payment is recorded in the service payment table as onsite (cash/walk-in) or online (gateway), updating status to paid when confirmed.

Step 6

Ledger and visibility

Transaction history and breakdown entries are created. Dashboard APIs aggregate counts and revenue by service for staff; citizens see their own overview.

4. Payment routing and collection

Onsite cashiering and optional online orchestration

NBOSS supports dual collection channels. Onsite workflows use service payment modules operated by authorized staff. Online collection uses NovuPay payment request creation, customer redirect to hosted checkout, return URL handling, and webhook-driven status updates with optional HMAC verification.

Onsite (walk-in) collection flow

Approved application
Treasury / cashier module
Payment posted (paid)
Receipt / printable
Transaction history

Online payment flow (NovuPay)

Pay Now / payment form
POST /eboss/payment/hitpay
NovuPay checkout
Redirect callback
Webhook (HMAC)
Payment + ledger update
Citizen
Initiates payment with application code + amount
NBOSS
NBOSS
Creates payment request via NovuPay API
NovuPay
NovuPay
Customer authorizes payment
Bank / wallet
NovuPay
Webhook: status completed → mark paid → post history
NBOSS

5. Ledger and reporting framework

Centralized operational ledger for reconciliation and dashboards

Financial visibility in NBOSS is anchored on transaction_history and transaction_history_breakdowns. Dashboard controllers aggregate this ledger by service name, month, and year—aligned with enabled modules in system_modules where type is services.

Service modules

Cedula, RPT, permits, clearances, violations, FSI — application + payment tables per service

transaction_history

Application code, OR, amounts, payment type, service name, status, timestamps

transaction_history_breakdowns

Line-item fee components linked to each posted transaction

Dashboards & manage reports

Overview, revenue streams, comparisons, top revenue, citizen overview APIs

Reporting outputs

  • Staff dashboard: percentage, compared years, revenue streams, top revenue, overview (admin-gated APIs).
  • Citizen dashboard: per-service pending and paid counts for the authenticated citizen.
  • Transaction history and payment breakdown modules for operational review and export workflows.

6. Payment and external integrations

Gateway connectivity and optional upstream transmission

NovuPay integration endpoints are exposed at POST /eboss/payment/hitpay, GET /eboss/payment/hitpay/redirect, and POST /eboss/payment/hitpay/webhook. Webhook processing verifies HMAC when configured, locates payment records by application code across service payment models, updates status to paid, and triggers transaction history creation for supported services.

Deployments requiring upstream reporting can use the eBT API payload contract documented in ebt_api.md for business permit, cedula, and RPT transaction uploads.

7. System architecture

Application and data structure

Presentation layer

Blade views for staff (/eboss/...) and citizen (/eboss/citizen/...) portals, plus public landing and white paper pages.

Application layer

Controllers, services (transaction history, printable, reports), middleware for setup gate, roles, and API auth.

Data layer

Per-service tables, payment tables, users/roles/permissions, organizations, setup config, support tickets.

CedulaRPTBarangay clearanceBusiness permit Building permitOccupancyParking ticketEnvironment ticket Fire safety inspectionTransaction historyApplication approval

8. Security and access controls

Governance, permissions, and integration integrity

  • Spatie role/permission model with per-module read and write gates on routes.
  • Setup middleware redirects incomplete deployments to initial configuration before module access.
  • Separate dashboard API policies for staff (auth.api) and citizens (auth.api:citizen).
  • NovuPay webhook HMAC verification when salt is configured; structured logging of payment events.
  • CSRF protection on web forms; webhook route excluded from CSRF for processor callbacks.

9. Risk management framework

Operational, security, and integration risk controls

Operational risk

Mitigated through approval queues, status tracking, and centralized transaction history for dispute resolution.

Access risk

Least-privilege module permissions for finance, review, cashiering, and administration functions.

Integration risk

Gateway failures logged; webhook signature validation; graceful handling when payment tables are unavailable.

Data integrity risk

Breakdown lines tied to transaction history; citizen_id backfill on ledger for citizen-scoped reporting.

10. Operational resilience

Continuity during disruptions

Service continuity depends on reliable approval workflows, payment partner uptime, and accurate ledger posting. NBOSS supports operational recovery through transaction logs, webhook retry tolerance at the gateway layer, and manual onsite collection when online payment is unavailable.

Incident response should follow: detect (logs/alerts), classify severity, contain (disable affected module or gateway), restore service, reconcile affected transactions against transaction_history, and document root cause for governance review.

11. Platform role summary

eBOSS positioning in one view

NBOSS, in summary

  • Unifies LGU permit, tax, clearance, violation, and inspection workflows in one platform.
  • Supports staff and citizen portals with role-based operational controls.
  • Routes collections through onsite cashiering and optional NovuPay online checkout.
  • Posts transactions to a centralized ledger for reconciliation and dashboards.
  • Integrates with external payment and reporting partners without replacing LGU policy and approval authority.

Ready to evaluate NBOSS for your LGU?

Prepare phase-1 services, approval structure, payment channels, and reporting requirements for a rollout design workshop.

Register as citizen Staff login Back to home