Why We Chose Cypress Over Postman and Selenium for Testing Payments
by Sundari
Testing a payments product is rarely straightforward. Payments are not just API calls and responses—they involve complex user journeys, redirections to external systems, multi-step authentication, and a variety of payment methods. As our product scaled, so did the complexity of testing these flows reliably and efficiently.
We started with Postman for API testing, which helped validate basic scenarios early on. But as we introduced more interactivity in the front end and added support for multiple payment connectors, Postman quickly reached its limits. We needed a framework that could test the full user experience, handle authentication flows, and scale with our growing system.
After evaluating several options—including Selenium—we chose Cypress as our front-end and end-to-end testing framework. This post outlines the specific challenges we faced, why Postman and Selenium could not fully address them, and how Cypress helped us build a robust, maintainable, and scalable testing strategy.
Testing payments is not like testing a typical CRUD application. There are a number of real-world complexities that any testing tool needs to handle. Here are some of the major ones we faced:
Many payment flows involve 3D Secure authentication, OTP validation, or redirects to external banking pages. Postman, being an API-only tool, had no way to simulate or verify these user interactions. Even browser automation tools like Selenium required extra work to manage session continuity across redirects.
Cypress gave us a way to handle these flows more naturally, simulating a real user navigating through redirections and returning to the application with the session intact.
Our product supports several payment service providers (PSPs), each with its own authentication rules, APIs, and user experiences. This created a few key problems:
-
We had to maintain separate test cases for each provider
-
Ensuring consistency across flows became difficult
-
Test coverage was fragmented, and regression testing took longer
We needed a unified framework that could abstract these differences and allow us to scale our tests with minimal duplication.
Payments happen across platforms—desktop, mobile web, and embedded browsers inside mobile apps. Ensuring a consistent experience across browsers like Chrome and Firefox was essential, but not something Postman could cover. We needed a tool that could run browser-based tests in a reliable and repeatable way.
As our test suite grew, so did the complexity of managing sensitive data and consistent state across tests. With Postman, adding new test cases meant managing tokens, test cards, and setup steps manually. This approach quickly became hard to maintain and slowed us down when expanding coverage.
Postman served us well in the early stages of our product. It allowed us to test individual APIs, validate responses, and debug issues quickly. But as our system evolved into a more stateful, interactive platform, Postman’s limitations became clear.
Payments are not just about what happens on the backend. They involve front-end interactions, redirections to third-party pages, and dynamic user decisions. Postman could test whether an API returned a 200 status—but it could not validate that the user was redirected correctly, authenticated successfully, or saw the right UI feedback after completing a payment.
Postman executes requests in isolation. While you can chain requests using scripts and environments, it does not natively support full session management. Testing workflows like login followed by payment initiation and 3DS redirection became increasingly error-prone as we tried to preserve state manually between requests.
Postman cannot validate what is rendered on the UI. Even when an API call succeeds, we had no insight into how the front-end responded. Was the "Payment Successful" message shown? Did the page transition as expected? Postman simply could not answer those questions.
As we added more connectors and edge cases, maintaining Postman collections became unwieldy. We had to:
-
Duplicate flows across environments
-
Rely on test data that had to be manually updated
-
Write increasingly complex scripts to simulate flows
It became clear that what started as a useful tool for API testing was not built to handle real-world payment scenarios at scale.
We considered Selenium for browser automation during our evaluation phase. It is widely used and battle-tested, but it did not align well with our goals. Here’s why:
Selenium tests are usually written in Java or Python. Our front-end team works primarily in JavaScript and TypeScript, so adopting Selenium would have created a disconnect in tooling and made test contributions harder.
Selenium uses a WebDriver to control the browser, which introduces latency and makes test runs slower. It also lacks the real-time visibility we wanted. Debugging issues in Selenium often involves digging through logs, while Cypress provides a visual, time-traveling debugger that lets you replay every test step.
Setting up Selenium involves managing WebDriver binaries, test runners, and integrating with CI pipelines manually. We wanted a solution that was easier to set up, required fewer moving parts, and worked well out of the box.
After moving beyond Postman and evaluating tools like Selenium, Cypress emerged as the clear winner for our current use cases. Here is what made it a strong fit:
Cypress tests are written in JavaScript, which made it easy for our front-end engineers to contribute. The syntax is clean, readable, and fits naturally into our existing codebase.
Cypress allowed us to test both API responses and UI interactions within a single test flow. We could:
-
Intercept API calls and stub responses
-
Validate that UI updates reflected the expected state
-
Test real end-to-end payment flows from start to finish
This gave us full confidence in the system without needing to mock external behaviors.
Cypress’s built-in UI lets us inspect every test run in detail. Failed tests can be replayed step by step, making it easy to identify where things went wrong. This drastically reduced the time we spent debugging compared to log-based tools.
Cypress integrates smoothly with GitHub Actions and other CI tools. We were able to plug it into our workflow and run tests on every pull request, catching regressions before they reached production. The fast feedback loop helped us maintain quality without slowing down development.
Testing payments is a different ballgame. It involves external redirections, dynamic user journeys, and sensitive state handling that traditional API tools like Postman cannot fully capture. While we considered Selenium during our evaluation, it did not align with our goals for speed, simplicity, and developer ownership.
Cypress provided the right mix of power and usability. It helped us bridge the gap between API and UI testing, fit perfectly with our front-end tech stack, and offered visibility into how users actually interact with our product.
For teams building complex workflows on modern web applications, Cypress offers a reliable and developer-friendly path to scalable testing.