jPOS Client Simulator: functional testing on the Control Plane

Payment systems are only as trustworthy as the testing behind them.

For an issuer, correctness is not just a response code. It is the ISO 8583 message on the wire, the product rules that shaped the decision, the ledger entries that were posted, and the evidence an operator can inspect later.

The new Client Simulator demo shows that loop end to end on the jPOS Control Plane: a live jCard issuer, a real CMF channel, a functional test suite, raw logs, and a reconciled general ledger.

What the demo shows

The video follows a complete functional test flow for a live jCard issuer:

• the jPOS Control Plane running in Kubernetes, with the jCard issuer deployed as a separate pod
• the ACME entity, its GOLD card product, BIN, authorization fee, velocity profile, cardholders, and active cards
• a Client Simulator project with endpoint, packager, suite, and cases bundled together
• a live CMF channel to the jcard-acme issuer pod
• a CMF v3 ISO 8583 packager describing the wire format
• the jcard-auth suite: 39 cases and 133 steps
• cases that combine platform actions with ISO requests
• field rules, assertion rules, and response grading
• a full suite run against the live pod
• raw ISO request and response traffic in the Log Viewer
• the resulting ledger entries on the cardholder account
• AI-assisted suite authoring and the path from correctness testing to load and soak testing

The important part is that these are not separate demos. The same run connects product configuration, generated traffic, operational logs, and accounting state.

More than message blasting

A simple ISO message blaster can tell you whether a host answered. It cannot tell you whether the test was staged correctly, whether the response matched the business rule, or whether the financial entries landed where they should.

The Client Simulator is a functional test harness. A case is made of typed steps:

• platform actions can reset velocity counters, fund a cardholder, or assert a ledger entry
• ISO request steps build real messages and send them to the issuer
• assertions grade the response field by field
• variables and helpers make each run deterministic without hard-coding every value

That means a single case can prepare its own state, drive wire traffic, inspect the issuer response, and verify the books.

Evidence on the wire

Every ISO step is built from explicit rules. Some fields are fixed literals, some come from helpers such as trace-number and timestamp generators, some come from the case variables, and others can be produced by small sandboxed scripts.

The response is graded the same way. In the demo, an authorization step expects response code 0000 and checks for the balance information in data element 54. The run captures the expected and received values, so the result is not just "green"; it is inspectable.

Because the test drives the live issuer, the traffic is also visible in the Log Viewer. The operator can inspect the actual request and response messages, such as 2100/2110 and 2200/2210, exactly as they crossed the channel.

That is the useful evidence trail: the test intent, the generated ISO message, the issuer response, and the structured log record all line up.

The ledger is part of the test

For card issuing, a passed response is not enough. The issuer also has to post the right entries.

The demo follows account 2.10.ACME.0000001, the cardholder account used during the run. With the relevant layers selected, the balance history shows settled and pending activity. The account statement shows every transaction touched by the suite.

Opening one authorization shows the general ledger legs behind it:

• the cardholder is debited on the pending layer for the hold
• the acquirer is credited for the purchase amount
• the issuer fee is booked to its own revenue account
• debits and credits balance

The simulator mocked none of this. It drove the real issuer, and the issuer posted to the real ledger.

AI authoring and scale

The demo closes with where this is going next. The Control Plane already has preconfigured suites for jCard and jPTS, and the integrated assistant can help author or edit them.

The important detail is the review boundary. A prompt can ask for a larger fixture set, a mixed traffic stream, or a fan-out from one known-good authorization into thousands of variations. The assistant returns a reviewable change set. The operator still decides what becomes part of the suite and what runs.

That keeps the correctness workflow controlled while making the harness easier to expand.

Once the suite exists, the same idea scales beyond functional correctness. The Client Simulator runs inside the Control Plane, on Kubernetes. The same structured cases that prove behavior on one issuer pod can be scaled horizontally to drive larger traffic patterns for load, endurance, and soak testing.

Why this matters

Payment testing needs to connect intent with evidence. A useful test has to show what it meant to do, what it sent, what came back, and what financial state changed as a result.

That is the practical value of putting the Client Simulator inside the jPOS Control Plane. It uses live endpoints, real packagers, structured assertions, operational logs, and the same ledger the issuer writes to in normal operation.

The result is a testing surface that is not just faster to run, but easier to trust.