Automating the execution of payment test cases is only one part of building a fully automated testing workflow. For continuous testing, organizations also need a way to trigger test execution automatically and process the resulting test outcomes without requiring manual interaction with the testing platform.Â
The latest PaytestHubAPI integration addresses this requirement by allowing external systems to initiate existing PaytestHub test cases and test sets and retrieve their results in a machine-readable format. This extends PaytestHub beyond automated test execution and enables it to become part of broader CI/CD and software development workflows.Â
For payment software development and QA teams, the integration provides a way to increase testing frequency and receive faster feedback on software changes while continuing to execute tests against real payment environments.Â
Moving Beyond Manual Test Triggers
PaytestHub already automates the execution of payment test cases. Once a test begins, PaytestHub can orchestrate the components required to complete the defined payment flow, including interactions with terminals and other PaytestLab products.Â
However, initiating that automated process has traditionally required user interaction with PaytestHub. A tester logs into the platform, selects the relevant environment and test case or test set, starts the execution, waits for completion, and reviews the result.Â
The PaytestHubAPI integration changes this part of the workflow.Â
An external system can now trigger automated regression testing using an existing test case or test set through the PaytestHubAPI. PaytestHub executes the defined procedure and makes the result available in a machine-readable format. This means that both the initiation of the test and the handling of its outcome can become part of a larger automated process.Â
The distinction is important. The test execution itself was already automated. The new capability removes the requirement for a person to manually determine when that execution starts and subsequently retrieve the result.Â
Moving PaytestHubAPI to the Orchestration Level
It is important to distinguish between two of our APIs: PaytestAPI and PaytestHubAPI.  The difference is the level of access a third-party system has to our testing infrastructure.Â
Previously, PaytestAPI primarily exposed individual commands for specific components. An API call could instruct PaytestRobot to perform an action, select a card through PaytestProbe, wait for a particular screen using OCR, or capture information through ADB.Â
These commands provide access to individual functions, but they require the calling system to coordinate the overall test flow. Building a complete automated payment test through this approach requires the calling system to understand which actions need to happen, in which sequence, and how the different components should work together.Â
Our new PaytestHubAPI operates at the PaytestHub test orchestration level. Instead of calling each individual action required during a transaction, an external system can request the execution of complete test sets that have already been defined in PaytestHub.Â
PaytestHub then manages the procedure contained within that test case. Depending on the scenario, this can include starting the transaction, handling card interaction, entering a PIN, responding to steps such as Dynamic Currency Conversion (DCC), and asserting the expected outcome.Â
The external system does not need to recreate this payment-specific orchestration. It initiates the appropriate test and receives the resulting status once execution is complete.Â
Integrating Payment Testing into CI/CD
One of the main drivers behind the PaytestHubAPI integration was the requirement to bring PaytestHub into continuous integration and continuous delivery (CI/CD) workflows.Â
In a typical software development process, a developer makes a change to the terminal software and a new version is built and deployed. Without an API-level connection to PaytestHub, automated payment testing still requires someone to initiate the appropriate test set after deployment.Â
With the new integration, the testing stage can be incorporated into the automated development process. Once a new software version has been built and deployed to the device, an external system can trigger the relevant PaytestHub regression test or test set. PaytestHub performs the automated test case execution and returns the result so that the surrounding system can determine whether the run was successful.Â
This enables payment testing to run according to the organization’s development schedule rather than the availability of a tester. Regression suites could, for example, be executed overnight or several times throughout the day following new builds.Â
When the development and QA teams return, successful tests are already identified, while failed runs can be investigated using the available results.Â
The primary benefit is therefore not a change in how quickly an individual test case executes. Test case creation and maintenance also remain fundamentally the same. The significant change is the frequency and consistency with which those tests can be executed because they can now be initiated automatically through external systems and CI/CD pipelines.Â
Integrating PaytestHub with External Testing Frameworks
The PaytestHubAPI integration also supports organizations where PaytestHub forms one part of a broader testing environment.Â
A fully integrated retail setup provides a useful example. An organization may already use another test automation framework to control and validate the Electronic Cash Register (ECR), including the checkout process and other application-specific workflows. That framework may not need to manage the detailed behavior of the payment terminal itself.Â
When the test reaches the payment stage, the external framework can call PaytestHub through PaytestHubAPI and request the execution of the relevant payment test case.Â
PaytestHub then manages the payment-specific procedure according to the test case that has already been defined. This means the external framework does not need to account individually for terminal behaviors such as PIN entry, DCC selection, card interaction, or other steps included within the payment flow.Â
This separation allows organizations to retain their existing test automation infrastructure while using PaytestHub for specialized POS and terminal testing and orchestration.Â
The capability is not restricted to one payment architecture. In the current implementation, the main requirements are that the PaytestHub environment is correctly configured and active and that the relevant test case or test set has already been created.Â
Increasing Test Frequency and Coverage
The integration also changes how organizations can scale their regression testing strategy.Â
The process of designing and maintaining test cases remains unchanged. Teams still need to define the scenarios they want to validate, establish the expected outcomes, and maintain those tests as their payment software evolves.Â
What changes is the operational effort required to execute them repeatedly.Â
A team can begin with a relatively small collection of important regression tests and schedule them as part of its existing automated processes. Additional test cases can then be introduced as the testing strategy matures without creating a corresponding requirement for someone to manually initiate and monitor every execution.Â
This allows automated payment testing to run more frequently and provides development teams with more immediate feedback. Instead of waiting for a dedicated testing stage, organizations can use repeated automated execution to identify unexpected behavior closer to the software change that introduced it.Â
The result is a more scalable approach to payment software QA in which test coverage can expand without increasing the manual workload associated with starting and monitoring test runs.Â
Current Scope and Future Development
The current PaytestHubAPI integration focuses on standard PaytestHub test cases where the procedure and expected outcome are defined within PaytestHub. The platform executes the test, asserts the expected result, and makes the outcome available to the calling system.Â
This should be distinguished from the existing EMV Level 3 testing process. In an EMV L3 workflow, PaytestHub receives test case information from an external Level 3 test tool, executes the required interactions with the terminal, and returns the execution information. PaytestHub is facilitating the execution rather than independently defining and asserting the Level 3 test outcome.Â
Extending API capabilities into EMV Level 3 automation is one of the areas planned for future development.Â
Additional PaytestHubAPI functionality is also expected to provide external systems with greater visibility into the testing infrastructure itself. This could include capabilities for checking the status and health of different testing environments and PaytestRobot systems, further reducing the need for manual interaction when operating automated payment testing infrastructure.Â
The first version of the PaytestHubAPI integration is currently available in beta. Additional functionality, including authorization through bearer tokens, is planned as part of the full initial release targeted for the end of September 2026.Â
Building Toward Continuous Payment Testing
The PaytestHubAPI integration represents an important step in PaytestLab’s approach to payment test automation. Rather than exposing only individual hardware and software actions through an API, PaytestHub can now provide programmatic access to the orchestration layer responsible for complete payment test execution.Â
This allows organizations to connect end-to-end payment testing more directly with CI/CD pipelines, existing testing frameworks, and broader software development processes while continuing to test against real payment environments.Â
For QA and development teams, the objective is not simply to automate more individual actions. It is to reduce the manual coordination surrounding those actions and make payment testing a repeatable part of the software delivery process.Â
As PaytestHubAPI expands to support additional testing and infrastructure capabilities, PaytestHub can increasingly operate as a centralized payment testing platform that external systems can trigger, monitor, and integrate into their own automated workflows.Â
Interested in integrating automated payment testing into your CI/CD workflow? Contact us to discuss how PaytestHubAPI can support your testing environment.Â