Skip to content

Conversation

@tl-luca-baggi
Copy link
Contributor

@tl-luca-baggi tl-luca-baggi commented Dec 4, 2024

Description

  • add statementReference to merchant account beneficiary (ACL-223)
  • add search payments providers endpoint (ACL-187)

Type of change

Please select multiple options if required.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code where necessary
  • I have added tests that prove my fix is effective or that my feature works
  • I have updated the relevant documentation

@tl-luca-baggi tl-luca-baggi requested review from a team as code owners December 4, 2024 10:46
return Beneficiary.merchantAccount()
.merchantAccountId(gbpAccount.getId())
.reference(UUID.randomUUID().toString())
.statementReference(RandomStringUtils.randomAlphanumeric(18))
Copy link
Contributor Author

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;
Copy link
Contributor Author

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 {
Copy link
Contributor

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

Copy link
Contributor Author

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;
Copy link
Contributor

@dili91 dili91 Dec 10, 2024

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

Copy link
Contributor Author

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?

Copy link
Contributor

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

@tl-luca-baggi tl-luca-baggi merged commit 653cd57 into main Dec 10, 2024
16 checks passed
@tl-luca-baggi tl-luca-baggi deleted the ACL-223 branch December 10, 2024 16:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants