Fix fields for pix payout

[creeperkatze]

Fixes #5425

[IMB11]

Thank you!

[alikindsys]

So, this fixes the frontend aspect of it, but as the backend still expects all fields you can't withdraw using this method.
I've removed the disabled attribute on the button to send these requests, and it is only when filling all of the payment options that the request goes through.

---

Edit: We did some digging and it seems like you're using MuralPay to handle those PIX-based transactions, seen that they support it. And as per their API bank branch code is only required for wire transfers, which are a separate thing, this is confusing and should be renamed to "random key" (Chave aleatória) and include a blank uuid as a placeholder since that's what the api actually expects (we've actually put the bank branch code there by mistake as it still is a requirement on the backend).

Due to what i presume to be KYC, CPF/CNPJ is always required on all requests, so that field should always be visibile. The blocking point is the deserialization errors, which should be fixed with adding Option to the fields of the rust struct that handles that on the backend (or making it an enum, making them optional would be the easiest option).

Other then that the transaction went smoothly, there are just some ux improvements, as this PR partially fixes the issue.

[creeperkatze]

So, this fixes the frontend aspect of it, but as the backend still expects all fields you can't withdraw using this method. I've removed the disabled attribute on the button to send these requests, and it is only when filling all of the payment options that the request goes through.

Edit: We did some digging and it seems like you're using MuralPay to handle those PIX-based transactions, seen that they support it. And as per [their API](https://developers.muralpay.com/docs/validations#brl-pix-bank-account) bank branch code is only required for wire transfers, which are a separate thing, this is confusing and should be renamed to "random key" (Chave aleatória) and include a blank uuid as a placeholder since that's what the api actually expects (we've actually put the bank branch code there by mistake as it still is a requirement on the backend).

Due to what i presume to be KYC, CPF/CNPJ is always required on all requests, so that field should always be visibile. The blocking point is the deserialization errors, which should be fixed with adding Option to the fields of the rust struct that handles that on the backend (or making it an enum, making them optional would be the easiest option).

Other then that the transaction went smoothly, there are just some ux improvements, as this PR partially fixes the issue.

Would this be correct now? (Not on the website yet)

[alikindsys]

Would this be correct now? (Not on the website yet)

This is certainly more correct, if the intended flow is to use the "bank account" key type.

To put it more more strictly:

• Selecting "CPF/CNPJ" would only show one field: CPF/CNPJ
• Selecting any other key type would show two input fields: CPF/CNPJ and the respective field thats required for that option.

A minor nitpick is that "bank account" is unintuitive, so it could be renamed to random key to match the required field. I never saw it being referenced as a "bank account key type".