payments-portal
StencilJS single-page payments portal for customer payment links, hosted as static assets on AWS S3/CloudFront with runtime JSON config and white-label theming.
Health score
0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.
Facts
| Languages | typescript |
| Frameworks | Stencil 4, Tailwind CSS 4 |
| Runtimes | nodejs |
| Tests / CI | some / CI in place |
| Last commit | 2026-05-19 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Payments and finance (system generated; curate in repo-owners.json to override) |
| Product area | Shared platform |
| Hosted | AWS Deployed to AWS
|
| Releases | 0 release pipeline(s): |
| Integration | rest |
| Source | Open in Azure DevOps |
Dependencies in context
Entanglement
loose No binding mechanisms apply: this system needs no untangling work.
Depends on / used by
Migration playbooks
Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.
ZDD adoption
No excuseNothing technical is holding this repo on the three-week release. It either already deploys without downtime (AWS) or is a modern, well-tested service the automated stealth path can carry today. Already deploys as a container to AWS, which releases without downtime today. Separating it from the three-week release is a process decision, not a technical one.
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- Raise automated test coverage first: ZDD trades the end-of-sprint manual gate for continuous automated confidence, so the tests are the entry ticket.
- Make every change dual-version safe: backwards-compatible APIs (new major version for breaking wire changes), expand and contract for any schema change, and consumers tolerant of unknown fields.
- Externalise any remaining session state so users can move between nodes mid-session without disruption.
- Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
- Use ECS rolling deployments with health checks gating traffic, and take this service off the three-week release train.
- Verify with area-scoped regression rather than the whole-platform cycle, and watch error rates after rollout with automated rollback on alert.
SQL Server exit
Not applicableNo SQL Server dependency is recorded for this repo. Nothing to migrate.
Containerisation
Already containerisedIts pipelines already build containers and deploy to AWS. Nothing to do here.
Recommended actions
No specific actions for this repo. It either needs only normal maintenance, or its work is covered by an estate-level action. See the full programme.
Assessment notes
payments-portal
Purpose
A small StencilJS single-page application that renders generated payment links for customers: it resolves a paymentLinkId from the URL, fetches payment-link details from a payment-link API, and embeds the shared payment-components payment form to take the payment. Branding is hostname-driven at runtime, with themes for Travel Counsellors and The Travel Agent Next Door (white-labelling).
Tech stack
TypeScript on Stencil 4 with Tailwind CSS 4 (PostCSS), ESLint and Jest/Stencil spec tests. Environment-specific values come from /config/runtime-config.json at runtime rather than being baked into the build; the starter config includes per-environment payment-components URLs (qa/stg/prod payments.travelcounsellors.io) and a standalonePayment test harness.
Deployment
Included via build->yaml-deploy with 0 classic releases: build pipeline payments-portal from the in-repo build.yml, using the shared InternalOSS/azure-pipelines-templates ci.yml (node 20.x, aws configuration). Artifacts go to the tc-payments-ui-artifacts S3 bucket and are served via a cloudfront_spa Terraform template from the aws-payments-tc-apps repo, functional area payments. No on-prem release pipeline.
Dependencies
Internal: loads the payment-components web component (portal-payment-wrapper) from environment-specific URLs at runtime, and calls a payment-link REST API (apiBaseUrl; the README notes this API did not yet exist, hence the standalone test path with a payment-router initiateToken). Only @stencil/core as a production npm dependency; everything else is dev tooling.
Data stores
None — a stateless static SPA. All state comes from the payment-link API and runtime config; build artifacts live in the tc-payments-ui-artifacts S3 bucket (deployment artifact, not an application data store).
Integration points
Outbound REST to the payment-link API (with a mockMode fallback baked into the local config) and runtime script-loading of payment-components for the embedded payment form; no auth flows of its own beyond what the payment component handles.
Code health
Small, tidy, recent codebase with three Jest spec files (payment-link service, brand theme, app component), a genuinely useful README and dedicated docs for AWS hosting, white-labelling and payment-components integration. Last commit 2026-05-19.
Modernisation risks
Low — modern Stencil/TypeScript, YAML CI, AWS-native hosting. The main caveat is that it was built ahead of its backing payment-link API (mockMode: true and a standalone token-paste path in the checked-in config), so it is an in-flight capability whose real integration surface is still settling; theming/config correctness across white-label hostnames is the other thing to watch.
Data store follow-up (2026-07-28)
Follow-up scan of project files, configuration and the central Terraform repos confirmed the empty data_stores list is correct. Front-end portal; no data store packages or configuration found.