-
Notifications
You must be signed in to change notification settings - Fork 10
Add search payments providers endpoint + statement reference to merchant account #330
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
Conversation
| return Beneficiary.merchantAccount() | ||
| .merchantAccountId(gbpAccount.getId()) | ||
| .reference(UUID.randomUUID().toString()) | ||
| .statementReference(RandomStringUtils.randomAlphanumeric(18)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
statementReference is supported for GBP only at API level
|
|
||
| private List<CustomerSegment> customerSegments; | ||
|
|
||
| private Capabilities capabilities; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could not reuse the same Capabilities object already defined in the entities folder (currently used for responses) because in the request BankTransferCapabilites, VrpSweepingCapabilities and VrpCommercialCapabilities are empty objects (whereas they have additional properties in the response).
I initially considered reusing the same objects anyway as adding additional properties in the request was not creating side effects in the APIs, but then I thought it might have led to confusion clients if they were expecting to use those additional properties for filtering out providers
| @Getter | ||
| @ToString | ||
| @EqualsAndHashCode | ||
| public class AuthorizationFlow { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needed, right? Like, we don't have already a AuthFlow model with just the config object
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's correct, we have another AuthorizationFlow entity but it's different (it's a wrapper for an actions object and it's used in the start auth flow API response)
|
|
||
| @Value | ||
| public class SearchPaymentProvidersResponse { | ||
| List<PaymentsProvider> items; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it expected that we're not adding BIN ranges to this PaymentsProvider type, right? Happy to skip them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually missed that, I would add it to keep feature parity with the API, unless you think is really not needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's bring this to @federico1525
Description
statementReferenceto merchant account beneficiary (ACL-223)Type of change
Please select multiple options if required.
Checklist: