paymentprovider-stripe
ASP.NET Core 8 adapter API integrating TC's payments platform with Stripe — payment links with dynamic products/pricing, ecom/MOTO payment intents, refunds, 3-D Secure and webhook notifications — following the BR-DGE provider conventions.
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 8, Mediator (source-generated), FluentValidation 12, Stripe.net 50 |
| Runtimes | .NET 8 |
| Tests / CI | good / CI in place |
| Last commit | 2026-05-11 |
| 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 |
Risk flags
No risk flags recorded.
Each flag links to its glossary definition.
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.
- 1 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.
- 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
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
paymentprovider-stripe
Purpose
The Stripe adapter in TC's payment-provider family (alongside br-dge, pcipal, dummy): controllers for client keys, ecom and MOTO payments, hosted payments, payment links (create/update/get/list, with dynamic Stripe product and price creation, custom unit amounts and metadata), transactions/refunds, 3-D Secure and a NotificationController that unwraps and signature-verifies Stripe webhooks. Payment links back the payment-link-wrapper/Stripe provider components in payment-components, e.g. for the payments-portal customer payment pages.
Tech stack
C# on .NET 8 (Api, Application, DataAccess, Models, ResponseMappers projects). Source-generated Mediator 3 (not MediatR), FluentValidation 12, Stripe.net 50 against api.stripe.com, Asp.Versioning, Swashbuckle 8, Scrutor, Serilog-style logging via TC.Payments.Logging/TC.Payments.JsonMessageTransport.WebapiLogging, TC.Persistence.DynamoDB 2 (configurable V2-with-V1-fallback repository version), TC.Diagnostics health checks 8, Nerdbank.GitVersioning and SonarCloud analysis.
Deployment
Traced via build->yaml-deploy with build pipeline paymentprovider-stripe Containers (release_count 0). build-containers.yml uses the shared InternalOSS/azure-pipelines-templates ci.yml (.NET SDK 8.0.x, SonarCloud) to container-build the API for AWS ECS in eu-west-1 via the aws-payments-tc-apps Terraform repo (useTFVarsDeployment: true, namespace finance-payments, functional area payments); build-packages.yml publishes TC.PaymentProvider.Stripe.Models and TC.PaymentProvider.Stripe.ResponseMappers NuGet packages. Per-environment appsettings (qa/preproduction/production/training) hold only behavioural config — Stripe keys live in DynamoDB, no secrets in source.
Dependencies
Internal: TC.Diagnostics.HealthChecks.AspNetCoreExtensions (tc-diagnostics-portal); the shared TC.Payments.* and TC.Persistence.DynamoDB packages map to no included repo with confidence (consistent with the other payment-provider assessments). External: the Stripe API (payments, products/prices, payment links, webhooks) via Stripe.net; AWS DynamoDB, S3 and ECS.
Data stores
DynamoDB tables Stripe.ChannelConfiguration (per-channel/company live-vs-test config), Stripe.ApiKeyConfiguration and the shared Provider.ApiKeyConfiguration (publishable/secret/webhook-secret keys) via TC.Persistence.DynamoDB; per-environment S3 buckets for external request/response logging (stripe-api-prod-request-response-logs in production).
Integration points
Inbound REST from the payment router/payment-components plus inbound Stripe webhook notifications (signature-verified and unwrapped by a Mediator pipeline behaviour); outbound REST to Stripe. No buses, queues or SQL.
Code health
Good: three test projects (Api, Application, ResponseMappers; ~92 Fact/Theory tests) and an unusually thorough README documenting implemented features, architecture and configuration. Actively maintained (last commit 2026-05-11, same day as its pcipal sibling — the provider family moves together).
Modernisation risks
Low — the most modern of the provider adapters (source-generated Mediator, .NET 8, System.Text.Json 10). Watchpoints: correctness of webhook secret/key management in the shared DynamoDB configuration tables (also used by other providers), and Stripe API versioning — Stripe.net upgrades can change response shapes that the ResponseMappers package must track for downstream consumers.