# SLT One — enterprise subscription operations demo

SLT One is a dependency-free, full-JavaScript reference implementation for consumer onboarding, digital KYC, recurring subscription billing and telco fulfilment. It includes a responsive customer portal and a dense operations console designed for large-scale SLT workflows.

## Run locally

```bash
npm start
```

Open `http://localhost:4173`. The app starts in the SLT operations console; use **Customer portal** in the top-right to switch views. No installation is required beyond Node.js 20+.

Sandbox OTP for both SMS and email: `482913`.

```bash
npm test
cp .env.example .env
npm run check:env
```

The browser demo intentionally runs with sandbox adapters. It never sends an uploaded identity image or payment credential to an external service. Set `INTEGRATION_MODE=live`, supply every environment variable, and connect the adapters in `src/integrations.js` only in an authorised environment.

## Included workflows

- New and existing-customer onboarding. Existing customers link their current SLT telephone/account number and reuse a verified KYC profile.
- Mandatory mobile and email OTP challenges, including expiry and attempt limits.
- Front-and-back NIC capture, simulated Sinhala/Tamil/English OCR, confidence and tamper checks.
- Editable OCR-extracted permanent address and separate current/installation address.
- Precise map pin/current-location interaction, coverage check, DP assignment, distance, capacity, technology and install estimate.
- Ready-made Fibre/voice/PEOTV packages plus a compatible advanced multi-service configuration.
- Multiple customer connections, each with one or more services.
- Immediate plan changes with prorating and simulated AAA/IN confirmation.
- Local-bank recurring mandate UX modelled on tokenised subscription billing.
- SLT operations overview, SLA queue, activation funnel, throughput, integration health, provisioning, coverage, billing, monitoring, reporting and configuration workspaces.
- Stage-by-stage operations review drawer with KYC evidence, customer/contact verification, DP feasibility, ownership, operational notes, exception routing and audited forward transitions.
- Customer 360, provisioning execution journal/retry, capacity forecasting, recurring collections/dunning, incident topology, governed reports and versioned automation configuration—all with purpose-built content.
- Complete Self Care areas for service/add-on management, live usage and line controls, itemised invoices and AutoPay, support diagnostics/tickets, and verified profile/security preferences.
- REST API, idempotency-oriented order model and three ordered PostgreSQL migrations.

## Production architecture

The demo server uses in-memory seeded data to stay instantly runnable. The migrations define the production PostgreSQL/PostGIS model. At scale, deploy stateless Node API replicas behind a gateway and move work off the request path:

```text
Web / mobile clients
        │
 API gateway + WAF ─── stateless Node API pods ─── PostgreSQL read/write pool
        │                       │                            │
        │                       ├── Redis OTP/rate limits   ├── PostGIS DP lookup
        │                       └── transactional outbox ───┘
        │                                      │
        └── webhooks ◀── event bus / workers ──┼── OCR + object storage
                                               ├── SMTP / SMS
                                               ├── local bank subscriptions
                                               └── SLT CRM / AAA / IN / PEOTV / field force
```

The schema includes geographic indexes for nearest-DP queries, partial indexes for active queues, idempotency keys, unique external-operation guards, a transactional outbox, retry scheduling and partitioned audit logs. Those controls keep customer requests fast while integrations are processed independently and safely retried. Autoscale API and worker pools on latency and queue depth; partition large order/audit tables by time; use read replicas for reporting; keep KYC documents in encrypted object storage rather than PostgreSQL.

## Security and compliance boundaries

- Encrypt NIC values and identity documents with a managed KMS; rotate keys and purge objects after the configured retention period.
- Store only bank tokens/mandates and card `last4`; never PAN/CVV or online-banking credentials.
- Hash OTP destinations/codes, rate-limit by customer/device/IP and require step-up verification for sensitive changes.
- Put admin access behind SLT SSO, MFA and role/region-scoped authorisation. Audit every read and mutation of KYC data.
- Verify bank and SLT webhooks using timestamped signatures, replay protection and idempotency keys.
- Complete SLT security, data-protection, PCI DSS and regulatory review before connecting live systems. The sample catalogue is illustrative and prices are shown exclusive of tax.

## Repository map

```text
public/                 Customer and admin SPA
server.js               Node HTTP API and sandbox adapters
src/integrations.js     Live SMTP, SMS, bank and SLT integration contracts
migrations/             PostgreSQL/PostGIS schema and workflow migrations
scripts/check-env.js    Strict environment validation
tests/                  API behavior tests
```

## Current SLT catalogue reference

The demo package names, Fibre tiers, multi-play composition and prices were aligned to SLT’s public product pages in September 2026. Product catalogue data must still be sourced from SLT CRM/product management in production rather than hard-coded.