paymentprovider-dummy
Two .NET 6 fake payment-provider APIs (payments and payment-instruments) that stand in for real PSPs on test environments, letting testers control payment outcomes via magic card numbers and amounts.
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 |
| Frameworks | ASP.NET Core 6, MediatR 10, FluentValidation 11, Serilog |
| Runtimes | .NET 6 |
| Tests / CI | some / CI in place |
| Last commit | 2025-05-14 |
| 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.
- 3 system(s) depend on this repo; during a rolling deploy they will talk to old and new versions at once, so responses must stay compatible
- 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.
- 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.
- 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
Replatform paymentprovider-dummy to modern .NET
Runs on .NET 6, out of mainstream support. No pinning dependency blocks it; sequence by fan-in (providers before consumers).
Impact: Unblocks 3 dependent system(s)
proposedAssessment notes
paymentprovider-dummy
Purpose
A dummy PSP for the payments platform: TC.PaymentProvider.Dummy.API implements the standard provider surface (ecom and MOTO payments, token payments, refunds, 3-D Secure setup, payment status, token stores) and TC.PaymentProvider.DummyPaymentInstruments.API implements tokenisation (single-use tokens, saved cards) — the API the payment-components UI calls as dummy-instruments-api. Result-control conventions let testers force outcomes (e.g. card numbers ending 420 → "Not Enough Funds", amounts 333/666 for token payments), so payment flows can be tested end-to-end without third-party PSPs.
Tech stack
C# on .NET 6 across a layered solution (two APIs, a shared API project, Application, Common, DataAccess, Domain). MediatR 10 with a validation pipeline behavior, FluentValidation 11, Serilog, Microsoft.AspNetCore.Mvc.Versioning, Swashbuckle 6, TC.Diagnostics health checks, TC.Payments.Models/TC.Payments.Logging shared payment packages and TC.Persistence.DynamoDB for storage; Nerdbank.GitVersioning.
Deployment
No classic release pipelines (release_count 0); traced via build->yaml-deploy, build pipeline paymentprovider-dummy. build-containers.yml uses the shared InternalOSS/azure-pipelines-templates ci.yml (pinned .NET SDK 6.0.201) to container-build both APIs and deploy to AWS ECS in eu-west-1 via the aws-payments-tc-apps Terraform repo (useTFVarsDeployment: true, namespace finance-payments, functional area payments) — the same pipeline shape as the real provider adapters, even though the service itself targets test environments.
Dependencies
Internal: TC.Diagnostics.HealthChecks.AspNetCoreExtensions (tc-diagnostics-portal); the shared TC.Payments.Models, TC.Payments.Logging and TC.Persistence.DynamoDB packages map to no included repo with confidence (consistent with the paymentprovider-br-dge assessment). External: AWS (DynamoDB, ECS). Deliberately no real PSP integration.
Data stores
AWS DynamoDB tables DummyProvider.Tokens (provider tokens/saved cards) and DummyProvider.Payments (payment references) via TC.Persistence.DynamoDB.
Integration points
Inbound REST only — called by the TC payment router and the payment-components dummy provider. No outbound integrations, buses or queues.
Code health
Two xUnit test projects (~42 tests) covering command handlers and validators with AutoFixture/NSubstitute/coverlet, but no API-level tests. Short, useful README documenting the result-control card-number conventions. Frozen since 2025-05-14.
Modernisation risks
Medium, driven entirely by the runtime: both APIs target .NET 6 (out of support since November 2024) with a pipeline-pinned 6.0.201 SDK, and its sibling providers (br-dge, stripe) have already moved to .NET 8 — an upgrade here is low-effort and low-risk. Blast radius is limited since it serves test environments, but it sits in the same finance-payments ECS namespace and shares the provider contract, so letting it rot would eventually break payment-platform testing.