Is your feature request related to a problem? Please describe.
Yes. This project is designed to receive webhook events from multiple third-party providers (e.g., IPG, Paystack, Flutterwave, etc), each with different payload structures. This leads to repetitive parsing logic, tight coupling with external formats, and increased maintenance overhead. This is a classic case of impedance mismatch
Describe the solution you'd like
Introduce a normalization layer that converts all incoming webhook payloads into a unified internal structure. This will act as an adapter between each provider and our internal system, resolving the impedance mismatch and simplifying downstream handling
Describe alternatives you've considered
-
Continuing with conditional logic per provider in the main webhook handler (leads to tightly coupled, hard-to-test code).
-
Creating separate processing pipelines for each provider (duplicated logic, inconsistent behavior).
None of these fully resolve the underlying impedance mismatch or scale well as new webhook sources are added.
Additional context
-
This approach aligns with the Adapter Design Pattern and promotes loose coupling, testability, and future extensibility.
-
Normalization also improves observability, as logs and internal monitoring will reference a consistent structure.
Is your feature request related to a problem? Please describe.
Yes. This project is designed to receive webhook events from multiple third-party providers (e.g., IPG, Paystack, Flutterwave, etc), each with different payload structures. This leads to repetitive parsing logic, tight coupling with external formats, and increased maintenance overhead. This is a classic case of impedance mismatch
Describe the solution you'd like
Introduce a normalization layer that converts all incoming webhook payloads into a unified internal structure. This will act as an adapter between each provider and our internal system, resolving the impedance mismatch and simplifying downstream handling
Describe alternatives you've considered
Continuing with conditional logic per provider in the main webhook handler (leads to tightly coupled, hard-to-test code).
Creating separate processing pipelines for each provider (duplicated logic, inconsistent behavior).
None of these fully resolve the underlying impedance mismatch or scale well as new webhook sources are added.
Additional context
This approach aligns with the Adapter Design Pattern and promotes loose coupling, testability, and future extensibility.
Normalization also improves observability, as logs and internal monitoring will reference a consistent structure.