I suggest you look to create a test pyramid with someething like

                1 manual UI test
              2 automated UI tests
            10 automated Unit tests

The manual test is to look at the page and see if anything seems amiss. This will cover the styles verification plus a lot more. The automated UI tests should cover the happy path, one sad path and 1 optional path. So: (1 case) happy - payment works, sad (2 cases) - amount is invalid, e.g. alpha and amount is blank.

For the unit cases it will actually depend on the technology:

If using a HTML POST form you can do the unit testing on the server side to make sure it handles all error conditions correctly and passes the correct error code / message to the web application.

If you are using AJAX however, with client-side testing you can do the testing of the form validations directly on the page itself using Jasmine. In fact even without ajax and js you could use Jasmine to verify that the client-side validations are working correctly. Try to make sure that you use HTML5 client side validations whenever possible as you know these should work without testing (after all if u find a bug what do u do?). The need to test will depend on several factors, mostly related to business need to know if it breaks.

The key thing is to design a fast system with as few automated UI test as possible (I mean in favor of non-UI tests which can run 100+ times faster). The few automated tests that do get created should be chosen very carefully and never from a list of 'check condition a,b,c,d, whatever else we can think of' or you end up with massive UI test suites that takes hours and days to run in all the different devices and browsers

I suggest you look to use* a test pyramid pattern with something like

                1 manual UI test
              2 automated UI tests
            10 automated Unit tests

The manual test is to look at the page and see if anything seems amiss. This will cover the styles verification plus a lot more. The automated UI tests should cover the happy path, one sad path and 1 optional path. So: (1 case) happy - payment works, sad (2 cases) - amount is invalid, e.g. alpha and amount is blank.

For the unit cases it will actually depend on the technology:

If using a HTML POST form you can do the unit testing on the server side to make sure it handles all error conditions correctly and passes the correct error code / message to the web application.

If you are using AJAX however, with client-side testing you can do the testing of the form validations directly on the page itself using Jasmine. In fact even without ajax and js you could use Jasmine to verify that the client-side validations are working correctly. Try to make sure that you use HTML5 client side validations whenever possible as you know these should work without testing (after all if u find a bug what do u do?). The need to test will depend on several factors, mostly related to business need to know if it breaks.

The key thing is to design a fast system with as few automated UI test as possible (I mean in favor of non-UI tests which can run 100+ times faster). The few automated tests that do get created should be chosen very carefully and never from a list of 'check condition a,b,c,d, whatever else we can think of' or you end up with massive UI test suites that takes hours and days to run in all the different devices and browsers.

Update:

* Originally I said 'create a test pyramid'. This might be a bit too high level. What I meant was the the test pyramid principle should guide your actions and where to test. This should be adding (not 'creating') to the test pyramid approach.

I suggest you look to create a test pyramid with someething like

                1 manual UI test
              2 automated UI tests
            10 automated Unit tests

The manual test is to look at the page and see if anything seems amiss. This will cover the styles verification plus a lot more. The automated UI tests should cover the happy path, one sad path and 1 optional path. So: (1 case) happy - payment works, sad (2 cases) - amount is invalid, e.g. alpha and amount is blank.

For the unit cases it will actually depend on the technology:

If using a HTML POST form you can do the unit testing on the server side to make sure it handles all error conditions correctly and passes the correct error code / message to the web application.

If you are using AJAX however, with client-side testing you can do the testing of the form validations directly on the page itself using Jasmine. In fact even without ajax and js you could use Jasmine to verify that the client-side validations are working correctly. Try to make sure that you use HTML5 client side validations whenever possible as you know these should work without testing (after all if u find a bug what do u do?). The need to test will depend on several factors, mostly related to business need to know if it breaks.

I suggest you look to create a test pyramid with someething like

                1 manual UI test
              2 automated UI tests
            10 automated Unit tests

The manual test is to look at the page and see if anything seems amiss. This will cover the styles verification plus a lot more. The automated UI tests should cover the happy path, one sad path and 1 optional path. So: (1 case) happy - payment works, sad (2 cases) - amount is invalid, e.g. alpha and amount is blank.

For the unit cases it will actually depend on the technology:

If using a HTML POST form you can do the unit testing on the server side to make sure it handles all error conditions correctly and passes the correct error code / message to the web application.

If you are using AJAX however, with client-side testing you can do the testing of the form validations directly on the page itself using Jasmine. In fact even without ajax and js you could use Jasmine to verify that the client-side validations are working correctly. Try to make sure that you use HTML5 client side validations whenever possible as you know these should work without testing (after all if u find a bug what do u do?). The need to test will depend on several factors, mostly related to business need to know if it breaks.

The key thing is to design a fast system with as few automated UI test as possible (I mean in favor of non-UI tests which can run 100+ times faster). The few automated tests that do get created should be chosen very carefully and never from a list of 'check condition a,b,c,d, whatever else we can think of' or you end up with massive UI test suites that takes hours and days to run in all the different devices and browsers