Card payments improvements

[jakubtobiasz]

As we're currently in the rapid development stage, we delivered a happy path for card payments. This task is aiming to implement missing features and provide fixes proposed during the code review.

Small wins 🏆

• [x] All relevant fixes suggested in #22 are implemented
• [x] The card data form is validated
  • [x] A cardholder name cannot be empty, and should have at least 3 characters
  • [x] A card number must be exactly 16 characters long
  • [x] A CVV code must be exactly 3 characters long
  • [x] A month is selected from a dropdown to prevent mistakes
  • [x] A year is selected from a dropdown to prevent mistakes (a current year and next 15 years)

Important! The validation must be done using some JS code or library, as we do not (and we cannot) pass the card data to the backend. No card data is touching the backend.

[jakubtobiasz]

It is possible to retry a payment with a card1

This point has been removed, as it will be implemented in #70

[jakubtobiasz]

• [ ] All possible cases are handled correctly:
• [ ] amount ending in 1 (cents) - frictionless (payment without additional 3DS confirmation), e.g. 5.21 — a customer sees a successful page
  • [ ] amount ending in 3 - method notification completed successfully (5.23) — a customer sees a waiting for a payment page (#25)
  • [ ] amount ending in 5 - method notification ended with an error (5.25) — a customer sees a waiting for a payment page (#25)
  • [ ] amount ending in 6 - decline (5.26) — a customer sees an error page
  • [ ] amount ending in any other value causes a redirect to challenge (forcing 3DS, e.g. 5.27, 5.24) – a customer sees a successful or an error page depending on a result

99% of handling card payment is a redirect to Tpay anyway, so we just need to handle a generic payment failure (#52).