Testing PSD2-Compliant Strong Customer Authentication with Event-Driven Architectures
Using Testcontainers, Kafka Streams, and integration testing to validate SCA flows at scale
Strong Customer Authentication (SCA) under PSD2 is often discussed as a regulatory requirement or a UX challenge. In reality, it is an engineering and testing problem—especially in fintech platforms built on event-driven architectures. SCA flows span multiple systems: authentication services, tokenization engines, payment processors, notification channels, and third-party identity providers. Ensuring that these components work together reliably, securely, and compliantly requires more than unit tests or mocked integrations.
This article explores how to design and test PSD2-compliant SCA flows using Testcontainers, Kafka Streams, and event-driven integration testing, with a focus on realism, traceability, and repeatability.
Why SCA Is an Event-Driven Problem
Modern fintech platforms rarely implement SCA as a synchronous, single-step API call. Instead, SCA is orchestrated as a multi-stage process:
A payment or sensitive action is initiated
A risk evaluation determines whether SCA is required
A challenge is triggered (OTP, push, biometric confirmation)
The user responds via a separate channel
The result is validated and correlated back to the original transaction
Each of these steps often emits and consumes events. Kafka (or similar platforms) is commonly used to coordinate these flows asynchronously, ensuring scalability and resilience. From a testing perspective, this means SCA cannot be validated reliably with isolated service tests. It must be tested as a distributed, event-driven workflow.
PSD2 SCA Requirements That Impact Testing
PSD2 introduces concrete constraints that must be verifiable through tests:
Authentication must use at least two independent factors
Authentication results must be cryptographically bound to the transaction
Replay attacks must be prevented
Exemptions must be applied deterministically and auditable
Failures must be handled predictably
These are not abstract requirements—they translate into specific system behaviors that must be validated under realistic conditions.
Tokenization and 2FA as Building Blocks
In many fintech platforms, SCA is implemented using tokenization combined with 2FA. Instead of exposing sensitive transaction data directly, the system generates a short-lived authentication token representing the transaction context. This token is used across services and channels, binding the user’s authentication action to a specific payment or operation. The advantage of this approach is clear: tokens are easier to trace, revoke, expire, and audit—key properties for PSD2 compliance.
Testing must verify not only that tokens are generated and validated correctly, but that they behave correctly across retries, failures, and concurrent flows.
Why Testcontainers Matter for Fintech QA
Mocking Kafka, databases, or identity providers hides many of the issues that occur in production. Timing, serialization, consumer lag, and message ordering are all critical in SCA flows—and none of them are visible with mocks.
Testcontainers allow teams to spin up real dependencies as part of integration tests:
Kafka brokers
Databases
Tokenization services
Notification simulators
This creates an environment that closely mirrors production, while still running deterministically in CI pipelines.
For regulated environments, this realism is essential. Test results must be repeatable, explainable, and defensible.
Event-Driven SCA Flow Under Test
A typical event-driven SCA flow might look like this:
A PaymentInitiated event is published
A risk service consumes it and emits ScaRequired or ScaExempted
If required, an SCA token is generated and an ScaChallengeIssued event is emitted
The user response triggers an ScaCompleted event
The payment engine consumes the result and proceeds or rejects
Each transition is an opportunity for failure—and therefore a test case.
Testing Kafka Streams with Real Dependencies
Kafka Streams is often used to implement decision logic and stateful processing in SCA pipelines. Testing these components requires validating not only output events, but also state transitions. Using Testcontainers, teams can:
start a Kafka broker
deploy the Streams topology
publish input events
assert emitted events and state changes
The following code snippets can be useful here and would typically be shown on screen:
- Kafka Testcontainers setup
- Streams topology initialization
- Event publishing and consumption assertions
This approach ensures that edge cases—duplicate events, out-of-order messages, retries—are handled correctly.
Testing Failure Scenarios and Edge Cases
PSD2 compliance depends heavily on how systems behave when things go wrong. Event-driven integration tests should explicitly cover scenarios such as:
- expired or reused SCA tokens
- delayed user responses
- duplicate challenge confirmations
- partial system outages
- concurrent SCA flows for the same user
These cases are difficult to simulate manually and nearly impossible to validate with unit tests alone. Event-driven integration tests make them repeatable and visible.
Auditability Through Test Design
One often overlooked benefit of this testing approach is audit readiness. Well-structured integration tests produce artifacts that demonstrate:
which events occurred
in what order
with which correlation identifiers
and under which conditions
This mirrors the evidence regulators expect during audits or incident investigations. In many cases, test output can be used as part of internal compliance documentation.
CI/CD and Continuous Compliance
Embedding these tests into CI/CD pipelines ensures that SCA compliance is not a one-time validation, but a continuous guarantee. Every change to authentication logic, token handling, or event schemas is validated automatically. Breaking changes surface immediately, long before they reach production.
This is especially important in fintech environments where multiple teams evolve services independently.
How OceanoBe Approaches SCA Testing in Fintech Platforms
At OceanoBe, we treat SCA as a distributed system, not a feature toggle. Our teams design and test SCA flows using:
event-driven architectures
Kafka Streams for decisioning
Testcontainers for realistic integration tests
token-based authentication models
CI-embedded compliance validation
This approach allows fintech platforms to scale securely, adapt to regulatory changes, and maintain confidence across releases.
SCA Compliance Is Proven Through Tests
PSD2-compliant Strong Customer Authentication cannot be validated with mocks, screenshots, or manual checks. It must be proven through executable, repeatable tests that reflect how the system behaves in production. By combining Testcontainers, Kafka Streams, and event-driven integration testing, fintech teams can validate not just correctness, but resilience, security, and auditability.
In regulated financial systems, the strongest form of compliance is behavior you can test—and reproduce—on demand.
