Platform Evolution
Assessment run-2026-07-27-1 · 213 of 213 repos assessed
Repos / payment-check-service

payment-check-service

Fraud/risk decisioning API that checks payments against booking data, business credit checks and whitelists before they are accepted.

95 · greenlowlooseOn-premZDD: no excuseapi

Health score

95

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.


Runtime currency / 25
25
Runs on supported modern .NET
Legacy transport / 15
15
No legacy WCF or SOAP surface
Test posture / 15
15
Good test coverage
Security hygiene / 15
15
No credentials found in source
Dangerous coupling / 15
15
No dangerous coupling detected
Activity / 10
5
No commit in over a year
Deployment hygiene / 5
5
CI in place
Health over time
2026-07-24 (run-2026-07-24-1): 952026-07-27 (run-2026-07-27-1): 95
No change since 2026-07-24 (95 to 95).

Facts

Languagescsharp, sql
FrameworksASP.NET Core 8, Dapper, Serilog
Runtimes.NET 8
Tests / CIgood / CI in place
Last commit2025-07-08
OwnerOwner unknown (mapping to be curated)
DomainPayments and finance (system generated; curate in repo-owners.json to override)
Product areaShared platform
HostedOn-prem Deployed to our own machines
  • Release "\finance\backoffice\payment-check-service CI": QA: deployment-group phase (agents on our own machines)
  • Release "\finance\backoffice\payment-check-service CI": Staging: deployment-group phase (agents on our own machines)
  • Release "\finance\backoffice\payment-check-service CI": Training: deployment-group phase (agents on our own machines)
  • Release "\finance\backoffice\payment-check-service CI": Production: deployment-group phase (agents on our own machines)
  • Release "\finance\backoffice\payment-check-service CI": DR: deployment-group phase (agents on our own machines)
Releases2 release pipeline(s): \finance\backoffice\payment-check-service CI; \finance\backoffice\payment-check-service DB
Integrationrest
SourceOpen in Azure DevOps

Risk flags

Each flag links to its glossary definition.

Dependencies in context

Laying out the graph…
greenamberreddata store (square, dashed link)Node size follows fan-in. Click any node to open it.

Entanglement

loose No binding mechanisms apply: this system needs no untangling work.

    Depends on / used by

    Used by (0)
    No internal dependents.

    Data stores
    sqlserver:PaymentCheck

    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 excuse

    Nothing 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. Modern runtime, good tests, no hosted legacy transport: the automated stealth path can carry it today.

    Steps
    1. Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
    2. 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.
    3. Audit serialized data: anything in Redis, queues or shared caches must deserialize cleanly across adjacent versions.
    4. Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
    5. Route deployments through the Workflow Engine's automated drain, deploy, health-check, return cycle (the path proven by the first automated production run in mid-2026).
    6. 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

    Feasible now (1 owned database)

    The database is solely owned by this system, so the migration is self-contained. Recommended target: PostgreSQL.

    Steps
    1. Inventory the schema and query surface of sqlserver:PaymentCheck: tables, stored procedures, triggers, cross-database joins and anything else engine-specific.
    2. Confirm the target: PostgreSQL (relational model; keep transactions and joins, swap the engine).
    3. Data access is not through an ORM, so port the SQL by hand: translate T-SQL constructs, replace stored procedures with application code or target-native equivalents, and add integration tests around the queries that matter first.
    4. Stand up the target alongside SQL Server, backfill with an ETL pass (pgloader or an export/import job), then dual-write or replicate until parity is proven.
    5. Move reads to the target, watch correctness and latency, then cut writes over and keep SQL Server read-only until confidence is earned.
    6. Decommission the SQL Server database and remove the connection strings and firewall paths that pointed at it.

    Containerisation

    Ready to containerise

    Modern runtime, no hosted legacy transport: this service can follow the estate's proven container path (Dockerfile, shared pipeline template, ECS via Terraform).

    Steps
    1. Add a Dockerfile and make the app read all configuration from environment variables and the secrets manager, never from machine-local files.
    2. Log to stdout and expose a health check endpoint so ECS can supervise it.
    3. Adopt the shared ci.yml pipeline template with the container parameters (awsRegion, containerAfterBuild, ecsTerraformRepo), which is exactly how the estate's existing AWS services deploy.
    4. Define the service in the Terraform repo, deploy to a non-production environment, then shift traffic and disarm the deployment-group release pipeline.

    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

    payment-check-service

    Purpose

    Central payment-check API: callers submit payment context (salesperson, booking, business ids) and get a decision. Sub-checks include booking checks, business-travel credit checks and a whitelist. Ships a NuGet client (TC.PaymentCheck.Client) for consumers.

    Tech stack

    ASP.NET Core Web API on .NET 8 with API versioning, Swashbuckle and Serilog. Domain/logic split into per-check projects; data access via Dapper. Client library multi-targets net462;net472;net481;netstandard2.0;net8.0 for legacy consumers. SSDT database project (db/PaymentCheckDatabase).

    Deployment

    Two build pipelines (payment-check-service CI, payment-check-service DB) matching in-repo build.yml and build-db.yml, releasing via \finance\backoffice\payment-check-service CI and ...DB; release_count 2. App and database deploy independently.

    Dependencies

    Internal: TC.ConnectionBroker.* (tc-connectionbroker) for SQL/HTTP/WCF connections, TC.Exceptions.* (tc-exceptions), and the business-travel credit check client TC.BusinessTravel.CreditCheck.WebApiClient (backoffice-bt-credit-check). Also references TC.Phenix.Services.Client for Phenix service access. No external third-party services identified.

    Data stores

    SQL Server PaymentCheck database (whitelist, sub-service check results), connection resolved via ConnectionBroker; schema in an SSDT .sqlproj.

    Integration points

    REST API consumed by payment-taking apps via the published client package; outbound REST/WCF calls to internal TC services through ConnectionBroker.

    Code health

    Four test projects covering API, WebApi and the credit-check/whitelist logic — good coverage relative to size. StyleCop and rulesets enforced. CI present. Last commit 2025-07-08.

    Modernisation risks

    Low risk overall: current .NET 8 runtime, tested, SSDT-managed schema. Main drag is the client package multi-targeting down to .NET Framework 4.6.2, which exists to serve legacy consumers and constrains client-side dependency upgrades.