Client Simulator on the jPOS Control Plane
The XML-based Client Simulator in jPOS-EE has been useful for generating ISO 8583 traffic and checking responses for many years. The new Client Simulator is a major overhaul of that work, integrated into the jPOS Control Plane.
Sending a message is only part of an automated test. Before an authorization can produce a meaningful result, somebody has to provision the card, fund its account, and put its velocity counters into a known state. Afterward, checking the response code is not enough: the test may also need to verify the hold, the fee, or the entries posted to the ledger.
When those operations live outside the simulator, the test depends on setup scripts and assumptions about what happened during the previous run. The Control Plane brings them into the test itself. A case can combine platform operations with ISO 8583 exchanges and assertions, preparing its own state and checking the financial consequences. The messages still go to a live issuer; the surrounding work becomes part of a repeatable test.
The updated video shows this against jCard, including how a result connects to the messages on the wire, the issuer’s participant trace, and the resulting ledger entries.
Correctness and load are different problems
A functional suite answers whether the system behaves as expected under the conditions being tested. A performance test asks what happens as traffic grows: throughput, latency, contention, and the point at which the system stops keeping up. Running a correct sequence faster is not, by itself, a realistic workload.
A common approach is to adapt a general-purpose tool such as JMeter—often used for HTTP testing—to generate ISO 8583 traffic. Our approach keeps the payment simulation in jPOS and uses Kubernetes to distribute the work.
The Control Plane’s job runner can launch actual pods, backed by the cluster’s hardware. Connecting that execution model to Client Simulator is the next step: distribute populations of simulated cardholders across workers, each maintaining realistic transaction sequences rather than repeatedly sending an isolated message.
The target is tens of thousands of transactions per second, with stochastic workloads controlling arrival times, transaction mixes, amounts, and cardholder activity. Those distributions matter: a uniform stream of authorizations exercises a different system from customers making purchases, encountering limits, and generating captures and reversals.
The video demonstrates the correctness side available today. Distributed load and soak testing build on that foundation—the same payment-aware simulation, with execution spread across the cluster. The throughput target will need to be measured against a specified workload and hardware configuration.