Add ability to surface custom error text

[man-of-seafood]

Describe the feature you'd like to request

Context: Similar my previous issue (link) - capturing card details and creating the card on the backend is a 2 step process, the 2nd of which could yield an error from the backend. In those cases, we'd like to be able to display the error from the backend.

Describe the solution you'd like

Expose a prop on the CreditCardInput named something like errorText that, when present, will render in the same place and with the same styles as the frontend validation error text. It would also trigger the error styling (red border, iirc). Assuming both a frontend validation error and an error supplied via errorText are present, I think the most flexible thing to do would be to render the errorText below the frontend validation error text. Likely having both of these present at the same time indicates a logical error, but imo that will at least be quickly apparent to the dev when they see both at the same time. And in the case both are actually needed, it's possible to display both.

Describe alternatives you've considered

Placing the error text elsewhere (i.e. somewhere in the component tree that we control). However, it seems most natural to surface the backend validation error in the same place.

[danestves]

Hi @man-of-seafood! After reading some of the docs I have seen this prop on the Square SDK setError https://developer.squareup.com/reference/sdks/web/payments/card-payments#Card.setError so, I think we can add it as a prop for the Credit Card input, and also watch any other method that make use of this prop

[man-of-seafood]

Thanks for the link! I looked at the setError docs, and it looks like you have to specify the field with the error, which leads me to think it will just use the default error text associated with that key. Correct me if I'm wrong, but it sounds like surfacing a custom error in that spot would require an upstream change to the SDK's API.

Edit (adding more context): We don't want to surface the specific issue from the backend (e.g. X field is invalid) since that introduces a security issue (i.e. an attacker can use backend validation errors to guide their attempts to crack it). With that in mind, we're trying to surface a generic message that doesn't reference a specific field.

[danestves]

Oh yeah, that is true! I'm thinking that we can introduce a setError function that receive an error string and style it like Square shows the errors, if no string is passed we use a generic error when calling that function like There was an error creating the payment, please try again

[danestves]

I have been playing around about this, what do you think?

[man-of-seafood]

After speaking with our team more about it, we'll be going with a different error-surfacing strategy, but I appreciate the proposed solution. And I'll see if I can find who works on the SDK to see if they'd consider exposing a hook to set error text in the standard spot which might make things easier!

[danestves]

Perfect! So, we can close this issue for now and reopen it if there is any update from Square?

[man-of-seafood]

Yes - closing it out!