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,31 @@
type: object
title: InrUpiAccountInfo
description: Required fields for USD -> INR corridor via Upi
required:
- accountType
- beneficiary
- 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
vpa:
type: string
description: Virtual Payment Address (UPI)
example: john@upi
beneficiary:
oneOf:
- $ref: ./IndividualBeneficiary.yaml
- $ref: ./BusinessBeneficiary.yaml
discriminator:
propertyName: beneficiaryType
mapping:
INDIVIDUAL: ./IndividualBeneficiary.yaml
BUSINESS: ./BusinessBeneficiary.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
type: object
title: MxnSpeiAccountInfo
description: Required fields for USD -> MXN corridor via Spei
required:
- accountType
- beneficiary
- clabe
- name
Comment on lines +4 to +8
Copy link
Contributor

Choose a reason for hiding this comment

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

[P2] required uses name, but other beneficiary schemas already use fullName/legalName, and INR UPI uses fullName. If the intent is “payee name”, this inconsistency can be confusing for clients and may cause generated SDKs to expose multiple overlapping fields.

Consider aligning on an existing field name (e.g. fullName) or clarifying in the description why name is distinct from beneficiary.fullName/beneficiary.legalName.

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

Comment:
[P2] `required` uses `name`, but other beneficiary schemas already use `fullName`/`legalName`, and INR UPI uses `fullName`. If the intent is “payee name”, this inconsistency can be confusing for clients and may cause generated SDKs to expose multiple overlapping fields.

Consider aligning on an existing field name (e.g. `fullName`) or clarifying in the description why `name` is distinct from `beneficiary.fullName`/`beneficiary.legalName`.

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

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
name:
type: string
description: Full name of the payee
example: Jane Smith
beneficiary:
oneOf:
- $ref: ./IndividualBeneficiary.yaml
- $ref: ./BusinessBeneficiary.yaml
discriminator:
propertyName: beneficiaryType
mapping:
INDIVIDUAL: ./IndividualBeneficiary.yaml
BUSINESS: ./BusinessBeneficiary.yaml
Comment on lines +23 to +31
Copy link
Contributor

Choose a reason for hiding this comment

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

[P3] This schema duplicates the existing BeneficiaryOneOf.yaml discriminator/oneOf block. To reduce drift (e.g., mapping changes), consider referencing it directly ($ref: ./BeneficiaryOneOf.yaml) instead of repeating the structure.

Also appears in: openapi/components/schemas/external_accounts/InrUpiAccountInfo.yaml:23-31.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

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

Comment:
[P3] This schema duplicates the existing `BeneficiaryOneOf.yaml` discriminator/oneOf block. To reduce drift (e.g., mapping changes), consider referencing it directly (`$ref: ./BeneficiaryOneOf.yaml`) instead of repeating the structure.

Also appears in: `openapi/components/schemas/external_accounts/InrUpiAccountInfo.yaml:23-31`.

<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>

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