Payments - architectural dilemma
Hi everyone 👋
I'm working on a complex payment application that needs to integrate multiple payment providers (Stripe, PayPal, etc.). I've been pondering the best architectural approach and would love to get some insights from someone who has experience with Payments.
My main dilemma is:
1. Should I implement each payment provider as a separate service within a single solution?
2. Or should I create a separate solution for each payment provider?
I've attached screenshot of 2nd scenario architecture. Any advice would be greatly appreciated.
I've attached screenshot of 2nd scenario architecture. Any advice would be greatly appreciated.
3 Replies
Separate solutions seems like complete overkill
look into the strategy pattern if you haven't already. Each payment method should be a separate strategy.
yeah, after giving it some more thought, separate solutions are definitely overkill at this point
Encapsulating domain logic for each payment provider within seperate namespace seems as better approach
However I'm still not sure should I use strategy pattern, dependency injection or factory pattern for this, any additional suggestions? Additionaly, where do I store sensitive configuration information for each payment provider?
do you have an idea on the best approach @canton7 ?