Merchant Portal Automation Task

What they ask

QA candidates get an automation task on the live merchant portal, in two flavours over the years.

Sign-up form (2022). Automate the merchant registration page: submit with nothing filled and assert the required-field errors; fill invalid data (a numeric name, a short phone, an email without a domain, a password that fails the policy, a confirmation that does not match) and assert each validation message; then the happy path with valid data through to the next step. Candidates did it in Cypress with fixtures for the credentials, screenshots of the error states, a Mochawesome report and, in one case, visual checks with Applitools.

Payment requests (2024). Log in to the merchant dashboard and automate the Payment Requests feature end to end: create a request with valid data; try an empty customer name and amount; a negative amount; an amount longer than eight digits; change the request currency; edit an existing request; mark a request as paid; and finally pay a request as a guest through the hosted checkout. Delivered as Java, Selenium, TestNG, Cucumber feature files with step definitions and a Page Object Model (login page, dashboard, payment requests list, edit page, payment page), with test data in a properties file.

What they look for

• Page objects that mirror the portal (login, dashboard, the feature page, the checkout page) and a hooks class that logs in once.
• Negative cases that are specific to money: zero, negative, too many digits, a currency change after creation.
• The guest checkout path asserted on the payment result page, not only on the redirect.
• Stable locators on a React dashboard where class names change, and screenshots on failure.
• Test data that does not pollute the merchant account: unique names, cleanup, or the test mode.