Improve Validation Error Messages For Banking Info

[Derek Siemens (DerekSiemens)]

Description of the change

Add in translatable error messages from the Finance API for banking information.

Type of change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation or Development tools (readme, specs, tests, code formatting)

Links

• Jira issue number: (PUT IT HERE)
• Process.st launch checklist: (PUT IT HERE)

Checklists

Development

• Prettier was run (if applicable)
• The behaviour changes in the pull request are covered by specs
• All tests related to the changed code pass in development

Paperwork

• This pull request has a descriptive title and information useful to a reviewer
• This pull request has a Jira number
• This pull request has a Process.st launch checklist

Code review

• Changes have been reviewed by at least one other engineer
• Security impacts of this change have been considered

[Copilot]

Pull request overview

Adds support for richer, (optionally) translatable validation error messages for the Tax & Cash “Banking Info” form by mapping Finance/Impact API validation errors into frontend-friendly error codes and formatting per-field ICU templates.

Changes:

• Map API validation error field names to form field names and map API error message strings to short frontend error codes.
• Extend the form error shape to carry an errorCode, and plumb it through to validation help text rendering.
• Introduce per-field ICU select templates (as component props) to render more specific error messages.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
packages/mint-components/src/components/tax-and-cash/sqm-banking-info-form/useBankingInfoForm.tsx	Adds mapping from API field/message to form field + errorCode and attaches errorCode onto per-field errors.
packages/mint-components/src/components/tax-and-cash/sqm-banking-info-form/sqm-banking-info-form.tsx	Adds per-field ICU error message props + uses them in getValidationErrorMessage when errorCode is available.
packages/mint-components/src/components/tax-and-cash/sqm-banking-info-form/sqm-banking-info-form-view.tsx	Extends the form error typing to include optional errorCode and adds errorMessages to text props.
packages/mint-components/src/components/tax-and-cash/sqm-banking-info-form/formDefinitions.tsx	Passes errorCode + fieldName into the validation message formatter for each input.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

In getValidationErrorMessage, the intl.formatMessage id is built from both fieldName and errorCode. Since errorCode can be the raw API message when it’s not mapped, this creates effectively unbounded/dynamic message IDs (including spaces/punctuation), which makes translation management and caching unpredictable. Consider using a stable id per field (e.g. fieldError-${fieldName}) and rely on the ICU select in defaultMessage to vary by errorCode instead of encoding errorCode into the id.

Suggested change

	id: `fieldError-${fieldName}-${errorCode}`,
	id: `fieldError-${fieldName}`,

[Copilot]

The banner comment says these frontend error codes are “mapped from the API error codes”, but in useBankingInfoForm they’re derived from (and keyed by) the Impact API message strings. Tweaking this wording to “mapped from API error messages” would better reflect the actual behavior and avoid confusion for future maintainers.

Suggested change

	// Error codes are short frontend keys mapped from the API error codes.
	// Error codes are short frontend keys mapped from API error messages.

[Derek Siemens (DerekSiemens)]

I do not think this is a good approach but its the best the AI can do with the current backend implementation.

The graphql API returns the field and the error message. But we need the error message to be translatable, I got it to setup this map so the ICU message can be nicer but this is so fragile... If the payments squad changes their text then our frontend would default to our fallback in the ICU message.

I think a better approach would be to return the error path from the graphql API. EX, this is coming back from the Finance API withdrawal.settings.error.patronymicName.alphanumeric. We can then use this as a much more stable data point for the ICU message translatability. The backend of course can remove some elements out of that path as needed