-
Notifications
You must be signed in to change notification settings - Fork 7
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
Brazilian standard require idNumber and back document #94
Conversation
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.
Like with the other PR, please open a PR against the FiatConnect specification document with the changes you'd like to see before making PRs against any of the actual code repositories. Also, this PR looks identical to your other PR, except for the addition of some changes to an existing KYC schema.
@@ -195,4 +218,4 @@ export type GetFiatAccountsResponse = z.infer< | |||
export const postFiatAccountResponseSchema = obfuscatedFiatAccountDataSchema | |||
export type PostFiatAccountResponse = z.infer< | |||
typeof postFiatAccountResponseSchema | |||
> | |||
> |
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.
nit: newline
@@ -48,7 +48,10 @@ export const personalDataAndDocumentsKycSchema = z.object( | |||
}), | |||
phoneNumber: z.string(), | |||
selfieDocument: z.string(), | |||
identificationDocument: z.string(), | |||
// identificationDocument: z.string(), |
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 can understand the need for requiring a front and back picture for an identification document, however, as it stands currently, this would introduce a breaking change to the current schema. Current consumers of this schema could in theory just use identificationDocumentFront
instead of identificationDocument
and ignore the two other new optional fields, but it would still be a breaking change. If this is required, we can think about how to add support for this into the spec without introducing a breaking change.
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.
Hi @jophish , its required. How can we do that without introducing a breaking change? One way is just add a identificationDocumentBack and idNumber and left identificationDocumment without changes.
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.
superceded by #122 |
No description provided.