-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Unify constraint validation logic in list payment methods filtering and in eligibility analysis during payment confirmation #4417
Closed
2 tasks done
Labels
A-constraint-graph
Area: Constraint Graph
A-payments
Area: payments
A-routing
Area: Routing
C-feature
Category: Feature request or enhancement
Milestone
Comments
14 tasks
14 tasks
14 tasks
This was
linked to
pull requests
Jun 19, 2024
This was
linked to
pull requests
Jun 22, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-constraint-graph
Area: Constraint Graph
A-payments
Area: payments
A-routing
Area: Routing
C-feature
Category: Feature request or enhancement
Feature Description
Currently, the logic that filters out ineligible payment methods when listing available payment methods for the merchant, and the logic that filters out ineligible connectors for a particular payment have the same underlying validation checks involved. These validations checks are based on the same data, namely the merchant's connector account configuration and application configs. Yet, both the aforementioned pieces of logic use different implementations for carrying out said checks.
We want to essentially unify the aforementioned implementations such that both pieces of logic make use of the same implementation.
Possible Implementation
We can make use of the constraint graph framework to represent all the checks as a constraint graph. One thing to be aware of is that the Payment Methods filtering logic checks the eligibility of payment methods whereas the Eligibility Analysis checks the eligibility of a connector for a particular payment, i.e. the goals differ even if the underlying checks are based on the same data.
The Constraint Graph can be build in a way that's sensitive to the domain of the constraints, and hence is a viable approach for the implementation.
Have you spent some time checking if this feature request has been raised before?
Have you read the Contributing Guidelines?
Are you willing to submit a PR?
No, but I'm happy to collaborate on a PR with someone else
The text was updated successfully, but these errors were encountered: