Skip to content
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

Open
2 tasks done
vspecky opened this issue Apr 22, 2024 · 0 comments
Assignees
Labels
A-constraint-graph Area: Constraint Graph A-payments Area: payments A-routing Area: Routing C-feature Category: Feature request or enhancement

Comments

@vspecky
Copy link
Member

vspecky commented Apr 22, 2024

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.

  • The Payment Methods filtering logic makes use of handwritten code to check merchant configs and app configs
  • The Eligibility Analysis during payments confirmation makes use of the Constraint Graph framework to carry out 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?

  • I checked and didn't find a similar issue

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

@vspecky vspecky added C-feature Category: Feature request or enhancement A-payments Area: payments A-routing Area: Routing A-constraint-graph Area: Constraint Graph labels Apr 22, 2024
@vspecky vspecky added this to the April 2024 milestone Apr 22, 2024
@bernard-eugine bernard-eugine modified the milestones: April 2024, May 2024 May 3, 2024
@prajjwalkumar17 prajjwalkumar17 self-assigned this May 3, 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
Projects
None yet
Development

No branches or pull requests

3 participants