Context
This is a deployed facility application with a public registration flow. Users select facilities and duration, provide personal details, complete payment information, upload supporting material and review the application before submission.
Business problem
Paper forms, separate payment records and manual access lists make facility registration slow to reconcile and difficult to audit. Members need a clear enrolment journey, while operators need reliable access and attendance records.
Users and roles
Applicants need a clear step-by-step registration journey; reception staff need fast QR check-in feedback; authorised administrators need application review, reporting and exception handling; support teams need traceable diagnostics.
Requirements
- Guide applicants through facility, personal detail, payment, upload and review stages
- Keep personally identifiable data out of QR payloads
- Support role-based access and revocation
- Provide a clear audit trail
- Remain usable across desktop and smaller screens
Solution
A staged React application keeps registration choices and costs understandable before submission. The access flow exchanges an opaque QR token for a server-side decision, while the ASP.NET Core API owns authorisation, validation, payment state and audit events.
Technology
Implemented technology
- ASP.NET Core
- React
- PostgreSQL
Planned for a future version
- Azure
- OpenID Connect
Architecture
A server-rendered web shell loads the scanner only when required. The API separates identity, access policy and reporting modules. PostgreSQL stores transactional data; append-only audit events support investigation without becoming the operational source of truth.
Security considerations
- Short-lived, single-purpose QR tokens
- Least-privilege roles enforced in the API
- Rate limiting and replay detection
- Encrypted transport and managed secrets
- Retention rules for access and audit records
Accessibility considerations
- Keyboard-operable administration flows
- Status communicated with text and icons, not colour alone
- Clear focus order and error summaries
- Touch targets sized for reception tablets and phones
Key decisions
- Prefer online authorisation for final access decisions
- Use opaque tokens rather than encoded personal data
- Log decision reasons without recording unnecessary sensitive data
- Keep recovery workflows explicit for support staff
Trade-offs
- Online authorisation improves revocation accuracy but depends on connectivity
- Detailed audit events aid support but require strict retention and access controls
- A focused scanner interface reduces errors but moves advanced controls into separate administration screens
Current status
This project is currently live. The public link opens the authenticated application; access to operational features remains restricted to authorised users.
Challenges
The central trade-off is speed versus assurance. A scan must feel immediate, but cached or offline decisions can become unsafe when access is revoked.
Outcomes and measurement
The deployed application brings registration stages, facility selection and access administration into one workflow. Future measurement can focus on application completion, payment exceptions, failed-scan reasons, support volume and audit completeness without inventing performance claims.
Lessons learned
Operational exceptions deserve first-class design. Incomplete applications, payment issues, expired codes, duplicate scans and temporary outages need understandable recovery paths, not generic error messages.