-
Notifications
You must be signed in to change notification settings - Fork 3
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
Initiate payment request use case based #35
base: master
Are you sure you want to change the base?
Initiate payment request use case based #35
Conversation
639fc9e
to
b284fb8
Compare
@martiBpl Greetings and thanks for raising a PR! From what I can see right now - both InitiateBankPaymentRequest & InitiateCardPaymentRequest provide just a wrapper around InitiatePaymentRequest's bankPaymentMethod & cardPaymentMethod, and that hardly seems like the best potential solution for the problem On top of that - overriding equals & hashCode does make sense based on field types, as long as you encounter comparing the InitiatePaymentRequest objects (was that the original reason for the PR?) |
Hi @Mantas-Ragauskas, One other solution would be to create a separate model class (non inherited) which would have a method mapToInitiatePaymentRequest. Side question: from the docs I've read that when creating a card payment you have to always provide a bankPaymentMethod
Does this mean that the bankPaymentMethod is required at all times? |
It should be. It would be way easier to just mark it as mandatory, even if that is only a business rule that is not implemented on the API yet. Will talk with the Platform team. They consider to implement such business rule on the API as well. |
No description provided.