Case Study: Card Payments Processor - Modernising API Security and Onboarding

Client Overview

The client was A UK payments processor powering fintech card programmes worldwide. As a PCI DSS Level 1 service provider, it needed to modernise its API security posture to meet growing regulatory obligations, reduce onboarding friction, and stay competitive in the rapidly evolving payments market.

The Challenge

Some client messages were still being sent over plain HTTP
Customer connectivity often relied on VPNs - slow, brittle, and expensive to maintain
Onboarding took weeks, with high operational overhead
Shared secrets and static credentials were in use, at odds with PCI DSS v4.0 requirements for credential cycling

Our Approach

This engagement was initially delivered via Raidiam, and later independently by Opendata Consult. Craig Greenhouse led the work as principal architect, supported by various other teams and team members.

Phase 1 - Discovery Workshops

Craig ran deep-dive architecture and security discovery sessions to baseline the current state and map regulatory and operational risks.
Phase 2 - Reference Architecture and recommendations

Risks were identified, recommendations for changes to architecture were presented to the client.
Phase 3 - Implementation

See below for Technical Deep Dive

Technical Deep Dive

The transformation wasn't just about turning on mTLS - it was a multi-layered programme of work that combined PKI, OAuth, trust frameworks, and careful migration planning. Below is a deeper look at the engineering delivery.

1. Trust & IAM Modernisation

We introduced Raidiam Connect as the client's federated trust anchor. This gave partners complete self-service for minting both transport and signing certificates. Once a certificate was generated, it could be used immediately to register OAuth clients in Cloudentity via Dynamic Client Registration (DCR).

This removed the need for static secrets and introduced enforced credential rotation as part of the process.

We also extended the use of Software Roles (a feature already present in Raidiam Connect). Each customer organisation was assigned roles that reflected which services they had access to - some bundled, some paid-for. When the customer created a Software Statement, they could only select from the roles assigned to their organisation.

In Cloudentity, those roles were mapped to specific OAuth scopes. Policy enforcement meant that if a client attempted to request scopes outside of their assigned roles during DCR, the request would be denied. This created a fine-grained, enforceable pay-per-use API model.

Example Software Statement Assertion with Software Roles Listed ( Top Right )

2. OAuth & Federated Identity

On top of DCR, Cloudentity was deployed for broader IAM functions:

Federated SSO so that each fintech could log into Raidiam Connect using their own IdP.
Per-organisation user pools with just-in-time (JIT) user provisioning.
Delegated Org Admins who could manage their own users once the initial setup was complete.

This meant the operator only needed to bootstrap a single Org Admin account - after that, customers were entirely self-service for user management.

3. mTLS Architecture

We built a multi-mTLS management architecture, designed to scale across dozens of fintech partners:

For REST APIs, traffic was fronted by an NGINX proxy before hitting AWS components (ALB, API Gateway, Lambda).
For SOAP, a separate NGINX listener on port 443 allowed new mTLS traffic to run side-by-side with the legacy port, enabling a controlled migration.
For payment processor-to-customer messages, we reversed the pattern: each customer terminated their own mTLS, using certificates signed by Raidiam Connect CAs.

Customers could optionally add certificate pinning and IP allow-listing, though in practice most were content with standard mTLS.

The engineering was non-trivial: it required proprietary message processor changes, SQL schema adjustments, new C# code in the messaging servers, and a naming/rotation scheme integrated with AWS Secrets Manager and IAM policies.

Towards the end of the engagement, we also designed the architecture for automatic certificate rotation, which was handed over as a next-phase project.

Click the diagram to open it full size in a new tab.

4. SOAP → REST Migration

Alongside securing SOAP with mTLS, a parallel initiative was launched to convert legacy SOAP calls to REST. This was the long-term retirement strategy for SOAP, ensuring the processor would not be tied to legacy integrations indefinitely.

In the meantime, NGINX routing supported a dual-path approach:

New calls to the modern FQDN used FAPI-conformant REST with mTLS and private key JWT.
Old calls to the legacy FQDN continued to work via client-secret flow.

This dual routing allowed customers to migrate gradually without service disruption.

5. Developer Enablement

Technical change was matched with developer enablement. We created detailed documentation, SOPs, and training across engineering, implementation, and support teams.

For external partners, we delivered a Postman collection that automated the hardest parts of OAuth onboarding. Developers only needed to supply five variables (Org ID, SSA ID, Client ID, Signing Key ID, and the private key itself). Everything else - including private key JWT assertions and discovery endpoint resolution - was automated.

One customer was fully onboarded to REST in just three days (Monday-Wednesday) - the fastest in company history.