payment-check-service
Fraud/risk decisioning API that checks payments against booking data, business credit checks and whitelists before they are accepted.
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 | csharp, sql |
| Frameworks | ASP.NET Core 8, Dapper, Serilog |
| Runtimes | .NET 8 |
| Tests / CI | good / CI in place |
| Last commit | 2025-07-08 |
| 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 | On-prem Deployed to our own machines
|
| Releases | 2 release pipeline(s): \finance\backoffice\payment-check-service CI; \finance\backoffice\payment-check-service DB |
| Integration | rest |
| Source | Open in Azure DevOps |
Dependencies in context
Entanglement
loose No binding mechanisms apply: this system needs no untangling work.
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. Modern runtime, good tests, no hosted legacy transport: the automated stealth path can carry it today.
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- 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.
- Audit serialized data: anything in Redis, queues or shared caches must deserialize cleanly across adjacent versions.
- Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
- 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).
- 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.
- Inventory the schema and query surface of sqlserver:PaymentCheck: tables, stored procedures, triggers, cross-database joins and anything else engine-specific.
- Confirm the target: PostgreSQL (relational model; keep transactions and joins, swap the engine).
- 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.
- 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.
- Move reads to the target, watch correctness and latency, then cut writes over and keep SQL Server read-only until confidence is earned.
- Decommission the SQL Server database and remove the connection strings and firewall paths that pointed at it.
Containerisation
Ready to containeriseModern runtime, no hosted legacy transport: this service can follow the estate's proven container path (Dockerfile, shared pipeline template, ECS via Terraform).
- Add a Dockerfile and make the app read all configuration from environment variables and the secrets manager, never from machine-local files.
- Log to stdout and expose a health check endpoint so ECS can supervise it.
- 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.
- 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.