Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
type: object
title: InrUpiAccountInfo
description: Required fields for USD -> INR corridor via Upi
required:
- accountType
- fullName
- vpa
properties:
accountType:
type: string
enum:
- INR_UPI_ACCOUNT
example: INR_UPI_ACCOUNT
fullName:
type: string
description: Full name of the beneficiary
example: John Michael Doe
Comment on lines +14 to +17
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Field fullName is inconsistent with existing patterns. The existing UpiAccountExternalAccountInfo.yaml uses a beneficiary object with IndividualBeneficiary or BusinessBeneficiary types. This standalone fullName field doesn't align with the established beneficiary pattern used across other account types.

Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/InrUpiAccountInfo.yaml
Line: 14:17

Comment:
Field `fullName` is inconsistent with existing patterns. The existing `UpiAccountExternalAccountInfo.yaml` uses a `beneficiary` object with `IndividualBeneficiary` or `BusinessBeneficiary` types. This standalone `fullName` field doesn't align with the established beneficiary pattern used across other account types.

How can I resolve this? If you propose a fix, please make it concise.

vpa:
type: string
description: Virtual Payment Address (UPI)
example: john@upi
Comment on lines +1 to +21
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This schema introduces INR_UPI_ACCOUNT as a new account type but it's not registered in:

  1. ExternalAccountInfoOneOf.yaml (discriminator oneOf list and mapping)
  2. ExternalAccountType.yaml (enum values)

Without these registrations, this schema cannot be used in the API. Check if this needs integration or if it's intended for a different purpose.

Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/InrUpiAccountInfo.yaml
Line: 1:21

Comment:
This schema introduces `INR_UPI_ACCOUNT` as a new account type but it's not registered in:
1. `ExternalAccountInfoOneOf.yaml` (discriminator oneOf list and mapping)
2. `ExternalAccountType.yaml` (enum values)

Without these registrations, this schema cannot be used in the API. Check if this needs integration or if it's intended for a different purpose.

How can I resolve this? If you propose a fix, please make it concise.

Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
type: object
title: MxnSpeiAccountInfo
description: Required fields for USD -> MXN corridor via Spei
required:
- accountType
- clabe
- name
properties:
accountType:
type: string
enum:
- MXN_SPEI_ACCOUNT
example: MXN_SPEI_ACCOUNT
clabe:
type: string
description: Mexican CLABE interbank account number (18 digits)
example: 012180001234567890
Comment on lines +14 to +17
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Field clabe differs from existing pattern in ClabeAccountInfo.yaml which uses clabeNumber with validation (18 digits, pattern ^[0-9]{18}$). This schema lacks the validation constraints present in the existing implementation.

Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/MxnSpeiAccountInfo.yaml
Line: 14:17

Comment:
Field `clabe` differs from existing pattern in `ClabeAccountInfo.yaml` which uses `clabeNumber` with validation (18 digits, pattern `^[0-9]{18}$`). This schema lacks the validation constraints present in the existing implementation.

How can I resolve this? If you propose a fix, please make it concise.

name:
type: string
description: Full name of the payee
example: Jane Smith
Comment on lines +1 to +21
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This schema introduces MXN_SPEI_ACCOUNT as a new account type but it's not registered in:

  1. ExternalAccountInfoOneOf.yaml (discriminator oneOf list and mapping)
  2. ExternalAccountType.yaml (enum values)

Without these registrations, this schema cannot be used in the API. Check if this needs integration or if it's intended for a different purpose.

Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/MxnSpeiAccountInfo.yaml
Line: 1:21

Comment:
This schema introduces `MXN_SPEI_ACCOUNT` as a new account type but it's not registered in:
1. `ExternalAccountInfoOneOf.yaml` (discriminator oneOf list and mapping)
2. `ExternalAccountType.yaml` (enum values)

Without these registrations, this schema cannot be used in the API. Check if this needs integration or if it's intended for a different purpose.

How can I resolve this? If you propose a fix, please make it concise.

Comment on lines +18 to +21
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Field name is inconsistent with existing patterns. The existing ClabeAccountExternalAccountInfo.yaml uses a beneficiary object structure. This standalone name field doesn't align with the established beneficiary pattern used across other account types.

Prompt To Fix With AI
This is a comment left during a code review.
Path: openapi/components/schemas/external_accounts/MxnSpeiAccountInfo.yaml
Line: 18:21

Comment:
Field `name` is inconsistent with existing patterns. The existing `ClabeAccountExternalAccountInfo.yaml` uses a `beneficiary` object structure. This standalone `name` field doesn't align with the established beneficiary pattern used across other account types.

How can I resolve this? If you propose a fix, please make it concise.