Credit card entry/update element

[brettflorio]

The Goal

We need an element that we can add to the customer portal to allow customers to update their payment details. In most cases, this will be a credit/debit card, so we'll need to do the appropriate modern js+iframe approach to ensure the inputs can't be accessed from other scripts on the page. There are 2 primary use cases, related but different:

1. On the checkout, this element will send data to a Foxy-controlled endpoint, and an encrypted payload will be returned. This encrypted payload will then be submitted when the checkout is submitted, decrypted serverside by Foxy, and handled basically as if a credit card was submitted directly to Foxy. (This is actually fairly similar to how Apple Pay and Google Pay work.)
   • Validation and inline errors will be limited in this case to ensuring the card number passes the luhn check, the expiration is in the future, the security code is 3 or 4 integers, etc. The card isn't actually verified at this step so no additional UI for messaging is required.
2. On the customer portal, submitting new payment details will (typically) result in the card being verified at that point. The response will not include an encrypted payload. Instead, it will contain a success or error message.

Some of our supported gateways (Stripe, Square, etc.) have their own js/iframe approach. In both the checkout and portal, we'd likely have a container component that loads either this new component of ours or a 3rd party embed/form/whatever.

The Details

Notes from our Slack discussion:

• For the UI, the element itself will basically render one iframe for all inputs. This is more lightweight than multiple iframes, has better accessibility and support for autocompletion.

• Customisation/styling: it will be limited. I think we should use Lumo CSS vars for consistency. We can read and send them to iframe on DOM connection, element resize, color scheme change and/or provide an option to update the values manually (e.g. via an event or a function call). This should cover a lot, if not most use cases. We may also look into supporting Vaadin’s ThemeableMixin in limited capacity if there’s ever a demand for that kind of functionality.

• Translations: those can come from the parent page via postMessage() as well.

• Templates/slots: no support inside of the iframe.

• Hidden/Readonly/Disabled control selectors: full support.

• The page that iframe will load should be a in the app-serverless repo, with as few dependencies or external libraries as possible. CORS can rely on the same domains that the portal allowlists, as well as the store's checkout domain. We’ll want to make sure the URL is versioned. We’ll also want to make sure that we limit the origins that receive postMessage() events from the iframe

Other Considerations

TBD.

[pheekus]

In progress: https://github.com/Foxy/foxy-elements/tree/feature/tokenization-embed

[pheekus]

Released in v1.27.0