paymentprovider-pcipal
ASP.NET Core 8 adapter API integrating TC's payments platform with PCI Pal for PCI-compliant secure phone payments, generating and tracking PCI Pal sessions whose captured card details are tokenised via BR-DGE.
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, MediatR 12, FluentValidation, Serilog |
| 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-pcipal
Purpose
Adapter API fronting the third-party PCI Pal "Integrated Solution" for secure telephone payments in Phenix: a travel counsellor on a Teams/Zoom call launches the PCI Pal iframe from the payment form, links the call via a four-digit ID, and the customer keys card details on their phone keypad. Handlers cover auth-token acquisition/refresh, session generation and status, channel details, token stores and external request/response logging. Unusually for PCI Pal integrations, card capture is delegated to a BR-DGE-built API so TC receives a BR-DGE token and completes the payment itself (allowing card fees to be charged).
Tech stack
C# on .NET 8 (API, Application, DataAccess, Models, PspModels projects). MediatR 12 with validation behaviors, FluentValidation, Serilog, Asp.Versioning, Swashbuckle 8, Scrutor, OneOf, JetBrains annotations; shared payments packages TC.Payments.Models, TC.Payments.Logging, TC.Payments.JsonMessageTransport (+ WebapiLogging) and TC.Persistence.DynamoDB 2; TC.Diagnostics health checks; Nerdbank.GitVersioning and SonarCloud analysis.
Deployment
Traced via build->yaml-deploy with build pipeline paymentprovider-pcipal 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 and deploy to AWS ECS in eu-west-1 via the aws-payments-tc-apps Terraform repo (useTFVarsDeployment: true, namespace finance-payments); build-packages.yml publishes the TC.PaymentProvider.PciPal.Models NuGet package for consumers. Per-environment appsettings gate sandbox vs live PCI Pal channel settings (flow/tenant IDs only — credentials come from DynamoDB/AWS, no secrets in source).
Dependencies
Internal: TC.Diagnostics.HealthChecks.AspNetCoreExtensions (tc-diagnostics-portal); the shared TC.Payments.*/TC.Persistence.DynamoDB packages map to no included repo with confidence (consistent with the paymentprovider-br-dge assessment). External: the PCI Pal REST API (staging pcipalstaging and live platforms, eu-west regions) and BR-DGE/Comcarde as the card-capture/tokenisation partner; AWS DynamoDB, S3 and ECS.
Data stores
DynamoDB tables PciPal.ChannelConfiguration (per-channel flow/tenant config) and Provider.ApiKeyConfiguration (client IDs/secrets) via TC.Persistence.DynamoDB; per-environment S3 buckets for external request/response logging (pcipal-api-prod-request-response-logs in production).
Integration points
Inbound REST from the payment router/payment-components (which render the PCI Pal iframe via the bridge telephony components); outbound REST (JSON and form-encoded) to the PCI Pal API with token auth. No buses, queues or SQL.
Code health
Good: three test projects (API tests with a shared TestBase plus application tests, ~100 Fact/Theory tests) using AutoFixture/NSubstitute/FluentAssertions and Microsoft.AspNetCore.Mvc.Testing. Excellent README explaining the business context, call flow and the non-standard BR-DGE split. One oddity: a stray TC.PaymentProvider.Bridge.Application.csproj (referencing a QuickBooks SDK) sits alongside the real Application csproj — an apparent copy-paste leftover from the br-dge repo. Actively maintained (last commit 2026-05-11).
Modernisation risks
Low — modern .NET 8, containerised ECS deployment, good tests and CI with SonarCloud. Watchpoints: the payment flow spans three parties (PCI Pal, BR-DGE, TC) so vendor-side changes on either can break telephone payments; the stray Bridge/QuickBooks csproj should be deleted to avoid confusion and needless dependency surface.