[C2F] Formatting on IBAN input and correct error validation UX

[melyndav]

Description

There is no validation on incorrect formatting for the IBAN input field when the CTA button is selected, and only shows after it's been selected with a toast, which is inconsistent with the rest of the validation UX and does not indicate to the user what specifically the issue is and how to resolve it.

Example: When I enter (dummy data for screenshot purposes) IBAN details in that follow the format from my bank which includes spacing, no validation is shown upon selecting the CTA:

Toast with generic error:

However, if I input the incorrect SWIFT format, validation is provided.

Scope:

Add validation to match the accepted IBAN format from the API (no spacing between numbers and digits). Add inline to the form when the CTA is selected to ensure consistency in the error state UX.

Remove the toast validation.

All updates should be made across all responsive sizes.

[melyndav]

Related issue: #2963

[rdig]

Two things here:

• we'll need specs for IBAN validation (alternatively we'll need more time to research the ISO standards)
• the toast validation still needs to be present, since we need to capture any errors communicating with the bridge API

[melyndav]

@rdig good point. We will confirm with the API what the validation for the spec.

[arrenv]

I have run a couple of tests on the API, and it seems as though the API requirements are:

• "Must be alphanumeric, without spaces."

This seems only relevant for iban.account_number and iban.bic. Spaces did not seem to be an issue for US accounts.

[rdig]

There's 3 things to consider here:

• bridge's requirements
• actual IBAN ISO 13616 (revised edition) standard format
• our specs

Because in the end it only matters what we want to validate against, since we can have a setup like this:

1. validate IBAN using our spec (let's say something more complex, five groups of four chars, first group needs to contain letters at position 0 and 1 -- country, followed by two numbers, then the remaining four groups must include only numbers)
2. after we validate the above, we can format it in a format that bridge accepts (in this case, basically just remove the spaces)

As long as we come up with specs for validation, we're all good to go

[arrenv]

@rdig Great, that gives us more freedom on our side. He is the spec.

• Account type: US

  • Account number
    • Must be numeric.
      • Validation message: “Please enter only numbers.”
    • Spaces should be supported, allowing users to easily copy and paste in values.
    • Should validate the length to be between 6 to 17 digits as of general practices influenced by guidelines from NACHA and the UCC.
    • Attention should be given to ensuring the API sent values are formatted to abide by the service provider API requirements.
  • Routing number
    • Must be numeric.
      • Validation message: “Please enter only numbers.”
    • Spaces should be supported, allowing users to easily copy and paste in values.
    • Should validate the length to be exactly 9 digits as defined by the ABA Routing Number Policy and guidelines from the Federal Reserve.
    • Attention should be given to ensuring the API sent values are formatted to abide by the service provider API requirements.

• Account type: IBAN

  • IBAN
    • Must be alphanumeric.
      • Validation message: “Please enter only letters and numbers.”
    • Spaces should be supported, allowing users to easily copy and paste in values.
    • Should validate the length to be a minimum of 15 and a maximum of 34 alphanumeric characters as defined in ISO 13616-1:2020.
    • Attention should be given to ensuring the API sent values are formatted to abide by the service provider API requirements.
  • BIC
    • Must be alphanumeric.
      • Validation message: “Please enter only letters and numbers.”
    • Spaces should be supported, allowing users to easily copy and paste in values.
    • Should validate the length to be 8 or 11 alphanumeric characters as defined in ISO 9362:2014.
    • Attention should be given to ensuring the API sent values are formatted to abide by the service provider API requirements.
  • Country
    • Selectable list including all ISO 13616-1 countries that officially use the IBAN system.
    • Countries should be in full name.
    • As the user types in a character, it should jump to best match countries in the list.
      • Matching should be by prefix search.

• Account type: Swift

  • If IBAN type then same as IBAN; otherwise:
  • All other/unknown type: Account number
    • Must be alphanumeric.
      • Validation message: “Please enter only letters and numbers.”
    • Spaces should be supported, allowing users to easily copy and paste in values.
    • Should validate the length to be 8 to 34 characters alphanumeric characters, dependent on bank.
    • Attention should be given to ensuring the API sent values are formatted to abide by the service provider API requirements.
  • BIC / SWIFT code
    • Must be alphanumeric.
      • Validation message: “Please enter only letters and numbers.”
    • Spaces should be supported, allowing users to easily copy and paste in values.
    • Should validate the length to be 8 or 11 alphanumeric characters as defined in ISO 9362:2014.
    • Attention should be given to ensuring the API sent values are formatted to abide by the service provider API requirements.

[rdig]

Just a small heads up that ISO 13616-1:2007 is the old, deprecated version, the current one is ISO 13616-1:2020 (the one I linked to above)

As far as I can tell the actual IBAN format hasn't changed between the revisions, but better to use the current one to avoid confusion

[arrenv]

Good pickup, I have updated it.

[jakubcolony]

@arrenv Spotted this while testing #3474, shouldn't both the account and routing numbers be digits only? From my research letters are not allowed.

[arrenv]

Thanks @jakubcolony, looks like a fell victim to some lazy copy and paste. Fixed now.

I have also added the SWIFT one.